Architecture Evaluation and Managerial Decision-Making

Introduction and Context

Serverless applications and microservices create substantial architectural freedom. Teams can select cloud functions, containers, managed databases, message brokers, API gateways, observability platforms, and commercial services independently. This freedom is valuable, but it also creates managerial responsibility. A technically attractive service may increase operating cost, regulatory exposure, vendor dependence, or organisational complexity. Consequently, architecture is not only a software design activity; it is also a decision-making discipline.

Architecture evaluation is the systematic examination of whether a proposed system can satisfy its functional and quality requirements within technical, financial, organisational, legal, and operational constraints. Managerial decision-making uses this evidence to determine what should be built, purchased, retained, migrated, standardised, or rejected.

For a diploma-level practitioner, the central lesson is that no architecture is universally best. A suitable architecture is one whose trade-offs are explicit, measurable where possible, and acceptable to the organisation that must operate and govern it.

Learning Objectives

By the end of this chapter, learners should be able to:

1. Explain the role of quality attributes in architecture evaluation.
2. Compare architectural alternatives using explicit criteria.
3. Prepare an Architecture Decision Record (ADR).
4. Identify and prioritise technical, operational, financial, and organisational risks.
5. Evaluate build-versus-buy choices and vendor lock-in.
6. Relate team topology and service ownership to system design.
7. Construct a practical migration framework for serverless and microservice adoption.
8. Justify technology decisions to both technical and managerial stakeholders.

1. Architecture as a Decision System

An architecture consists not merely of components and interfaces, but also of constraints, responsibilities, deployment arrangements, data ownership, operational practices, and decisions about change. In a microservice system, these decisions include service boundaries, communication patterns, data consistency, deployment independence, and ownership. In a serverless system, they additionally include function granularity, event design, execution limits, managed-service dependence, and cost-control mechanisms.

A useful decision statement has five elements:

• Context: the business and technical circumstances.
• Problem: the decision that must be made.
• Alternatives: realistic options, including doing nothing.
• Criteria: the qualities and constraints used for comparison.
• Consequences: expected benefits, costs, risks, and future effects.

This structure prevents a common failure: selecting a technology because it is fashionable, familiar, or promoted by a supplier rather than because it satisfies a defined need.

Functional and Quality Requirements

Functional requirements describe what the system does, such as accepting an order, calculating a premium, or issuing a notification. Quality attributes describe how well it performs or behaves. Important attributes for cloud-native systems include:

Quality attributes are often in tension. Strong isolation may improve security but increase latency. Independent microservice deployment may improve modifiability but increase operational overhead. A highly managed serverless service may improve operability while reducing portability.

2. Evaluating Quality Attributes

Quality attributes should be converted into scenarios rather than left as vague aspirations. A quality-attribute scenario normally identifies:

1. Source: who or what generates the stimulus.
2. Stimulus: the event or condition.
3. Environment: normal operation, peak load, failure, or maintenance.
4. Artifact: the component or system affected.
5. Response: what the system should do.
6. Measure: how success will be judged.

For example:

During a promotional event, when order traffic reaches 500 requests per second, the order API shall accept valid requests with a 99th-percentile response time below 800 milliseconds, while failed requests are retried or reported without duplicate orders.

This is more useful than saying that the system must be “fast and scalable.” The scenario identifies a workload, a measurable threshold, and a correctness condition.

Availability and Reliability

Availability is the proportion of a period during which a service is operational according to an agreed definition. A simple availability measure is:

Uptime and downtime must use the same time unit, such as minutes per month. The measure is meaningful only when the organisation defines what counts as downtime, including exclusions such as planned maintenance or force majeure events.

For example, if a service is unavailable for 43.2 minutes in a 30-day month, total time is 43,200 minutes. Availability is approximately 99.9%. This calculation does not prove that users experienced acceptable service: monitoring coverage, partial failures, and degraded performance must also be considered.

Reliability concerns correct and consistent operation. A service can be available but unreliable if it returns incorrect results or loses messages. Serverless and microservice designs therefore require idempotency, retry policies, dead-letter handling, timeouts, and clear failure semantics.

Performance and Scalability

Performance includes latency, throughput, resource consumption, and sometimes cold-start behaviour. Averages alone can hide poor user experiences; percentiles such as p95 and p99 are often more informative. Scalability concerns the ability to maintain an acceptable quality level as workload changes.

Evaluation should consider:

• normal and peak traffic;
• synchronous and asynchronous paths;
• database and downstream-service limits;
• queue growth and processing delay;
• cold starts and provisioned capacity;
• throttling and retry amplification.

A function that scales automatically may still overload a database that does not scale at the same rate. Scalability is therefore a property of the whole dependency chain, not of an isolated component.

Security, Compliance, and Governance

Security evaluation includes identity, least privilege, secrets management, encryption, network controls, vulnerability management, logging, and incident response. In serverless systems, the large number of functions and event permissions can create an extensive policy surface. In microservices, service-to-service authentication and authorisation must be explicit.

Compliance is contextual. A system processing health, financial, educational, or personal information may require data residency, retention, auditability, breach reporting, segregation of duties, or approved subprocessors. A managed cloud service is not automatically compliant merely because the provider advertises certifications. The customer remains responsible for correct configuration, access control, data classification, and operational evidence.

Cost Efficiency

Cloud cost is usually variable and distributed across requests, execution time, storage, network transfer, observability, support plans, and idle resources. A simplified serverless execution estimate is:

The expression is an estimation model, not a universal provider billing formula. Units and pricing definitions differ between providers. Compute duration should be measured consistently, memory may be billed in configured or allocated units, and supporting costs must include logs, databases, queues, data transfer, and monitoring. Cost models should use realistic traffic distributions rather than a single average.

Total cost of ownership also includes engineering labour, training, migration, support, compliance, outages, and exit costs. A cheaper infrastructure invoice can therefore produce a more expensive system overall.

3. Architecture Decision Records

An Architecture Decision Record is a short, durable document that records an important architectural decision and its reasoning. ADRs preserve organisational memory. Without them, future engineers may remove a component whose purpose is no longer obvious or repeat a debate whose evidence has already been examined.

A practical ADR contains:

• title and status;
• date and decision owners;
• context and forces;
• decision statement;
• alternatives considered;
• evaluation criteria and evidence;
• consequences, including negative consequences;
• security, compliance, and cost implications;
• review date or reversal conditions.

Example ADR

Title: Use asynchronous messaging for invoice generation

Status: Accepted

Context: Invoice generation may involve slow tax and document services. Customers need rapid order confirmation, while invoices may be delivered within two minutes.

Alternatives: Generate synchronously; use a queue and worker; purchase a complete invoicing platform.

Decision: Publish an OrderConfirmed event to a managed queue. An invoice service consumes the event, stores processing status, and sends the completed invoice. Consumers must be idempotent.

Rationale: The asynchronous design reduces coupling and protects order latency. It introduces eventual consistency, queue monitoring, duplicate-message handling, and additional operational responsibility.

Consequences: Customers may briefly see an order without an invoice. The service must provide status visibility and a dead-letter process. The decision will be reviewed if invoice completion exceeds two minutes for more than 1% of orders.

A good ADR is not a sales document. It should state why an option was rejected and what would cause the decision to be reconsidered.

4. Risk Analysis and Trade-off Reasoning

Risk is the possibility that uncertainty will affect objectives. Architecture risks commonly include:

• excessive dependence on one provider;
• untested service boundaries;
• data inconsistency across services;
• unpredictable cost under burst traffic;
• insufficient observability;
• regulatory non-compliance;
• shortage of skills;
• insecure default permissions;
• migration downtime;
• unsupported or immature technology.

A qualitative risk register commonly records likelihood, impact, exposure, owner, mitigation, and contingency. A simple prioritisation model is:

This is an ordinal scoring aid, not a precise probability calculation. For example, if likelihood and impact are each rated from 1 to 5, a score of 20 indicates higher priority than a score of 6, but it does not mean the first risk is mathematically 3.33 times more dangerous. Organisations should define rating scales consistently.

Risk treatment can involve avoidance, reduction, transfer, acceptance, or monitoring. A risk should not be marked “mitigated” merely because a control exists; its effectiveness requires evidence such as test results, audit records, or operational metrics.

5. Build-versus-Buy Assessment

Build-versus-buy is a strategic decision about whether to develop a capability internally, purchase software, consume a managed service, or combine these options. The relevant question is not simply “Which is cheaper?” It is “Where can the organisation create differentiated value and acceptably control risk?”

A capability is a strong candidate for building when it is strategically differentiating, closely aligned with unique processes, unavailable at the required quality, or a source of intellectual property. Buying is often preferable for commodity capabilities such as email delivery, identity federation, payment processing, monitoring, or document storage, provided security and compliance requirements are satisfied.

Evaluation criteria include:

The comparison must include lifecycle cost, not only acquisition cost. A service that costs 10,000 currency units to integrate but 5,000 per month may exceed the cost of internal development over time. Conversely, internal software requiring two full-time specialists may be more expensive than a managed alternative.

A defensible assessment should document assumptions about transaction volume, growth, staffing, support, downtime, security controls, contract terms, and exit effort. Procurement, legal, security, finance, and operational teams should participate rather than leaving the decision to developers alone.

6. Vendor Lock-in and Portability

Vendor lock-in occurs when changing provider becomes sufficiently costly, risky, or slow that the organisation cannot act freely. Lock-in has several forms:

• Technical lock-in: proprietary APIs, event formats, runtimes, databases, or deployment models.
• Data lock-in: difficult export formats, large transfer volumes, or incompatible schemas.
• Operational lock-in: teams trained around one platform and lacking alternative skills.
• Commercial lock-in: contracts, minimum commitments, termination fees, or price changes.
• Regulatory lock-in: approvals or residency arrangements that complicate relocation.

Lock-in is not automatically unacceptable. A proprietary managed service may provide major productivity, reliability, or security benefits. The objective is informed dependence, not the unrealistic elimination of all dependence.

A lock-in assessment should ask:

1. Can data be exported in a complete, documented, usable format?
2. Can application logic be tested outside the provider environment?
3. Are interfaces based on open standards where practical?
4. What skills and tools would a migration require?
5. How long could the organisation operate during a transition?
6. What are the financial and contractual exit conditions?

Portability measures include containerised components, infrastructure as code, standard protocols, abstracted interfaces, portable data formats, regular export tests, and documented recovery procedures. Abstraction should be selective: an overly generic wrapper may hide valuable provider capabilities and add complexity without creating real portability.

7. Team Topology and Service Ownership

Architecture and organisation influence each other. A service cannot be genuinely independent if every change requires approval from a separate specialist team. Team topology addresses how teams are structured and how they interact.

Four useful team types are:

• Stream-aligned teams: aligned to a flow of customer or business value and responsible for delivering it.
• Platform teams: provide internal capabilities that reduce cognitive load, such as deployment platforms, observability, identity integration, and approved templates.
• Enabling teams: help other teams acquire skills or adopt difficult practices, without permanently taking ownership away.
• Complicated-subsystem teams: own specialist components requiring unusual expertise, such as advanced fraud models or highly specialised data processing.

Service ownership should be explicit. A service owner is accountable for its design, code, deployment, security posture, documentation, service-level objectives, incident response, cost, and lifecycle. Ownership does not mean one person performs every task; it means a team has clear accountability and authority.

A service catalogue should record:

• service purpose and business capability;
• owning team and escalation route;
• interfaces and dependencies;
• data classification and retention;
• deployment and rollback method;
• dashboards, alerts, and service-level objectives;
• recovery expectations;
• current cost and known risks;
• lifecycle state.

Poor ownership produces orphan services, duplicated platforms, slow incident response, and insecure configurations. Excessive fragmentation produces too many teams and coordination paths. The appropriate granularity is the smallest unit that can be changed, deployed, operated, and governed responsibly.

8. Migration Frameworks

Migration from a monolith or conventional platform to microservices and serverless should be incremental. A useful framework has the following stages.

Stage 1: Establish the Baseline

Document current business capabilities, dependencies, data flows, performance, incidents, costs, deployment frequency, and regulatory constraints. Without a baseline, improvement cannot be demonstrated and migration may merely relocate problems.

Stage 2: Identify Seams and Priorities

A seam is a boundary at which behaviour can be separated with manageable coupling. Candidate capabilities should have clear ownership, stable interfaces, tolerable data dependencies, and a meaningful reason for independent scaling or release. Do not select a capability solely because it is small.

Stage 3: Choose a Strangler or Coexistence Approach

The strangler approach places a new component in front of or beside an existing system and gradually redirects selected functionality. Coexistence may use an anti-corruption layer to translate between old and new models. Both approaches reduce the need for a risky “big bang” replacement.

Stage 4: Prepare Platform and Governance

Before multiplying services, establish automated delivery, identity patterns, logging, tracing, secrets management, environment management, cost controls, security scanning, backup standards, and ownership rules. A platform should provide paved paths while allowing justified exceptions.

Stage 5: Migrate Data and Contracts Carefully

Data migration is often harder than code migration. Use versioned contracts, backward-compatible changes, dual writing only when its consistency implications are understood, reconciliation, and rollback plans. Event schemas require ownership and evolution rules.

Stage 6: Measure and Learn

Track deployment frequency, lead time, change failure rate, recovery time, latency, availability, cost per transaction, security findings, and customer outcomes. Metrics should support learning rather than encourage teams to optimise a single number.

Stage 7: Retire Legacy Components

A migration is incomplete while old paths remain active and expensive. Confirm traffic has moved, data is reconciled, support procedures are updated, and rollback windows have closed before decommissioning. Record the retirement decision in an ADR or equivalent governance record.

9. Worked Evaluation Example

An organisation must choose between three approaches for sending customer notifications:

• build an internal notification service;
• use a managed cloud notification service;
• purchase a specialist communication platform.

The decision criteria are strategic differentiation, speed, compliance, operational effort, and portability. The notification capability is not a source of competitive advantage, but messages contain personal information and must be auditable.

The evaluation finds that internal development offers maximum control but requires specialists for email, delivery monitoring, bounce handling, and compliance evidence. The managed service offers rapid implementation and integrates with existing cloud identity, but creates provider dependence. The specialist platform offers advanced campaign features but introduces a separate contract, data processor review, and integration overhead.

The selected approach is the managed service for transactional notifications, subject to encrypted data handling, retention limits, export testing, budget alerts, and an interface owned by the organisation. Marketing campaigns are excluded because they have different requirements and may later justify a specialist platform.

This decision demonstrates bounded scope. “Buy” is not a single decision for all notification use cases. Architectural choices should be aligned with business capabilities and risk profiles.

10. Illustrative Case Study: Modernising a Regional Retailer

Background. A regional retailer operates a monolithic online store. Releases occur monthly, peak-season scaling is difficult, and the operations team receives limited visibility into failures. Management is considering a complete rewrite using microservices and serverless functions.

Problem. A complete rewrite promises modern technology but carries high delivery risk. The retailer has a small platform team, limited distributed-systems experience, and strict requirements for payment security and order correctness.

Analysis. The team maps the customer journey and finds that product search, order placement, payment, inventory reservation, and notification have different scaling and reliability characteristics. Search receives high read traffic; payment requires careful security controls; inventory reservation must prevent overselling; notification can be asynchronous. The team also discovers that the existing database is shared by many modules, making immediate service separation dangerous.

Approach. The organisation creates ADRs for an incremental migration. Search is extracted first because it has a clear interface and independent scaling need. A managed search service is selected after a data export and cost test. Notifications move to an asynchronous queue with idempotent consumers. Payment remains in the monolith until compliance and reconciliation controls are validated. A platform team supplies deployment templates, tracing, secrets management, and cost dashboards. Each extracted capability receives an owning team and service catalogue entry.

The team defines measurable targets: search p95 latency below 300 milliseconds during peak load, notification completion within two minutes for 99% of accepted events, no duplicate payment capture, and a rollback procedure tested before each migration step.

Outcome. Search deployment becomes independent, notification delays become visible through queue metrics, and peak capacity improves. The organisation does not immediately achieve a fully decomposed architecture, but it reduces risk and gains evidence for subsequent decisions. Some expected savings do not occur because observability and data reconciliation add costs.

Learning points. First, migration should follow business and risk boundaries rather than technological fashion. Second, service independence requires ownership, automation, and operational capability. Third, retaining a monolith temporarily can be a rational decision. Finally, success must be judged by customer and organisational outcomes, not by the number of services created.

11. Ethical, Legal, and Governance Considerations

Technology decisions affect employees, customers, suppliers, and communities. Managers should consider whether automation changes work without adequate consultation, whether monitoring collects excessive personal information, and whether service failures disproportionately affect vulnerable users.

Data minimisation, purpose limitation, retention control, access logging, and transparent processing are important governance practices. Artificial intelligence may be used in architecture tools for code generation, cost forecasting, anomaly detection, or risk classification, but generated recommendations require human review. AI outputs may reproduce insecure patterns, omit regulatory constraints, or expose confidential architecture information to an external service. Organisations should define approved tools, data-handling rules, review responsibilities, and provenance requirements.

Governance should be proportionate. Excessive approval gates slow delivery and encourage workarounds; insufficient governance creates unmanaged risk. Lightweight ADR review, automated policy checks, service ownership, and periodic architecture reviews often provide better control than committees that inspect every implementation detail.

12. Challenges and Limitations of Evaluation Frameworks

No framework removes uncertainty. Quality scenarios may be incomplete, estimates may be biased, and test environments may not represent production. Cost forecasts are particularly sensitive to traffic growth, data transfer, logging volume, and provider pricing changes. Risk matrices can create false precision when ratings are subjective. Weighted scoring models may hide disagreement behind a single number.

Evaluation should therefore combine quantitative evidence with expert judgement. Use prototypes, load tests, security assessments, contract reviews, failure exercises, and pilot migrations. Record assumptions and revisit them when conditions change. A decision that was appropriate for a small workload may become inappropriate after rapid growth, a regulatory change, or an acquisition.

Best Practices for Professional Decision-Making

1. Start with business capability and user outcomes.
2. Express quality requirements as measurable scenarios.
3. Compare realistic alternatives, including “do nothing.”
4. Record significant decisions and their consequences in ADRs.
5. Treat cost, security, compliance, and operability as design concerns.
6. Assign clear service ownership before production deployment.
7. Use risk registers with named owners and tested mitigations.
8. Evaluate total lifecycle cost and exit cost, not only initial price.
9. Use managed services deliberately, with evidence-based lock-in decisions.
10. Migrate incrementally and preserve rollback options.
11. Build platform capabilities that reduce, rather than conceal, complexity.
12. Review decisions when assumptions, scale, regulations, or strategy change.

Chapter Summary

Architecture evaluation connects technical design with organisational strategy. Quality attributes such as availability, performance, security, cost efficiency, portability, and operability must be expressed as scenarios and evaluated across the whole system. Architecture Decision Records preserve context, alternatives, evidence, and consequences. Risk analysis helps teams prioritise uncertainty, while build-versus-buy assessment considers strategic differentiation, lifecycle cost, skills, compliance, and operational responsibility.

Vendor lock-in may be acceptable when its benefits exceed its risks, but technical, data, operational, commercial, and regulatory dependence should be understood. Team topology and explicit service ownership determine whether microservices can actually be operated independently. Migration should proceed through baseline measurement, carefully selected seams, platform preparation, contract and data management, incremental coexistence, measurement, and retirement of legacy paths. Effective managerial decisions are transparent, evidence-based, reversible where possible, and aligned with both business value and responsible governance.

Key Terms

Architecture evaluation: Systematic assessment of an architecture against requirements, constraints, risks, and expected outcomes.

Quality attribute: A non-functional property such as availability, security, performance, or modifiability.

Quality-attribute scenario: A structured statement specifying a stimulus, environment, response, and measurable result.

Architecture Decision Record (ADR): A concise record of an important architectural decision and its reasoning.

Risk register: A document listing risks, ratings, owners, mitigations, and contingencies.

Build-versus-buy: Evaluation of internal development against purchased or managed alternatives.

Total cost of ownership: The complete lifecycle cost of acquiring, operating, changing, governing, and retiring a solution.

Vendor lock-in: Dependence that makes changing provider costly, risky, or slow.

Portability: The ability to move a workload, data, or capability between environments.

Service ownership: Explicit accountability for a service’s operation, security, cost, and lifecycle.

Stream-aligned team: A team organised around a flow of customer or business value.

Platform team: A team providing internal capabilities that reduce the cognitive load of delivery teams.

Idempotency: The property that repeating an operation produces the same intended effect as performing it once.

Eventual consistency: A model in which distributed replicas or services may temporarily differ but converge later.

Strangler approach: Incremental replacement in which new functionality gradually surrounds and displaces an older system.

Anti-corruption layer: A translation boundary that prevents one system’s model from contaminating another’s model.

Service-level objective: A target for a service quality measure, such as latency or availability.

Cognitive load: The mental effort required for a team to understand, change, and operate a system.

Governance: Structures and practices that direct, constrain, review, and evidence technology decisions.

Review Questions

5 Short Answer Questions

1. What is the difference between a functional requirement and a quality attribute?
2. Name four elements commonly included in an Architecture Decision Record.
3. Why can a service be available but unreliable?
4. Identify three forms of vendor lock-in.
5. What is the purpose of a service catalogue?

5 Long Answer Questions

1. Explain how quality-attribute scenarios improve architecture evaluation. Construct an example for a serverless order-processing system.
2. Discuss the major factors that should be included in a build-versus-buy assessment.
3. Explain how team topology and service ownership influence the success of microservice architecture.
4. Describe an incremental migration framework for moving from a monolith to cloud-native services.
5. Evaluate the benefits and limitations of using managed cloud services in a regulated organisation.

3 Analytical / Application Questions

1. A payment service has excellent latency but experiences duplicate charges after message retries. Which quality attributes and design controls should be reconsidered? Justify your answer.
2. A provider offers a low-cost proprietary database with exceptional performance. Analyse the technical, commercial, operational, and regulatory questions that should be answered before adoption.
3. Design an ADR outline for extracting notification processing from a monolith. Include at least two alternatives, measurable decision criteria, risks, and reversal conditions.

Multiple Choice Questions with Answers

Question 1

Which statement best describes an Architecture Decision Record?

A. A complete implementation manual for every service

B. A concise record of an important decision, its context, alternatives, and consequences

C. A financial invoice for cloud resources

D. A list of only approved programming languages

Correct Answer: B. A concise record of an important decision, its context, alternatives, and consequences

Question 2

Which quality-attribute scenario is the most measurable?

A. The application should be modern

B. The service should be user-friendly

C. During peak traffic, p99 latency shall remain below 800 milliseconds

D. The platform should use advanced technology

Correct Answer: C. During peak traffic, p99 latency shall remain below 800 milliseconds

Question 3

What does a risk score calculated as Likelihood × Impact primarily provide?

A. A precise probability of system failure

B. A prioritisation aid for comparing risks

C. A guaranteed financial loss estimate

D. A replacement for testing

Correct Answer: B. A prioritisation aid for comparing risks

Question 4

Which capability is generally the strongest candidate for building internally?

A. A unique algorithm that differentiates the organisation’s product

B. Routine email delivery

C. Commodity object storage

D. Standard identity federation

Correct Answer: A. A unique algorithm that differentiates the organisation’s product

Question 5

Which is an example of data lock-in?

A. A team uses infrastructure as code

B. A provider offers documented export in an open format

C. Stored data can only be exported through a proprietary, incomplete format

D. A service uses encrypted connections

Correct Answer: C. Stored data can only be exported through a proprietary, incomplete format

Question 6

What is the primary responsibility of a service-owning team?

A. Only writing source code

B. Only approving procurement contracts

C. Accountability for the service’s design, operation, security, cost, and lifecycle

D. Replacing all platform teams

Correct Answer: C. Accountability for the service’s design, operation, security, cost, and lifecycle

Question 7

What is the main purpose of a platform team?

A. To centralise every product decision

B. To provide internal capabilities that reduce delivery teams’ cognitive load

C. To prevent teams from deploying independently

D. To own all business functionality

Correct Answer: B. To provide internal capabilities that reduce delivery teams’ cognitive load

Question 8

Which migration approach gradually replaces parts of an existing system while allowing coexistence?

A. Big-bang replacement

B. Strangler approach

C. Manual rollback only

D. Uncontrolled duplication

Correct Answer: B. Strangler approach

Question 9

Why is idempotency important in event-driven systems?

A. It guarantees that messages are delivered exactly once

B. It ensures repeated processing has the same intended effect as one processing attempt

C. It eliminates the need for monitoring

D. It prevents all provider outages

Correct Answer: B. It ensures repeated processing has the same intended effect as one processing attempt

Question 10

Which cost estimate is most complete for a serverless architecture?

A. Only the number of function invocations

B. Only the monthly database charge

C. Requests, compute, supporting services, transfer, observability, labour, and exit costs

D. Only the initial development budget

Correct Answer: C. Requests, compute, supporting services, transfer, observability, labour, and exit costs