13. Architecture Decision-Making and Technology StrategyIntroduction and ContextSoftware architecture is not only the design of components, interfaces, databases, and deployment environments. It is also a system of consequential choices made under uncertainty. Selecting a messaging platform, deciding whether to build or purchase a capability, accepting a cloud provider’s managed service, or postponing a platform redesign can influence cost, reliability, security, delivery speed, employee skills, and business flexibility for years. At small scale, architectural choices are often made informally. A developer selects a framework, a team adopts a cloud service, and the decision appears reversible. At organisational scale, however, the consequences become distributed. A technology choice may affect procurement, legal compliance, operations, hiring, customer experience, financial planning, and the ability to enter new markets. Architecture decision-making therefore connects technical design with strategy. This chapter presents a disciplined approach to making and governing such decisions. It examines architecture decision records, trade-off analysis, fitness functions, reference architectures, technical-debt assessment, build-versus-buy evaluation, vendor lock-in, total cost of ownership, FinOps, sustainability, and organisational readiness. The central argument is that a good architectural decision is not necessarily the one using the newest or most powerful technology. It is the decision that best fits the organisation’s goals, constraints, capabilities, risk appetite, and expected future change. Learning ObjectivesBy the end of this chapter, the learner should be able to: 1. Explain why architecture decisions require explicit evidence, assumptions, and governance. 2. Create and evaluate an architecture decision record (ADR). 3. Analyse architectural alternatives using trade-off matrices and scenario-based reasoning. 4. Design measurable fitness functions for important quality attributes. 5. Use reference architectures without treating them as rigid templates. 6. Identify, classify, and prioritise technical debt. 7. Evaluate build-versus-buy choices, vendor dependence, and total cost of ownership. 8. Explain the role of FinOps and sustainability in technology strategy. 9. Assess organisational readiness before adopting an architectural approach. 10. Apply these methods to a realistic system-design decision. Architecture as a Strategic Decision PracticeAn architecture decision is a choice about the significant structure, behaviour, technology, or governance of a system. Significant does not necessarily mean technically complex. A decision is architecturally significant when reversing it would be expensive, when it constrains many future choices, or when it affects important system qualities such as availability, security, performance, privacy, or maintainability. Architecture decisions operate at several levels. Strategic decisions concern the direction of a product or technology portfolio, such as adopting a multi-cloud policy or standardising on a particular integration style. Solution decisions concern a product or platform, such as choosing between a relational database and a document database. Delivery decisions concern implementation and operation, such as selecting a deployment model or defining service-level objectives. These decisions are linked. A strategic commitment to rapid international expansion may require an architecture capable of regional deployment and data-locality controls. That requirement can influence database selection, identity management, observability, and cloud-provider choice. Consequently, architecture cannot be evaluated only through diagrams or component-level benchmarks. It must be interpreted in relation to business objectives and organisational capabilities. A useful distinction is between reversible and irreversible or expensive-to-reverse decisions. A user-interface library may be replaced within a product cycle. Replacing a payment provider, data model, identity platform, or event backbone may require migration, customer communication, compliance review, and prolonged parallel operation. The latter decisions deserve more analysis and stronger governance. Nevertheless, excessive analysis is also harmful. The objective is not perfect prediction but an appropriately informed and transparent commitment. Architecture Decision Records: Preserving ReasoningAn architecture decision record is a short document that captures an important architectural choice, the context in which it was made, the alternatives considered, and the consequences expected. Its value is not merely historical. An ADR prevents organisational memory from being lost when staff change, makes assumptions reviewable, and enables later teams to distinguish an intentional constraint from an accidental one. A practical ADR normally includes: - Title and status: for example, “Use a managed relational database,” with a status such as proposed, accepted, superseded, or deprecated.
- Context: the business need, system constraints, quality requirements, known risks, and relevant assumptions.
- Decision: the selected approach stated clearly and specifically.
- Alternatives: credible options that were examined, not merely weak options created to justify a preferred answer.
- Decision drivers: factors such as latency, regulatory requirements, cost, delivery time, portability, skills, and operational complexity.
- Consequences: benefits, disadvantages, new responsibilities, and effects on future decisions.
- Evidence and validation: experiments, benchmarks, prototypes, vendor assessments, or stakeholder approvals.
- Review conditions: events or dates that should trigger reconsideration.
An ADR should record why a decision was appropriate at the time, rather than pretending that it is universally correct. For example, “Adopt provider X” is weaker than “Adopt provider X for the first two years because the team lacks operational expertise in self-managed infrastructure, the service meets regional data requirements, and the migration interface will be isolated behind an internal abstraction.” The latter statement makes the boundaries and assumptions visible. ADRs should be stored near source code or in an accessible engineering knowledge base. They should be version-controlled and linked to relevant architecture diagrams, risk registers, infrastructure code, and product objectives. A decision should be revisited when its assumptions change—not merely because a new technology becomes fashionable. From Preferences to Trade-Off AnalysisArchitectural choices rarely produce a single winner across all dimensions. A platform may offer excellent scalability but impose high operating complexity. A commercial product may accelerate delivery but reduce portability. A data architecture may maximise consistency while limiting availability during network partitions. Trade-off analysis makes these tensions explicit. The first step is to identify decision drivers and convert vague preferences into evaluation criteria. “The system must be fast” is insufficient. A more useful requirement may be that 95 percent of checkout requests complete within 300 milliseconds under a defined workload. “The solution should be affordable” may become a first-year budget ceiling, a monthly cost-per-transaction target, or an agreed total cost of ownership over three years. A weighted decision matrix can support comparison. Each criterion receives a weight reflecting its importance, and each alternative receives a score based on evidence. The resulting total is not an objective truth; it is a structured conversation. It is particularly useful when accompanied by sensitivity analysis. If a small change in the weight of portability reverses the result, the decision is sensitive and should be discussed more carefully. Scenario analysis is often more valuable than a simple score. Teams can examine normal operation, peak demand, regional failure, security incident, staff turnover, regulatory change, vendor price increase, and rapid business growth. The question is not merely “Which option is best?” but “Which option performs acceptably across the futures that matter?” Common trade-offs include: - delivery speed versus long-term flexibility;
- operational simplicity versus customisation;
- consistency versus availability or partition tolerance;
- performance versus cost;
- central standards versus team autonomy;
- innovation speed versus governance and control;
- portability versus deep use of provider-specific capabilities.
Trade-off analysis should also distinguish constraints from preferences. A legal data-residency requirement is a constraint; a team’s familiarity with a framework is usually a preference or capability factor. Confusing the two can lead to unnecessarily narrow designs. Fitness Functions: Making Architecture TestableA fitness function is an automated or repeatable test that provides evidence about whether an architecture satisfies a desired characteristic. The concept converts architectural aspirations into measurable controls. It is especially valuable in evolving systems, where architecture can gradually drift away from intended qualities. Examples include: - an automated test that rejects services with an unauthorised dependency;
- a deployment check verifying that all production data is encrypted;
- a performance test enforcing a latency threshold at a specified load;
- a static analysis rule limiting cyclic dependencies;
- a cost monitor identifying resources that exceed a budget envelope;
- a resilience experiment verifying recovery within the defined recovery-time objective;
- an accessibility test applied to user-facing interfaces.
Fitness functions may be transactional, measuring a single request or deployment, or holistic, evaluating system-wide behaviour. They may be triggered continuously in a delivery pipeline or run periodically against production-like environments. They can also be qualitative at first, provided the evaluation method is explicit; however, measurable functions are generally easier to govern. A fitness function must have a threshold, scope, measurement method, and response. A statement such as “the platform should be secure” is not a fitness function. “All externally accessible endpoints must require approved authentication and must produce an audit event for privileged actions” is more actionable. Teams should avoid turning every preference into a hard gate. Excessive gates create false alarms, slow delivery, and encourage teams to bypass governance. Fitness functions should focus on architecture characteristics that matter materially to the system. Fitness functions also reveal conflicts. A cost threshold may encourage smaller instances, while a latency threshold may require additional capacity. The correct response is not to hide the conflict but to make it visible and decide which trade-off is acceptable under particular conditions. Reference Architectures and Contextual AdaptationA reference architecture is a tested or recommended arrangement of architectural elements, practices, and technology patterns for a class of systems. It may describe a web application platform, a data-analytics environment, a regulated financial service, or a multi-region SaaS product. Reference architectures reduce design effort, provide a common vocabulary, and embed lessons from previous implementations. They should not be treated as universal blueprints. A reference architecture contains assumptions about scale, threat model, latency, organisational skills, regulatory setting, and operating model. Applying it without examining those assumptions can produce unnecessary services, excessive cost, and complexity that the organisation cannot operate. A sound adaptation process is to identify the reference architecture’s invariant principles and variable implementation details. For example, the principle “separate public traffic from administrative access” may remain valid, while the network technology used to implement it can vary. Teams should document deviations and their reasons, using ADRs where the deviation has significant consequences. Reference architectures are particularly useful for platform teams. They can provide approved patterns for identity, observability, data protection, deployment, secrets management, and disaster recovery. Reusable patterns should be offered as paved roads rather than compulsory roads in every case. Teams need a documented exception process for legitimate differences. Technical Debt as a Portfolio of ObligationsTechnical debt refers to the future cost created when a design or implementation choice provides a short-term advantage at the expense of later correction, maintenance, risk, or reduced adaptability. The metaphor is useful only when applied carefully. Not every imperfect implementation is debt, and not all debt is irresponsible. A deliberate temporary shortcut can be rational if its repayment conditions are understood. Technical debt may be: - intentional and prudent, such as postponing optimisation until usage patterns are known;
- intentional and reckless, such as bypassing security controls to meet an arbitrary deadline;
- unintentional and prudent, where future consequences were not visible at the time;
- unintentional and reckless, where poor engineering practice created avoidable problems.
Debt also appears at different levels: code, architecture, infrastructure, data, testing, documentation, and organisational processes. Architectural debt often has a wide blast radius. For example, a tightly coupled service boundary can make independent deployment, scaling, and team ownership difficult. Assessment should consider principal, interest, risk, and urgency. Principal is the effort needed to correct the issue. Interest is the recurring cost paid while it remains. Risk concerns the likelihood and impact of failure or constraint. A debt register can record the affected capability, evidence, owner, estimated remediation effort, business impact, and trigger for action. A useful prioritisation method compares the expected cost of carrying debt with the cost and risk of repayment. Debt that blocks a strategic initiative, threatens compliance, causes repeated incidents, or increases operating cost should generally receive higher priority than debt that is merely aesthetically undesirable. Fitness functions, incident data, delivery metrics, and support effort provide evidence for this assessment. Build, Buy, Subscribe, or Partner?The build-versus-buy decision is better understood as a spectrum: build internally, adopt open source, purchase licensed software, consume a managed cloud service, or partner with an external provider. The correct choice depends on whether the capability differentiates the business and whether the organisation can operate it reliably. Building may be justified when the capability is central to competitive advantage, requires distinctive behaviour, or cannot be obtained without unacceptable restrictions. It also provides control over roadmap and data, but demands investment in engineering, security, support, upgrades, and continuity. Buying or subscribing is attractive for commodity capabilities such as standard authentication, email delivery, payment processing, monitoring, or collaboration. It can reduce time to value and transfer some operational responsibility. However, it may introduce integration work, contract dependence, data-transfer concerns, pricing exposure, and limitations on customisation. The analysis should include more than acquisition price. Relevant questions include: - What is the capability’s strategic importance?
- How quickly is it required?
- Can the organisation recruit and retain the necessary expertise?
- What service levels, support, security controls, and compliance evidence are available?
- How difficult is migration if the provider fails or prices change?
- Who owns the data, and in what format can it be exported?
- What internal integration, testing, monitoring, and governance work remains?
A capability that is non-differentiating but operationally demanding is often a strong candidate for managed consumption. Conversely, outsourcing a capability that defines customer value may weaken strategic control. These are not absolute rules; they are prompts for analysis. Vendor Lock-In and Portability StrategyVendor lock-in exists when changing a supplier is sufficiently difficult or costly that the organisation’s practical freedom of choice is reduced. Lock-in can result from proprietary APIs, data formats, identity integration, operational knowledge, contractual terms, specialised skills, or large volumes of data that are expensive to move. Lock-in is not automatically negative. Deep adoption of a provider’s managed services may produce better reliability, faster delivery, and lower operational burden. The strategic issue is whether the benefits are worth the reduced flexibility and whether the organisation has accepted the dependency knowingly. Portability should be treated as a design objective with a cost, not as an abstract virtue. Possible mitigations include data-export procedures, open formats, isolated provider adapters, abstraction at selected boundaries, contractual exit assistance, multi-provider testing, and maintaining skills outside the primary supplier. Full multi-cloud deployment is not always an effective mitigation; it can duplicate complexity and cost without eliminating dependence on specialised services. A vendor-risk review should examine financial stability, security posture, service history, subcontractors, data location, incident communication, exit terms, pricing mechanisms, and concentration risk. Critical providers should have contingency plans and tested recovery procedures. Total Cost of Ownership and FinOpsTotal cost of ownership (TCO) estimates the full economic cost of a solution over a defined period. It includes direct and indirect costs rather than only licence or infrastructure charges. A TCO model may include compute, storage, network transfer, licences, support, implementation, migration, training, security controls, observability, backups, disaster recovery, staff time, procurement, compliance, and eventual replacement or exit. A simple TCO model can be expressed as: TCO = acquisition and implementation costs + operating costs + people costs + risk and compliance costs + migration or exit costs − residual value. The formula is not intended to produce false precision. Its purpose is to make omitted costs visible. Estimates should state assumptions such as workload growth, retention periods, staffing levels, discounts, and failure rates. Scenario ranges are generally more credible than one exact number. FinOps is an organisational and operational practice for creating shared accountability for cloud-related cost. Engineering teams understand the technical causes of consumption, finance teams manage budgets and forecasts, and product or business teams connect spending to value. FinOps is not simply cost cutting. A cheaper system that causes outages or slows product delivery may destroy more value than it saves. Useful practices include resource tagging, cost allocation to products, budget alerts, unit economics, rightsizing, scheduling non-production environments, selecting appropriate pricing commitments, removing unused resources, and reviewing cost during architecture design. Unit measures such as cost per order, cost per active customer, or cost per gigabyte processed are more informative than total monthly expenditure alone. Cost governance must avoid harmful incentives. If teams are punished for all infrastructure growth, they may under-provision systems or conceal usage. Cost decisions should be evaluated alongside reliability, security, performance, and customer outcomes. Sustainability as an Architectural ConcernSustainable architecture considers the environmental effects of computing across the system life cycle. Important factors include energy consumption, hardware utilisation, data movement, storage retention, cooling, hardware manufacture, and the embodied impact of replacing equipment. Software decisions influence these factors through workload efficiency and resource demand. Architectural practices that may improve sustainability include efficient algorithms, right-sized resources, workload scheduling, data-retention policies, compression where appropriate, reducing unnecessary network transfers, using caching carefully, and selecting infrastructure with credible environmental reporting. However, optimisation must be evidence-based. Moving computation to another region or adding a cache may reduce one form of consumption while increasing another. Sustainability can be incorporated into fitness functions and TCO analysis. For example, teams can monitor compute utilisation, storage growth, data-transfer volume, or energy-related indicators supplied by infrastructure providers. Sustainability should not be separated from business resilience: efficient systems may reduce cost and improve performance, while durable designs reduce replacement and migration work. Organisational Readiness and the Operating ModelAn architecture succeeds only when an organisation can build, operate, secure, and evolve it. Organisational readiness includes skills, team boundaries, decision rights, funding, product ownership, operational practices, leadership support, and learning capacity. A distributed system adopted by a team without observability, automated testing, incident response, and platform expertise is not merely a technical risk; it is an operating-model mismatch. Likewise, a platform strategy that assumes autonomous product teams will fail if all deployments require approval from a central group. Readiness assessment can examine: - technical skills and recruitment capacity;
- team cognitive load and ownership boundaries;
- deployment automation and environment consistency;
- monitoring, tracing, logging, and incident management;
- security and compliance maturity;
- architecture governance and exception handling;
- funding for migration and ongoing operations;
- executive sponsorship and stakeholder alignment.
The result should influence the architecture. A modular monolith may be more appropriate than microservices when independent scaling and deployment are not yet needed. A managed platform may be preferable when the organisation cannot support a complex control plane. Readiness is not a permanent label; it can improve through staged adoption, training, platform investment, and controlled experimentation. An Integrated Decision WorkflowA practical decision workflow begins by framing the problem rather than selecting a technology. The team clarifies the business outcome, scope, constraints, quality scenarios, time horizon, and decision authority. It then identifies plausible alternatives, including the option of making no change. Next, the team gathers evidence through prototypes, benchmarks, threat modelling, supplier assessment, cost estimation, and consultation with operations, security, finance, legal, and product stakeholders. Alternatives are evaluated against decision drivers and realistic scenarios. Uncertainty should be recorded explicitly; assumptions that could materially change the decision become candidates for experiments or review triggers. The selected option is documented in an ADR, with consequences and ownership. Important characteristics are converted into fitness functions. The implementation is then staged where possible, using a reversible first step, a migration seam, or a limited pilot. After adoption, actual cost, reliability, delivery performance, and user outcomes are compared with the assumptions. The decision is retained, adapted, or superseded on the basis of evidence. This workflow prevents two opposite failures: ungoverned local choices that accumulate systemic risk, and centralised architecture processes that delay delivery without improving decisions. Illustrative Case Study: Selecting an Order-Processing PlatformBackgroundNorthstar Retail, a fictional online retailer, is growing from a regional operation into several markets. Its order-processing application is a modular monolith hosted on virtual machines. It uses a relational database, a third-party payment gateway, and a separately managed search service. The engineering team consists of eight developers, two operations specialists, and one security engineer shared with other products. Situation and ProblemSeasonal traffic causes capacity concerns, deployments are increasingly difficult, and the company wants to launch in two additional regions. A technology supplier proposes a fully managed event-driven order platform. Another internal group recommends decomposing the application into microservices and operating the components on a container platform. A third option is to improve the existing monolith and adopt selected managed services. The executive request is framed as “move to a scalable architecture within nine months.” The architecture group reframes it as: increase peak order capacity, reduce deployment risk, support regional data requirements, and preserve a sustainable operating model without exceeding the approved cost envelope. AnalysisThe team identifies the following decision drivers: order correctness and auditability, recovery objectives, time to market, peak throughput, regional data controls, operational complexity, three-year TCO, provider exit options, and staff capability. It rejects a simplistic definition of scalability based only on request volume because order processing also requires consistency, reconciliation, and dependable payment state transitions. A prototype shows that the existing relational model can support the projected transaction volume after indexing and partitioning changes. A second experiment demonstrates that asynchronous events can decouple notifications and analytics without placing the core order transaction on an unreliable path. The team also discovers that operating a new container platform would require two additional specialists and a substantial observability investment. The decision matrix favours an incremental approach: retain the order core as a modular monolith, use a managed relational database, introduce an event broker for non-critical downstream activities, and isolate payment and search integrations behind adapters. The fully managed supplier would accelerate delivery but create difficult data-export and workflow dependencies. A complete microservice decomposition would offer future independent scaling but would exceed current readiness and introduce distributed consistency challenges. Strategy and SolutionThe ADR records the selected architecture and its assumptions. It defines a two-year review trigger based on sustained throughput, team growth, or a requirement for independent regional deployment. Fitness functions include database recovery within the agreed objective, automated checks preventing direct access to payment-provider APIs outside the adapter, deployment rollback capability, and a cost-per-order threshold. FinOps tags resources by product capability and produces a monthly cost-per-order report. The sustainability review targets storage retention and non-production scheduling. A supplier assessment requires exportable transaction data, documented incident communication, and an exit-assistance clause. The migration is staged: first observability and database improvements, then integration isolation, then event-driven secondary workflows. OutcomeThe approach avoids a high-risk rewrite while addressing the immediate business requirements. The organisation gains evidence about actual bottlenecks before committing to service decomposition. It also accepts a known limitation: the order core remains a scaling and deployment boundary. This limitation is recorded as managed architectural debt with explicit review conditions rather than being hidden as an accidental problem. Learning PointsThe case illustrates that architecture strategy is a portfolio of choices rather than a contest between fashionable patterns. It also shows the value of distinguishing core correctness from peripheral asynchronous work, assessing organisational readiness, recording exit options, and using measurable fitness functions. Most importantly, a staged decision can preserve future choices while delivering present value. Risks, Failure Modes, and Governance ConcernsA frequent mistake is technology-first reasoning: selecting a platform because it is popular and then searching for a problem it can solve. Another is false precision in scoring matrices, where arbitrary numerical values conceal disagreement. Teams may also omit operational costs, underestimate data migration, or treat supplier assurances as evidence without independent validation. Architecture governance can fail in two directions. Weak governance permits duplicated technologies, inconsistent security controls, and unrecognised dependencies. Excessive governance creates approval queues and discourages experimentation. Effective governance sets guardrails, publishes reference patterns, requires explicit records for consequential decisions, and offers timely exception handling. Ethical and regulatory considerations include privacy, data minimisation, accessibility, algorithmic accountability, auditability, and equitable access to services. A low-cost vendor is not an acceptable choice if it exposes sensitive data or prevents legally required access and deletion. AI-enabled services require additional examination of data use, model reliability, explainability, bias, intellectual-property terms, and human oversight. Decision-makers should also recognise power asymmetry. A supplier may provide attractive introductory pricing while retaining control over pricing, interfaces, or data practices. Contracts, security reviews, procurement controls, and executive accountability are therefore part of architecture strategy, not administrative details. Current Developments and Emerging DirectionsArchitecture decision-making is increasingly supported by internal developer platforms, policy-as-code, automated cost analysis, software supply-chain controls, and continuous compliance checks. These tools can turn architectural principles into executable guardrails. However, automation does not eliminate judgement; poorly designed rules can encode outdated assumptions and block legitimate innovation. Generative AI is being used to summarise ADRs, detect dependency patterns, propose infrastructure changes, estimate cloud costs, and assist with threat modelling. Its outputs require human review because it may reproduce insecure patterns, misunderstand organisational constraints, or invent evidence. AI should support decision preparation rather than replace accountability. Platform engineering is also changing the build-versus-buy discussion. Organisations increasingly create internal platforms that provide standardised deployment, identity, observability, and security capabilities to product teams. Such platforms can reduce cognitive load, but they themselves become products requiring user research, service levels, investment, and lifecycle governance. The strategic direction is therefore toward continuous architecture: decisions are documented, tested through fitness functions, observed in production, and revisited as evidence changes. This approach is more durable than one-time architecture reviews. Best Practices for Professional Decision-Making1. Start with business outcomes, quality scenarios, and constraints rather than products or tools. 2. Record consequential decisions and the assumptions that support them. 3. Compare credible alternatives, including incremental change and no change. 4. Use experiments and production evidence to reduce uncertainty. 5. Separate hard constraints from preferences and temporary compromises. 6. Evaluate TCO over a defined time horizon, including people, migration, and exit costs. 7. Treat vendor lock-in as a trade-off to manage, not a slogan to avoid. 8. Make important qualities measurable through proportionate fitness functions. 9. Include finance, security, legal, operations, product, and sustainability perspectives. 10. Assess organisational readiness before adopting a complex architecture. 11. Prefer staged adoption and reversible steps when uncertainty is high. 12. Revisit decisions when assumptions, scale, regulations, suppliers, or organisational capabilities change. Chapter SummaryArchitecture decision-making links technical design with business strategy, organisational capability, financial responsibility, and long-term adaptability. Architecture decision records preserve context, alternatives, assumptions, and consequences. Trade-off analysis and scenario evaluation provide a disciplined basis for comparing alternatives, while fitness functions make architectural qualities testable and guard against drift. Reference architectures accelerate design but must be adapted to local conditions. Technical debt should be treated as a portfolio of obligations whose cost, risk, and repayment urgency can be assessed. Build-versus-buy decisions must consider strategic differentiation, skills, integration, control, and lifecycle responsibility. Vendor lock-in may be acceptable when its benefits outweigh its managed risks. TCO and FinOps expose the full economic effects of architecture, while sustainability extends evaluation to resource and environmental impact. Finally, organisational readiness determines whether an architecture can actually be delivered and operated. Effective strategy is therefore evidence-based, explicit, staged, and continuously reviewed. Key TermsArchitecture Decision Record (ADR): A document capturing the context, alternatives, decision, and consequences of an important architectural choice. Architectural decision: A significant choice that shapes system structure, behaviour, technology, or governance. Trade-off analysis: Systematic comparison of alternatives across competing criteria and scenarios. Decision driver: A factor that materially influences an architectural choice, such as cost, security, or latency. Fitness function: An automated or repeatable test that evaluates whether an architecture satisfies a desired quality. Reference architecture: A reusable architectural model for a particular class of systems or organisational context. Technical debt: Future cost, risk, or reduced adaptability created by a present design or implementation choice. Build-versus-buy: Evaluation of whether a capability should be developed internally or obtained externally. Vendor lock-in: Reduced practical freedom to change suppliers because migration is costly or difficult. Portability: The ability to move a system, workload, or data between environments or suppliers. Total cost of ownership (TCO): The full lifecycle cost of acquiring, operating, maintaining, and retiring a solution. FinOps: A collaborative practice connecting cloud usage, financial accountability, and business value. Unit economics: Cost or value measured per meaningful business unit, such as transaction or active customer. Organisational readiness: The skills, structures, processes, funding, and governance needed to adopt and operate an architecture. Quality attribute: A non-functional system characteristic such as availability, performance, security, or maintainability. Decision sensitivity: The extent to which a decision changes when assumptions, weights, or conditions change. Exit strategy: Planned methods and conditions for reducing or ending dependence on a technology or supplier. Architecture drift: Gradual divergence between the intended architecture and the system that is actually implemented. Review QuestionsShort Answer Questions1. What information should an architecture decision record contain? 2. Distinguish between a reversible and an expensive-to-reverse architecture decision. 3. What is a fitness function, and why is it useful? 4. Define total cost of ownership in the context of technology strategy. 5. Why is organisational readiness relevant to architecture adoption? Long Answer Questions1. Explain how trade-off analysis and scenario analysis can be combined to evaluate competing architectures. 2. Discuss the benefits and risks of using reference architectures in a large organisation. 3. Describe a systematic method for identifying and prioritising technical debt. 4. Analyse the strategic factors that should influence a build-versus-buy decision. 5. Explain how FinOps, sustainability, and reliability can be considered together in architecture governance. Analytical / Application Questions1. A company is considering a provider-specific database for a high-growth product. Develop an evaluation framework addressing performance, TCO, lock-in, portability, organisational readiness, and exit strategy. 2. A development team proposes decomposing a stable monolith into twenty microservices because the organisation expects future growth. What evidence, fitness functions, and readiness criteria should be required before approving the proposal? 3. Construct a brief ADR outline for replacing a self-managed monitoring stack with a managed observability service. State at least three decision drivers, two risks, and two review triggers. 22. Multiple Choice Questions with AnswersQuestion 1Which statement best describes the primary purpose of an architecture decision record? A. To provide a complete implementation manual for every component B. To preserve the context, reasoning, alternatives, and consequences of a significant decision C. To replace all technical requirements and test plans D. To guarantee that an architectural decision will never be changed Correct Answer: B. To preserve the context, reasoning, alternatives, and consequences of a significant decision Question 2A team says that its system “must be fast.” Which change would make this requirement most suitable as a fitness function? A. Describe performance as a general engineering preference B. Require the newest available hardware C. Specify a latency threshold under a defined workload D. Ask developers to optimise code whenever possible Correct Answer: C. Specify a latency threshold under a defined workload Question 3Which factor most strongly indicates that a decision deserves extensive architectural analysis? A. The decision uses a familiar programming language B. The decision is easy to reverse without migration or disruption C. The decision constrains many future choices and is costly to reverse D. The decision affects only a temporary development experiment Correct Answer: C. The decision constrains many future choices and is costly to reverse Question 4What is a major weakness of using a weighted decision matrix without sensitivity analysis? A. It cannot list more than two alternatives B. It may conceal how changes in assumptions or criterion weights affect the result C. It always favours open-source technologies D. It prevents teams from considering cost Correct Answer: B. It may conceal how changes in assumptions or criterion weights affect the result Question 5Which situation is the clearest example of technical debt? A. A documented temporary shortcut with an identified repayment trigger B. A completed feature that has passed all agreed tests C. A business requirement that has not yet been prioritised D. A reference architecture published by a platform team Correct Answer: A. A documented temporary shortcut with an identified repayment trigger Question 6Why might an organisation rationally accept vendor lock-in? A. Lock-in always eliminates operating costs B. Provider-specific services may deliver sufficient strategic and operational benefits when dependency risks are managed C. Portability is never relevant to architecture D. Contracts cannot reduce supplier risk Correct Answer: B. Provider-specific services may deliver sufficient strategic and operational benefits when dependency risks are managed Question 7Which cost is commonly omitted from an overly narrow technology price comparison? A. Implementation, training, migration, and ongoing people costs B. The colour of the system diagram C. The number of product meetings unrelated to the system D. The programming language’s historical popularity Correct Answer: A. Implementation, training, migration, and ongoing people costs Question 8What is the central purpose of FinOps? A. To minimise all cloud spending regardless of service quality B. To connect cloud consumption, financial accountability, and business value C. To transfer all technology decisions to the finance department D. To eliminate the need for cost monitoring Correct Answer: B. To connect cloud consumption, financial accountability, and business value Question 9A team adopts a complex distributed architecture but lacks observability, incident-response processes, and operational skills. What does this primarily indicate? A. Excessive data portability B. Insufficient organisational readiness C. Successful reference-architecture reuse D. A completed exit strategy Correct Answer: B. Insufficient organisational readiness Question 10Which approach best manages uncertainty in a high-impact architecture decision? A. Choose the most fashionable technology immediately B. Avoid documenting assumptions so the team remains flexible C. Use experiments, staged adoption, explicit review triggers, and measurable fitness functions D. Require a permanent commitment before testing alternatives Correct Answer: C. Use experiments, staged adoption, explicit review triggers, and measurable fitness functions
|
