IT Phrases Guide
English Phrases for Architecture Decision — IT Professional's Guide
English vocabulary and phrases for discussing technical architecture choices — proposing options, evaluating trade-offs, and building consensus.
9 phrases across 2 situations · 3 phrases to avoid · 5 exercises · 10 FAQ items
Framing the Problem
- The core trade-off here is [A] versus [B] — optimising for [one] makes [other] harder.Structuring an architectural discussion around trade-offs
"The core trade-off here is consistency vs availability — optimising for strong consistency makes horizontal scaling harder."
- I'd like to propose [approach] — here's my reasoning.Introducing a solution professionally
"I'd like to propose an event-driven architecture here — here's my reasoning."
- What are the constraints we're designing around?Clarifying requirements before proposing solutions
"Before we dive into options, what are the constraints we're designing around — latency, cost, team expertise?"
- Have we considered [alternative approach]? I'd like to understand why we ruled it out.Surfacing alternatives without dismissing current direction
"Have we considered a monolith-first approach? I'd like to understand why we ruled it out before committing to microservices."
Evaluating Options
- The risk with this approach is [X] — mitigated by [Y].Presenting risks with mitigations
"The risk with this approach is eventual consistency causing stale reads — mitigated by adding a read-your-writes guarantee for the user's own session."
- This is a reversible decision — we can change it later without high cost.Categorising decision reversibility (Bezos "one-way door" framework)
"This is a reversible decision — the schema is internal and we can migrate it later without high cost."
- This is a one-way door — once we go this route, migrating away will be very expensive.Flagging an irreversible commitment
"Choosing a proprietary event broker is a one-way door — migrating away from it later will be very expensive."
- I'd recommend writing an ADR to document this decision.Suggesting an Architecture Decision Record
"Given the long-term impact, I'd recommend writing an ADR to document this decision and our reasoning."
- What does the team's operational expertise look like for this stack?Surfacing the human factor in architecture decisions
"Before we commit to Kafka, what does the team's operational expertise look like for this stack?"
Phrases to Avoid
These common phrasings undermine your professionalism. Here are better alternatives.
Tech choices without reasoning sound like personal preference. Trade-off framing is persuasive and defensible.
"Over-engineered" is dismissive. Proposing a simpler alternative with a scale rationale is constructive.
"Always done it this way" shuts down discussion. Asking whether new requirements are materially different is honest and open.
Practice Exercises
Choose the most professional or correct phrase for each scenario.
Frequently Asked Questions
What is an ADR and why write one?
An Architecture Decision Record documents a significant technical decision: the context, the options considered, the chosen approach, and the consequences. It creates an audit trail for future engineers who wonder "why did we do it this way?"
What does "trade-off" mean in architecture discussions?
A trade-off is when improving one quality (e.g. performance) comes at the cost of another (e.g. consistency or cost). Architects explicitly name trade-offs to make decisions transparent and defensible.
What is "eventual consistency"?
Eventual consistency is a model where data replicas may be temporarily out of sync but will converge to the same state given enough time. Common in distributed databases and event-driven systems.
What does "scalability" mean?
Scalability is the ability of a system to handle increased load — either vertically (adding resources to one machine) or horizontally (adding more machines).
What is a "monolith"?
A monolith is a single deployable application containing all the functionality. Contrasted with microservices. Monoliths are simpler to develop and operate at small scale but can become hard to change as they grow.
What does "coupling" mean?
Coupling is the degree of interdependence between components. High coupling means a change in one component forces changes in others. Good architecture aims for low coupling and high cohesion.
What is "CAP theorem"?
CAP theorem states that a distributed system can only guarantee two of three properties simultaneously: Consistency, Availability, and Partition tolerance. It's a foundational concept in distributed systems design.
What does "idempotent" mean in API design?
An idempotent operation produces the same result no matter how many times it's called. HTTP PUT and DELETE are idempotent; POST typically is not.
What is "technical debt" in architecture?
Technical debt is the accumulated cost of shortcuts and suboptimal decisions. Architectural debt (choosing the wrong patterns) is particularly expensive because it's pervasive and hard to refactor away.
What does "loose coupling" mean?
Loose coupling means components interact through well-defined interfaces and know little about each other's implementation. This makes them independently deployable, testable, and replaceable.