14. Architecture Governance, Economics and Digital TransformationIntroduction and ContextArchitecture decisions are rarely only technical decisions. Selecting a cloud platform, decomposing a monolith, introducing an integration layer, or standardising observability changes cost structures, operating responsibilities, delivery practices, risk exposure, and organisational behaviour. For this reason, full-stack professionals increasingly participate in decisions that once belonged exclusively to enterprise architects, finance managers, procurement officers, or executive committees. Architecture governance provides the means by which an organisation makes, records, evaluates, and revises architectural decisions. Its purpose is not to impose approval layers on every design choice. Effective governance establishes principles, boundaries, evidence requirements, and decision rights while allowing teams to work autonomously within those boundaries. Poor governance produces either uncontrolled variation and technical debt or excessive bureaucracy that slows delivery without improving outcomes. Architecture economics extends this discussion by examining value, cost, risk, and opportunity. A technically elegant solution may be economically unsuitable if it creates excessive operating expenditure, vendor dependence, or migration complexity. Conversely, a seemingly expensive platform investment may be justified when it reduces duplicated capability and accelerates several product teams. Digital transformation therefore requires a balanced view of technology, economics, organisational readiness, customer value, and sustainable change. This chapter examines governance mechanisms, total cost of ownership, FinOps, risk analysis, build-versus-buy decisions, portfolio roadmaps, legacy modernisation, and socio-technical measures. The central argument is that architecture should be governed as a portfolio of evolving capabilities rather than as a collection of isolated diagrams. Learning ObjectivesAfter studying this chapter, students should be able to: 1. Explain the purpose, scope, and principles of architecture governance. 2. Design proportionate architecture standards, review processes, and decision records. 3. Analyse total cost of ownership and distinguish capital, operating, migration, and opportunity costs. 4. Apply FinOps principles to cloud consumption and engineering decisions. 5. Evaluate build-versus-buy alternatives using strategic, economic, technical, and risk criteria. 6. Construct a portfolio roadmap for modernisation and digital transformation. 7. Analyse legacy migration options and socio-technical outcomes. 8. Identify governance, ethical, regulatory, vendor, security, and organisational risks. 9. Select meaningful metrics that connect architecture activity with business and user outcomes. Architecture Governance as a System of Decision RightsArchitecture governance is the system through which architectural authority is distributed and exercised. It includes principles, standards, reference architectures, review forums, exception processes, documentation practices, controls, and feedback mechanisms. Governance is distinct from architecture management. Architecture management creates and evolves architectural direction; governance ensures that decisions are consistent with agreed objectives and that deviations are visible, justified, and controlled. A useful governance model separates three levels of decision-making. At the enterprise level, leaders establish strategic principles such as information security, data ownership, interoperability, resilience, and responsible technology use. At the platform or domain level, architects define reusable services, technology guardrails, integration patterns, and operating models. At the team level, developers make implementation decisions within those boundaries. The objective is subsidiarity: decisions should be made as close as possible to the work, unless their consequences cross team, domain, regulatory, or strategic boundaries. Governance is effective when it clarifies four questions: - Who has authority to decide?
- What evidence is required?
- Which constraints are mandatory, and which are recommendations?
- How can a decision be challenged, reviewed, or reversed?
A governance system should distinguish principles, standards, patterns, and preferences. A principle expresses a durable direction, such as “protect sensitive data throughout its lifecycle.” A standard specifies a mandatory technical or operational requirement, such as approved encryption mechanisms. A pattern offers a reusable solution to a recurring problem, while a preference reflects an informed but non-binding choice. Confusing these categories causes either weak control or unnecessary rigidity. Proportionality and the Minimum Viable Governance ModelGovernance should be proportional to risk, investment, complexity, and reversibility. A small internal service with low data sensitivity may require peer review and automated checks. A payment service, identity platform, or system processing health information may require formal threat modelling, resilience testing, privacy assessment, financial review, and executive risk acceptance. A minimum viable governance model normally includes: - a concise set of architectural principles;
- an inventory of systems, interfaces, owners, and critical dependencies;
- lightweight architecture decision records;
- automated policy and security checks in delivery pipelines;
- a review mechanism for high-impact decisions;
- an explicit exception and sunset process; and
- periodic measurement of outcomes rather than document volume.
The quality of governance should not be judged by the number of review meetings or pages of documentation. More meaningful indicators include the time required to make decisions, the percentage of material risks identified before production, the rate of successful exceptions, and the reduction of duplicated capabilities. Standards, Reference Architectures, and Architecture ReviewsStandards create a common technical language. They may cover API conventions, identity, observability, logging, data classification, deployment, accessibility, testing, and service reliability. A standard should state its purpose, scope, mandatory requirements, approved alternatives, owner, review date, and consequences of non-compliance. Standards without ownership become obsolete documents; standards without exceptions become obstacles to innovation. Reference architectures provide tested arrangements of components for recurring contexts. For example, a reference architecture for a secure web application may include an identity provider, web application firewall, service layer, managed database, secrets management, central logging, monitoring, backup, and deployment pipeline. It is not a mandatory design for every application. Rather, it reduces decision effort and makes important concerns visible. Architecture reviews should be treated as risk and learning activities, not ceremonial approvals. A useful review asks whether the proposed design: 1. supports the intended business capability and user experience; 2. meets security, privacy, resilience, accessibility, and regulatory obligations; 3. fits the organisation’s operating and support capabilities; 4. has a credible cost model and exit strategy; 5. manages dependencies and migration consequences; and 6. provides evidence through prototypes, tests, benchmarks, or operational experience. The review outcome may be approval, conditional approval, redesign, deferral, or acceptance of a documented risk. A decision record should explain the context, alternatives considered, decision, consequences, assumptions, and review trigger. This is more valuable than a diagram that merely depicts the chosen components. The Economics of ArchitectureArchitecture economics examines the full consequences of an architectural choice. The most common error is to compare purchase prices while ignoring lifecycle costs. Total cost of ownership (TCO) includes all significant costs incurred to acquire, build, operate, change, secure, govern, and retire a solution. A simplified TCO model is: TCO = acquisition and implementation costs + operating costs + change and integration costs + risk and compliance costs + retirement costs − measurable residual value Costs may be direct or indirect. Direct costs include licences, cloud consumption, infrastructure, staff, support contracts, testing, migration, and training. Indirect costs include productivity loss, duplicated data, delays caused by dependencies, vendor lock-in, outages, and the opportunity cost of maintaining an obsolete platform. A credible comparison should state the time horizon, usually three to seven years depending on the decision, and distinguish one-time from recurring costs. Economic evaluation should consider more than the lowest TCO. Relevant criteria include: - time to value and speed of delivery;
- adaptability to uncertain requirements;
- security and regulatory exposure;
- reliability and operational burden;
- skills availability;
- reversibility and exit cost;
- strategic differentiation; and
- effect on customer and employee experience.
A net present value analysis may be appropriate for major investments. Future costs and benefits are discounted to reflect the time value of money. However, financial precision should not create false certainty. Estimates are assumptions, not facts. Scenario analysis—optimistic, expected, and adverse—usually provides a more honest basis for decision-making. FinOps and Cloud EconomicsFinOps is an operating discipline that brings finance, engineering, product, and business teams together to create accountability for variable technology consumption. It is not merely a cost-cutting programme. Its purpose is to maximise business value from cloud and platform expenditure while preserving reliability, security, and delivery capability. FinOps commonly follows a cycle of inform, optimise, and operate. In the inform stage, consumption is made visible through tagging, allocation, dashboards, budgets, and unit costs. In the optimise stage, teams remove waste, right-size resources, select suitable purchasing models, improve architecture, and negotiate commitments. In the operate stage, spending targets and value measures become part of normal product planning and governance. Useful measures include cost per transaction, cost per active customer, cost per API call, environment utilisation, idle resource percentage, forecast variance, and committed-use coverage. These measures must be interpreted carefully. Reducing cost per transaction by degrading latency or availability is not genuine value creation. A mature team considers cost alongside service-level objectives, security, customer satisfaction, and developer productivity. Cloud economics also changes the relationship between architecture and finance. Elasticity can reduce the need for large up-front capacity, but poorly governed elasticity can create unpredictable expenditure. Managed services may reduce operational labour while increasing dependence on a provider. Multi-cloud may improve negotiating power or resilience in specific situations, but it can also duplicate skills, tools, and operational complexity. The economically appropriate choice depends on workload characteristics and strategic needs, not on slogans. Build, Buy, Subscribe, or Partner?The build-versus-buy decision is a strategic choice about where the organisation should create differentiation and where it should consume a capability as a service. “Build” may mean developing software internally; “buy” may mean purchasing a package; “subscribe” may mean using a cloud or software-as-a-service product; and “partner” may mean obtaining a jointly delivered capability. A decision matrix should evaluate at least the following dimensions: | Criterion | Questions | |---|---| | Strategic value | Does the capability differentiate the organisation or merely enable operations? | | Functional fit | Can the alternative support current and foreseeable requirements? | | Economics | What are TCO, cash-flow, scaling, and exit implications? | | Time | How quickly can usable capability be delivered? | | Control | Are data, configuration, roadmap, and service levels sufficiently controllable? | | Risk | What are the security, continuity, compliance, and supplier risks? | | Capability | Does the organisation possess the skills to build and operate it? | | Integration | How easily can it connect to existing systems and data? | Build is attractive when requirements are distinctive, intellectual property is strategic, or available products cannot meet important constraints. Buy or subscribe is often preferable for commodity functions such as routine collaboration, payroll, or standard identity features, provided privacy, integration, service levels, and exit are acceptable. A hybrid approach is frequently rational: purchase a core platform and build differentiating workflows around it. Common mistakes include comparing build cost with licence cost only, assuming a product’s feature list proves suitability, ignoring implementation and data migration, and failing to negotiate data portability. Procurement should assess not only the initial contract but also renewal increases, integration charges, premium support, audit rights, termination assistance, and the supplier’s financial and technical viability. Modernisation, Legacy Systems, and Portfolio RoadmapsLegacy systems are not necessarily worthless. They may embody reliable business rules, historical data, regulatory evidence, and organisational knowledge. Their difficulty often arises from obsolete skills, fragile interfaces, insecure infrastructure, high change cost, and inability to support new customer expectations. Modernisation should therefore begin with business capabilities and risk, not with a presumption that every old system must be replaced. A portfolio assessment maps applications against business value, technical health, change cost, risk, and strategic relevance. Typical strategies include: - Retain: continue operating when value and risk remain acceptable.
- Retire: remove unused or duplicated capability.
- Rehost: move with minimal code change, often to new infrastructure.
- Replatform: adopt a managed runtime or database with limited redesign.
- Refactor: improve internal structure while preserving behaviour.
- Rearchitect: substantially alter the system’s architecture.
- Replace: adopt a new package or service.
- Rebuild: create a new solution when existing foundations are unsuitable.
These terms describe options, not a maturity ladder. Rehosting may be sensible as a temporary risk reduction, while refactoring may be justified for a frequently changing service. Rewriting a large system without incremental validation is particularly risky because undocumented rules are easily lost. A portfolio roadmap sequences change according to dependencies, risk reduction, value, organisational capacity, and learning. It should identify transition states rather than only a distant target architecture. A strong roadmap includes funding assumptions, owners, measurable outcomes, migration waves, coexistence arrangements, decommissioning dates, and decision points at which the strategy may change. The strangler approach is one incremental modernisation pattern. New functionality is placed behind a controlled interface while selected functions are gradually moved from the legacy system. Anti-corruption layers prevent legacy data models and assumptions from contaminating the new design. Parallel operation, reconciliation, feature flags, and reversible releases reduce risk, although they create temporary duplication and operational complexity. Digital Transformation as Socio-Technical ChangeDigital transformation is broader than technology replacement. It changes how value is created, how decisions are made, how employees work, and how customers interact with an organisation. A transformation programme can fail even when its software is technically sound if incentives, skills, processes, governance, or leadership remain unchanged. A socio-technical perspective examines at least five dimensions: technology, people, process, structure, and culture. For example, introducing continuous delivery requires automation and suitable architecture, but also smaller batches, product ownership, risk-based controls, learning from failure, and cooperation between development, operations, security, and finance. Transformation portfolios should connect investment to outcomes such as reduced customer effort, faster fulfilment, improved resilience, reduced regulatory exposure, or increased employee productivity. Outputs—applications deployed, APIs created, or training sessions completed—are useful progress indicators but are not outcomes themselves. Metrics That MatterA balanced measurement system combines leading and lagging indicators. Technical delivery measures may include deployment frequency, lead time for changes, change failure rate, mean time to restore service, defect escape rate, and platform adoption. Economic measures may include TCO trend, unit cost, forecast accuracy, and benefits realisation. User measures may include task completion, accessibility, satisfaction, retention, and complaint volume. Organisational measures may include cognitive load, psychological safety, skills coverage, and dependency waiting time. Metrics can distort behaviour. If teams are judged only by deployment frequency, they may release trivial changes. If cloud cost is the dominant target, teams may underinvest in resilience. If incident counts are used punitively, reporting will decline. Metrics should therefore be interpreted as signals within a context and reviewed for unintended consequences. A small set of meaningful measures is more valuable than a large dashboard disconnected from decisions. An Illustrative Case: Modernising a Regional Insurance PlatformBackgroundConsider an illustrative insurer, Northbridge Mutual, whose policy administration system was developed over two decades. It supports critical billing and claims processes but uses batch interfaces, a proprietary database, and specialist skills that are becoming difficult to recruit. Customers increasingly expect digital quotations, real-time claim updates, and self-service changes. Situation and ProblemThe executive team proposes replacing the entire system within eighteen months. The initial business case compares a new commercial package with the apparent cost of retaining the legacy platform. Architects identify that the legacy system contains undocumented underwriting rules and interfaces with regulators, brokers, finance, and document services. A complete replacement would create substantial data migration and business continuity risk. AnalysisA cross-functional team maps capabilities, dependencies, risks, and customer journeys. It discovers that the highest customer impact lies in quotation and claim-status services, while the stable billing engine has relatively low change demand. TCO modelling includes package configuration, integration, migration, parallel operation, training, data cleansing, support, and retirement. Scenario analysis shows that a big-bang replacement has attractive long-term simplicity but a high probability of delay and operational disruption. The team also assesses cloud consumption. A proposed event-driven design would improve responsiveness but could create uncontrolled message and storage costs unless workloads are measured by transaction and retention policy. FinOps controls, tagging, budgets, and architectural cost reviews are added to the design. Approach and StrategyThe board approves a staged roadmap. First, the organisation creates an API façade and a canonical customer view without changing core policy calculations. Second, new digital quotation and claim-status capabilities are built around carefully governed interfaces. Third, selected low-risk policy functions are replatformed. Billing remains temporarily on the legacy system, protected by reconciliation and monitoring. A commercial package is purchased for document generation because it is not a strategic differentiator, while customer decisioning remains internally controlled because it embodies competitive underwriting practices. Governance is deliberately lightweight. Product teams make routine design decisions using approved patterns. A monthly architecture forum reviews only decisions involving regulated data, major supplier commitments, cross-domain dependencies, or material resilience risk. Architecture decision records document alternatives and assumptions. Exceptions expire after twelve months unless renewed with evidence. OutcomeThe programme does not eliminate the legacy platform immediately. Instead, it reduces exposure by isolating high-change customer journeys, improves observability, and creates a controlled path for future replacement. Business leaders receive clearer cost and risk information, while engineering teams gain autonomy within explicit guardrails. The case demonstrates that transformation value may arise from reducing uncertainty and increasing strategic options, not only from completing a final-state migration. Learning PointsThe case illustrates five principles: modernisation should be capability-led; migration risk is often greater than coding risk; commercial products should be selected according to strategic differentiation; cloud cost requires engineering accountability; and governance is most useful when it makes consequential choices visible without reviewing every local decision. Risks, Constraints, and Professional ResponsibilitiesArchitecture governance can become bureaucratic when every decision requires a committee, when standards are written without delivery experience, or when compliance evidence is collected after implementation. It can also become ineffective when exceptions are informal, ownership is unclear, or senior leaders bypass controls for urgent projects. The remedy is not the absence of governance but a clear risk-based operating model. Important risks include vendor lock-in, concentration of cloud providers, data residency violations, insecure third-party components, algorithmic bias, privacy loss, shadow technology, cost overrun, skills depletion, and failure to retire replaced systems. Technical debt should be treated as a managed liability. It is not always harmful; deliberate debt can accelerate learning or market entry. Unmanaged debt becomes dangerous when its service cost, risk, and repayment implications are invisible. Ethical governance requires attention to affected stakeholders, not only paying customers. Architecture choices may determine who can access a service, whether a decision can be explained, how long personal data is retained, and whether employees are subjected to disproportionate surveillance. Privacy by design, accessibility, human oversight of consequential automated decisions, data minimisation, and transparent accountability should be incorporated early. Regulatory obligations vary by jurisdiction and industry, but common professional responsibilities include protecting confidential information, maintaining reliable records, controlling access, testing resilience, retaining evidence, and ensuring that supplier arrangements do not remove organisational accountability. Compliance is a baseline, not a substitute for sound engineering judgement. Emerging Directions and Best PracticesArchitecture governance is increasingly supported by policy as code, automated compliance checks, software bills of materials, infrastructure as code, platform engineering, internal developer portals, and continuous architecture validation. These tools can detect prohibited configurations, expose dependencies, estimate cloud cost, and provide approved self-service paths. Automation, however, can reproduce flawed policies at scale. Human review remains necessary for ambiguous, high-impact, or ethically sensitive decisions. Artificial intelligence is entering portfolio analysis, code modernisation, incident prediction, cost anomaly detection, and architecture documentation. Its outputs should be treated as advisory because generated recommendations may omit business constraints, reproduce bias, expose sensitive information, or be confidently incorrect. Organisations should establish data handling rules, review requirements, provenance expectations, and accountability for AI-assisted decisions. Effective practice can be summarised as follows: - govern decisions and outcomes, not document volume;
- place authority near delivery while escalating cross-cutting risks;
- publish a small, owned, regularly reviewed set of principles and standards;
- automate repeatable controls in engineering workflows;
- use TCO and scenario analysis rather than purchase price alone;
- make cloud cost visible through meaningful unit economics;
- preserve exit options in supplier and platform decisions;
- modernise incrementally where business rules and migration risks are uncertain;
- connect technical metrics with customer, financial, and organisational outcomes; and
- treat exceptions, debt, and assumptions as explicit, reviewable information.
Chapter SummaryArchitecture governance establishes decision rights, principles, standards, review processes, exceptions, and evidence requirements. Its objective is controlled adaptability rather than centralised approval. Proportionate governance enables teams to decide locally while escalating decisions that create significant security, regulatory, financial, or cross-domain consequences. Architecture economics evaluates lifecycle value through total cost of ownership, risk, opportunity cost, time to value, reversibility, and strategic differentiation. FinOps makes variable cloud expenditure visible and links consumption to engineering and business outcomes. Build-versus-buy analysis must consider integration, skills, supplier dependence, exit cost, and strategic uniqueness rather than licence price alone. Legacy modernisation is best approached as a portfolio problem. Retain, retire, rehost, replatform, refactor, rearchitect, replace, and rebuild are context-dependent strategies. Incremental migration, transition architectures, and capability-based roadmaps can reduce disruption and preserve learning. Digital transformation succeeds when technology, people, processes, structures, and culture change together. Meaningful socio-technical metrics connect delivery, cost, reliability, customer value, and organisational health. Ethical, regulatory, security, and professional responsibilities must remain visible throughout the transformation. Key TermsArchitecture governance: The system of principles, authority, controls, reviews, and decisions used to direct and oversee architecture. Architecture decision record: A concise record of context, alternatives, decision, consequences, assumptions, and review conditions. Reference architecture: A reusable, tested model showing how components may be arranged for a recurring context. Architecture principle: A durable statement that guides architectural choices. Technical standard: A mandatory or formally approved requirement for technology, design, or operation. Exception: An authorised deviation from a principle or standard, normally with justification and expiry. Total cost of ownership: The complete lifecycle cost of acquiring, building, operating, changing, securing, and retiring a solution. Opportunity cost: The value of alternatives forgone when resources are committed to a particular choice. FinOps: A collaborative discipline for managing cloud consumption and maximising technology value. Unit economics: Financial measurement of cost or value per meaningful business or technical unit. Build-versus-buy analysis: A structured comparison of internally creating and externally obtaining a capability. Vendor lock-in: Dependence on a supplier that makes switching technically, financially, or operationally difficult. Legacy system: An existing system whose technology, skills, interfaces, or constraints hinder desired change. Replatforming: Moving a system to a different runtime or managed foundation with limited redesign. Refactoring: Improving internal structure without intentionally changing externally observable behaviour. Strangler pattern: Incrementally replacing functions of a legacy system while the old and new systems coexist. Portfolio roadmap: A sequenced plan connecting capabilities, investments, dependencies, risks, and outcomes. Socio-technical metric: A measure combining technical performance with human, organisational, customer, or business effects. Policy as code: Machine-readable rules automatically checked or enforced in technology workflows. Benefits realisation: The discipline of verifying that an investment produces its intended measurable outcomes. Review QuestionsShort Answer Questions1. What is the difference between architecture management and architecture governance? 2. Why should governance be proportional to risk and reversibility? 3. What cost categories should be included in a TCO analysis? 4. What are the three broad stages commonly associated with FinOps? 5. Explain the purpose of an architecture decision record. Long Answer Questions1. Discuss how principles, standards, reference architectures, and exceptions work together in an effective governance model. 2. Explain the build-versus-buy decision framework, including strategic differentiation, TCO, supplier risk, and exit considerations. 3. Compare rehosting, replatforming, refactoring, rearchitecting, and replacement as legacy-modernisation strategies. 4. Analyse why digital transformation should be understood as socio-technical change rather than technology replacement. 5. Explain how a portfolio roadmap can reduce migration risk while maintaining business value and organisational learning. Analytical / Application Questions1. An organisation has rising cloud expenditure but stable customer demand. Design a FinOps investigation that distinguishes necessary growth from waste and proposes suitable metrics. 2. A government agency wants to replace a critical legacy system in one release. Using the chapter’s frameworks, evaluate the risks and propose an alternative roadmap. 3. A team proposes buying a SaaS platform containing sensitive customer data. Prepare a decision analysis covering governance, privacy, TCO, supplier risk, integration, and exit strategy. 22. Multiple Choice Questions with AnswersQuestion 1Which governance arrangement best reflects the principle of subsidiarity? A. A central architecture board approves every technical decision. B. Teams decide locally within guardrails, while cross-domain and high-risk decisions are escalated. C. Suppliers make all architecture decisions because they own the technology. D. No architectural decisions are documented to preserve delivery speed. Correct Answer: B. Teams decide locally within guardrails, while cross-domain and high-risk decisions are escalated. Question 2Which item is most clearly an example of an architecture principle rather than a standard? A. All production secrets must be stored in the approved secrets manager. B. Applications must use the organisation’s approved API gateway. C. Sensitive data must be protected throughout its lifecycle. D. Logging agents must send events in the specified JSON format. Correct Answer: C. Sensitive data must be protected throughout its lifecycle. Question 3Why can a lower licence price fail to indicate a lower TCO? A. Licence prices are always unrelated to operating costs. B. TCO also includes integration, migration, support, training, risk, and retirement costs. C. TCO excludes all indirect costs by definition. D. A lower licence price automatically increases cloud consumption. Correct Answer: B. TCO also includes integration, migration, support, training, risk, and retirement costs. Question 4A cloud team reduces infrastructure cost by weakening availability and increasing incidents. Which conclusion is most appropriate? A. The team has necessarily improved FinOps maturity. B. Cost reduction is always more important than reliability. C. The team should evaluate cost alongside service objectives and business value. D. FinOps applies only to finance departments. Correct Answer: C. The team should evaluate cost alongside service objectives and business value. Question 5Which situation most strongly supports building a capability internally? A. The capability is a routine commodity with many mature providers. B. The capability contains strategic differentiation that is poorly supported by available products. C. The organisation wants to avoid all responsibility for operations. D. The purchase contract has a low initial price. Correct Answer: B. The capability contains strategic differentiation that is poorly supported by available products. Question 6What is the primary purpose of an anti-corruption layer during modernisation? A. To prevent all communication between old and new systems. B. To ensure that legacy data models and assumptions do not contaminate the new design. C. To eliminate the need for data reconciliation. D. To convert every legacy component into a microservice immediately. Correct Answer: B. To ensure that legacy data models and assumptions do not contaminate the new design. Question 7Which metric combination best represents a socio-technical view of transformation? A. Lines of code, number of classes, and database tables. B. Number of meetings, pages of documentation, and review attendance. C. Deployment performance, customer effort, service reliability, and team cognitive load. D. Number of vendors, programming languages, and architectural diagrams. Correct Answer: C. Deployment performance, customer effort, service reliability, and team cognitive load. Question 8An architecture exception should generally include which control? A. Permanent approval without justification. B. A justification, named owner, risk treatment, and review or expiry date. C. Removal of the relevant standard from the organisation. D. Informal approval by an unrecorded conversation. Correct Answer: B. A justification, named owner, risk treatment, and review or expiry date. Question 9Which modernisation choice moves a system to a managed runtime with limited redesign? A. Retirement B. Replatforming C. Rebuilding D. Rewriting all business rules Correct Answer: B. Replatforming Question 10Why is a big-bang replacement particularly risky for a poorly documented legacy system? A. It guarantees lower operating expenditure. B. It may lose undocumented business rules while concentrating migration and continuity risk in one release. C. It prevents the use of commercial software. D. It eliminates the need for stakeholder participation. Correct Answer: B. It may lose undocumented business rules while concentrating migration and continuity risk in one release.
|
