Architecture guide / Technology choices
Choose a stack you can change.
No framework can promise to fit every future requirement. A better technology decision explains what the business needs now, which changes are plausible, what would be expensive to replace, and how the team will keep the system supported.
Replace the permanence promise
Ask what changes, and what it would cost.
An adaptable stack meets today's important requirements while keeping selected future changes manageable. That means explicit boundaries, accessible data, maintained dependencies and a team that can operate the system. It also means choosing which options are worth paying for.
- Current fit comes first
- A system that cannot meet the actual workflow, data or operating requirements is a poor choice even if its components are fashionable or easy to swap.
- Flexibility has a carrying cost
- Every extra service, abstraction and deployment path needs ownership and verification. Preserve an option when a credible change justifies that work.
- An exit is something you rehearse
- An export button or interface diagram does not establish replaceability. Inspect the data, dependent behavior, migration steps and acceptance evidence required to move.
Six tests for a technology proposal
Ask for evidence at the expensive boundaries.
Use these questions to compare a shortlist. Record the tradeoffs for the actual product and team; do not collapse every answer into a single popularity score.
Fit the real workload
01Decision question: Can this choice serve the work the business must do?
- Why it matters
- Architecture debates can start before anyone defines transaction behavior, access boundaries or the operating environment.
- Evidence to request
- Critical workflows, data volumes and shapes, latency needs, availability expectations, integrations and deployment constraints.
- Useful investigation
- Build a representative vertical slice and test demanding operations with realistic data. Separate measured behavior from assumptions and vendor claims.
- Tradeoff to decide
- Product and engineering owners agree which requirements are mandatory and which can change.
- Decision record
- Requirement, candidate, test conditions, result, limitations and unresolved risk.
- Weak answer
- A trivial demo is used to claim production scale or an average response time hides the slow path.
- Review trigger
- A new workflow, data scale, access model or operating requirement invalidates the original test.
Match the team that will own it
02Decision question: Can the team maintain and recover this system?
- Why it matters
- A technology choice includes the work of upgrades, incidents, delivery and handover.
- Evidence to request
- Team experience, ownership map, deployment process, debugging tools, recovery procedure and dependence on specialist knowledge.
- Useful investigation
- Have the intended team make a small change, deploy it in a safe environment and diagnose a deliberately introduced failure.
- Tradeoff to decide
- Engineering leaders weigh capability development and specialist support against delivery and operating demands.
- Decision record
- Named owners, demonstrated tasks, knowledge gaps and the plan to close them.
- Weak answer
- Hiring availability is assumed, or only the original implementer can release or recover the system.
- Review trigger
- Ownership changes, routine upgrades stall or incidents depend on one person.
Keep change boundaries explicit
03Decision question: Which parts can change without rewriting the product?
- Why it matters
- Coupling often comes from shared assumptions and data access rather than the number of applications.
- Evidence to request
- Module responsibilities, public contracts, dependency directions, business rules and vendor-specific behavior.
- Useful investigation
- Trace one plausible change through the code and interfaces. Identify which consumers must change together and test the contract that should remain stable.
- Tradeoff to decide
- Architects decide where a boundary reduces a real change cost and where direct integration is simpler.
- Decision record
- Boundary purpose, dependent consumers, compatibility policy and a representative change test.
- Weak answer
- Every component receives a generic wrapper, or microservices are treated as proof of independence.
- Review trigger
- Repeated changes cross the same boundary or a supposedly isolated vendor assumption spreads.
Retain usable data
04Decision question: Could another implementation understand the records?
- Why it matters
- Data meaning, identity and history can outlive the framework that first stored them.
- Evidence to request
- Schemas, identifiers, relationships, units, audit history, exports, retention requirements and authoritative ownership.
- Useful investigation
- Export representative data and reconcile it into a separate test reader. Check missing fields, relationships and historical meaning, not just row counts.
- Tradeoff to decide
- Data and business owners decide what must be preserved and what a migration must prove.
- Decision record
- Data contract, source of truth, reconciliation rules, known loss and acceptance owner.
- Weak answer
- A CSV export is called an exit plan although important relationships or history are absent.
- Review trigger
- A new integration, retention requirement or data model exposes assumptions that were never documented.
Plan ordinary upgrades
05Decision question: Can the stack stay supported without a periodic rescue?
- Why it matters
- An initially good choice can become difficult to maintain when upgrades and dependency changes accumulate.
- Evidence to request
- Current versions, official support policies, licensing terms, dependencies, upgrade guidance and a maintenance owner.
- Useful investigation
- Rehearse an upgrade in a test environment with meaningful compatibility checks. Record the manual work and recovery procedure.
- Tradeoff to decide
- Engineering owners choose an upgrade policy and budget that match the system's risk and operating constraints.
- Decision record
- Version inventory, verified policy links, upgrade evidence, owner and next review date.
- Weak answer
- Popularity substitutes for a support policy, or all dependency work is deferred until an urgent problem.
- Review trigger
- A support milestone, incompatible dependency, license change or failed upgrade changes the risk.
Price the replacement path
06Decision question: What would it take to replace this choice?
- Why it matters
- A low entry cost can hide data conversion, contract changes and a long period of running two systems.
- Evidence to request
- Affected workflows, contracts, data movement, coexistence needs, cutover criteria, operating costs and rollback limits.
- Useful investigation
- Map an incremental or whole-system replacement for one likely change. Test the riskiest boundary before describing the plan as reversible.
- Tradeoff to decide
- Business and engineering owners weigh the cost of keeping an exit available against the likelihood and impact of needing it.
- Decision record
- Migration stages, acceptance tests, temporary responsibilities and the point after which rollback becomes harder.
- Weak answer
- A proxy is added without ownership, dual-system data consistency is ignored, or an indefinite migration is called low risk.
- Review trigger
- A vendor, cost, product or operating change makes the current tradeoff materially worse.
A change rehearsal
Replace flexibility claims with a concrete scenario.
These examples are prompts for investigation. The right test depends on the product, and passing one scenario does not prove that every future change will be easy.
| Likely change | Boundary to inspect | Hidden cost | Owner | Useful proof |
|---|---|---|---|---|
| Replace an external service | Adapter and business contract | Provider-specific semantics | Integration owner | Equivalent behavior with test inputs |
| Add a new channel | Shared business rules | Rules copied into interfaces | Product engineering | New interface reuses checked behavior |
| Change data storage | Data ownership and access | Queries, history and migration | Data owner | Reconciled test migration |
| Increase workload | Measured bottleneck | Coordination and operating cost | Engineering and operations | Representative load evidence |
| Upgrade a framework | Dependency and runtime surface | Compatibility and release effort | Maintainer | Passing upgrade rehearsal |
| Transfer ownership | Delivery and recovery knowledge | Undocumented operating work | Engineering lead | New owner completes routine tasks |
Make the decision reviewable
Keep the rationale with the choice.
A short decision record should let the next owner understand why the stack was chosen and what would justify reconsidering it.
- 01
State the constraints
Name the product workflows, data, operating requirements, team capability and delivery limits. Mark assumptions separately from requirements that cannot be traded away.
- 02
Compare a credible shortlist
Include improving the current system where relevant. Compare the whole delivery and operating approach, including dependencies, rather than collecting framework features.
- 03
Test the costly uncertainty
Choose a representative workflow and one plausible future change. Run a bounded investigation with an acceptance criterion; record failures and unresolved questions.
- 04
Record the decision and consequences
Write the context, alternatives, chosen option, reasons and tradeoffs. Give the record an owner and review it with the people who will build and operate the system.
- 05
Set a review trigger
Monitor the properties that matter and schedule maintenance. When evidence changes the decision, preserve the old rationale and record the replacement decision instead of rewriting history.
Keep adaptation practical
Maintain the conditions that made the choice work.
Architecture evolves through working changes and feedback. These practices make the decision easier to reassess without adding speculative infrastructure.
- Automate meaningful boundaries
- Test contracts, dependency direction and important operating properties where automation provides useful feedback. A green build alone does not prove the architecture remains suitable.
- Assign maintenance ownership
- Keep dependency upgrades, documentation, recovery procedures and vendor-policy review in ordinary engineering work. Record who acts when a review trigger occurs.
- Make transitional work temporary
- For an incremental replacement, name the owner of routing, shared data and cross-system behavior. Define completion and removal criteria before adding another permanent layer.
- Preserve the point of return
- Distinguish a deployment rollback from recovery of changed data and contracts. Rehearse the relevant recovery path and identify destructive steps that require separate approval.
Questions behind the shortlist
Choose for evidence you can inspect.
A defensible proposal explains both the reason to choose a technology and the conditions under which that reason stops being persuasive.
- Is any technology stack future-proof?
- No stack can establish that every unknown requirement will fit. The useful target is a system the team can maintain and adapt to plausible changes, with the costs and limitations of that adaptability understood.
- Do microservices make a system easier to change?
- They can create independent deployment boundaries, but shared data, contracts and operating dependencies can still force coordinated change. Assess a specific boundary and the team's ability to operate it before choosing a distributed design.
- Should every vendor be hidden behind an abstraction?
- No. An abstraction is useful when it isolates a meaningful change or clarifies a stable business contract. A generic wrapper can add maintenance while leaving important vendor semantics untouched.
- Is incremental migration always safer than a rewrite?
- No. Microsoft's Strangler Fig guidance identifies situations where the pattern may not fit, including a small system that is simple to replace or an urgent need to retire the original. Coexistence, data consistency, routing and eventual removal all add work.
- What should a stack proposal contain?
- Ask for the actual constraints, alternatives, reasons, operating ownership, representative test evidence, dependency and support review, and likely change costs. Include unresolved assumptions and the conditions that would reopen the decision.
Source basis
Sources behind the control model.
- 01
AWS
Architectural decision record processGuidance for recording architectural context, decisions and consequences, with ownership, review and superseding records when decisions change.
- 02
Microsoft
Strangler Fig patternIncremental replacement guidance, updated June 2026, including applicability limits, shared resources, transitional costs and data-validation and rollback considerations.
- 03
Martin Fowler
Foreword to Building Evolutionary ArchitecturesA 2017 explanation of architecture as continuing change with feedback, including architectural fitness functions and attention to long-lived data. Used as a conceptual basis, not current product guidance.
Start with one real workflow
A Systems Audit is the usual starting point. If the opportunity is already clear, we can move directly into a focused build.
Show Us the WorkflowStart with the free automation readiness checklistOBSERVEQUANTIFYDECIDEBUILD