Foundations of Enterprise IT Architecture

Introduction

Enterprise IT architecture is the discipline of describing, governing and evolving the structure of an organisation’s business capabilities, information, applications, technology and governance arrangements. It provides a bridge between organisational strategy and the systems through which strategy is executed. Without such a bridge, technology investment tends to become a collection of locally rational but globally inconsistent decisions: duplicate applications are acquired, information is fragmented, integrations multiply, security controls vary and important business changes become slow and expensive.

Enterprise architecture is not synonymous with technology planning, software design or infrastructure management. It operates across the enterprise and considers how organisational purposes, operating models, processes, information, applications, platforms, people and external relationships fit together. Solution architecture is narrower: it defines the structure of a particular change, product, service or project while ensuring alignment with enterprise direction.

This chapter establishes the conceptual foundation required for later study of architecture frameworks, governance, capability planning, digital transformation and architecture practice.

Learning Objectives

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

1. Define enterprise architecture, solution architecture and related terms.
2. Distinguish architecture from design, implementation and project management.
3. Explain architectural principles, abstraction levels, viewpoints, views and artifacts.
4. Identify major stakeholder groups and analyse their concerns.
5. Explain how business strategy is translated into capabilities, processes and IT systems.
6. Apply architectural reasoning to an organisational case.
7. Evaluate common limitations, governance risks and ethical issues in architecture practice.

1. The Meaning and Scope of Architecture

In ordinary language, architecture refers to the structure and relationships of parts within a whole. In information technology, architecture is a reasoned description of the fundamental organisation of a system, including its components, relationships, governing principles and evolution over time.

A system may be a software product, an information platform, a business unit, an ecosystem of organisations or the enterprise as a whole. The word enterprise does not necessarily mean a large commercial company. A university, government department, hospital, charity or multinational group can each be treated as an enterprise if it has a coherent mission, boundaries, capabilities and stakeholders.

A useful distinction is between:

• Architecture as a description: a model of what exists or is intended.
• Architecture as a practice: the professional activity of analysing, designing, communicating and governing that structure.
• Architecture as a decision process: the selection of structures and technologies under constraints such as cost, risk, regulation and time.

Architecture is therefore both descriptive and normative. It describes the current environment and recommends a desirable future state.

Enterprise Architecture

Enterprise architecture (EA) is the coordinated practice of analysing, planning, communicating and governing enterprise-wide change. It describes the relationship between business direction and the resources, information, applications and technologies used to achieve it.

EA commonly addresses four interrelated domains:

These domains are analytical categories rather than isolated departments. A business capability depends on information, applications and technology. Conversely, a technology constraint may influence what the business can offer. Enterprise architects must therefore examine dependencies across domains.

EA also includes governance: the decision rights, standards, review mechanisms and exception processes that maintain coherence while allowing justified variation. A catalogue of systems without governance is documentation, not effective architecture practice.

Solution Architecture

Solution architecture is the design of the structure and behaviour of a specific solution to a defined business or technical problem. A solution may be a new customer portal, a data-migration programme, an enterprise resource planning implementation or a cloud-based analytics service.

A solution architect typically determines:

• the scope and boundaries of the solution;
• major components and their responsibilities;
• interfaces and information flows;
• quality attributes such as security, availability and performance;
• technology choices and deployment patterns;
• transition arrangements and implementation constraints;
• risks, assumptions and compliance requirements.

Solution architecture is not merely detailed software design. It connects business requirements to an implementable structure and must account for the surrounding enterprise. A technically elegant solution can still be architecturally poor if it duplicates authoritative data, violates regulatory obligations or cannot be operated by the organisation.

Related Architectural Roles

Business architecture focuses on strategy, capabilities, value streams, organisation and operating models. Data architecture concerns the structure, meaning, ownership and movement of information. Application architecture organises software applications and their interactions. Technology or infrastructure architecture addresses platforms, networks, devices and technical environments. Security architecture integrates protection, identity, trust, resilience and compliance across these domains.

A technical architect may concentrate on a platform or technology domain. A domain architect leads architecture for a specialised area such as data or security. An enterprise architect manages cross-domain coherence and strategic alignment. In practice, role names vary between organisations, and responsibilities may overlap.

2. Architecture, Design and Implementation

The terms architecture and design are related but should not be treated as interchangeable.

Architecture establishes the significant structures, boundaries, relationships, principles and decisions that shape a system. Design develops those decisions into more detailed specifications. Implementation constructs, configures and deploys the resulting system. Operations run, monitor and improve it.

The distinction is one of emphasis rather than an absolute boundary. For example, deciding that an organisation will use event-driven integration is an architectural decision; defining the exact event schema and retry algorithm may be detailed design. However, an event schema may become architectural if it is shared by many systems and creates a long-term dependency.

Architecture is concerned especially with decisions that are difficult to reverse, affect many stakeholders or constrain future choices. These are sometimes called architecturally significant decisions. Examples include selecting a system of record, defining identity boundaries, choosing a cloud operating model or adopting a common integration style.

Architecture is also distinct from project management. Project management coordinates scope, schedule, resources and delivery risks. Architecture determines whether the proposed outcome is coherent, sustainable and aligned with enterprise needs. Effective delivery requires both disciplines.

3. Abstraction Levels and Architectural Domains

Architecture must be represented at different levels of abstraction. Abstraction suppresses detail that is not relevant to a particular decision while preserving the relationships needed for understanding.

A strategic view may show capabilities and investment themes. A portfolio view may show applications and their lifecycle. A solution view may show services, interfaces and deployment zones. A detailed design view may show data structures, protocols or infrastructure configurations. Each is valid for a different purpose.

A common progression is:

1. Context level: enterprise boundaries, external actors, regulators and strategic drivers.
2. Conceptual level: major capabilities, business services, information concepts and solution options.
3. Logical level: responsibilities, components, interfaces, data relationships and control structures.
4. Physical or deployment level: products, platforms, networks, locations, configurations and operational environments.

These levels should not be confused with organisational hierarchy. A conceptual model can be more useful to a technical team than an overly detailed physical diagram, while a regulator may require physical evidence of controls.

Current, Target and Transition Architectures

Architecture work normally distinguishes among:

• Current-state architecture: what exists, including undocumented workarounds and actual dependencies.
• Target-state architecture: the desired future arrangement.
• Transition architecture: an intermediate state that enables progressive movement toward the target.

The target state is not automatically the best immediate design. A transition state may be necessary because contracts, skills, data quality, operational risk or funding prevent a direct transformation. Architecture roadmaps connect these states through initiatives, dependencies and decision points.

Capability-Based Thinking

A business capability describes what an organisation must be able to do, not how it currently performs the activity. Examples include customer authentication, claims settlement, research administration and regulatory reporting. Capabilities are more stable than processes or applications and therefore provide a useful link between strategy and investment.

For example, a strategy to provide personalised digital services may require capabilities in identity management, customer insight, consent management and omnichannel interaction. The architecture question is not simply “Which application should be purchased?” but “Which capabilities are required, what maturity do they have, and how should technology support them?”

4. Architectural Principles

Architectural principles are enduring rules and preferences that guide decisions. They provide consistency when detailed requirements are incomplete and help resolve conflicts among projects.

A useful principle normally contains:

• a concise statement;
• a rationale explaining why it matters;
• implications describing the consequences;
• an owner or authority;
• scope and possible exceptions.

Examples include:

Business alignment: Technology investments shall have an explicit relationship to strategic outcomes or mandatory obligations.

Information as an organisational asset: Critical information shall have defined ownership, quality responsibilities, classification and lifecycle controls.

Reuse before acquisition or construction: Existing capabilities and services should be reused where they satisfy requirements without unacceptable risk.

Security and privacy by design: Protection requirements shall be considered from inception rather than added after implementation.

Interoperability through explicit contracts: Systems exchanging information shall use documented interfaces, agreed semantics and controlled change mechanisms.

Least privilege: Users, services and administrators shall receive only the access necessary for legitimate duties.

Resilience proportional to impact: Continuity and recovery controls shall reflect the consequences of service disruption.

Principles are not absolute laws. Applying “reuse before build,” for example, may be inappropriate when an existing system cannot meet legal, safety or scalability requirements. A mature governance process records exceptions, their justification, duration and compensating controls.

5. Stakeholders, Concerns and Viewpoints

A stakeholder is an individual, group or organisation that affects, is affected by, or has an interest in an architecture. Stakeholders may include executives, customers, employees, product owners, developers, operations teams, security specialists, data stewards, auditors, suppliers, regulators and communities.

Stakeholders do not merely need different levels of technical detail; they have different concerns. A chief financial officer may focus on value, cost and financial risk. A chief information security officer may focus on threat exposure and control effectiveness. A service manager may need operational dependencies and support responsibilities. A regulator may require evidence of lawful processing and accountability.

A viewpoint is a specification of the conventions used to construct and interpret a view for particular stakeholder concerns. A view is the representation produced using that viewpoint. An artifact is a concrete work product, such as a capability map, application catalogue, context diagram, data model, interface specification, risk register or roadmap.

The distinction is important:

A single architecture may require multiple views. No single diagram can accurately communicate strategy, application dependencies, security controls and deployment topology at the same time. View management prevents the architecture repository from becoming a collection of disconnected drawings by recording relationships, ownership, version and intended use.

Figure: From stakeholder concerns to architecture views and artifacts.

6. From Business Strategy to IT Systems

The relationship between strategy and IT is not a one-way translation. Strategy establishes intended outcomes, but technology also creates new capabilities and can alter the feasible strategy. Digital platforms, data analytics, automation and artificial intelligence may enable services that were previously impractical. Architecture must therefore support both alignment with strategy and informed strategic innovation.

A practical traceability chain is:

Strategy → outcomes → capabilities → value streams and processes → information and applications → technology services → measurable results.

Suppose a bank adopts a strategic objective to reduce the time required to open a customer account. The objective may be translated into capabilities such as digital identity verification, automated risk assessment, document capture and case management. These capabilities require processes, trusted data, application services, integration and secure technology platforms. Measures might include completion time, abandonment rate, fraud loss, accessibility and customer satisfaction.

Traceability should operate in both directions. Forward traceability asks how an investment supports a strategic objective. Backward traceability asks which strategic objective justifies an application, data store or platform. The second question helps identify technical debt, redundant systems and capabilities that lack a clear owner.

Operating Models and Architecture

An operating model describes how an organisation standardises and integrates its processes to deliver value. A highly standardised organisation may benefit from common platforms and shared data. A diversified organisation may require more local autonomy and integration contracts. Architecture should reflect this choice rather than impose uniformity for its own sake.

Centralisation, federation and decentralisation each have benefits and risks. Centralisation may improve consistency and economies of scale but can create bottlenecks. Federation can respond to local needs but may increase duplication and coordination costs. The appropriate arrangement depends on regulatory conditions, business diversity, risk appetite and organisational capability.

7. Architectural Artifacts and Repositories

Architecture artifacts make reasoning visible and reviewable. Common artifacts include:

• stakeholder maps and problem statements;
• principles and policy statements;
• capability maps and value-stream models;
• organisation and process models;
• information inventories, conceptual data models and lineage maps;
• application portfolios and dependency matrices;
• integration and interface catalogues;
• technology standards and platform reference architectures;
• security and privacy models;
• current-target gap analyses;
• transition roadmaps, decision records and risk registers.

An artifact should have a defined purpose, audience, owner, date, status and level of detail. A visually attractive diagram with no ownership or maintenance process quickly becomes misleading.

An architecture repository is a managed collection of architecture content and its metadata. It may be implemented using specialist tools, modelling platforms, document systems or a combination. The tool is less important than consistency, searchability, version control, traceability and access control.

Architecture description languages and modelling notations can improve precision. However, notation should serve communication. Excessively complex models can exclude stakeholders and encourage documentation for its own sake. The principle of “just enough architecture” is valuable: create the minimum reliable description needed to make sound decisions, while documenting decisions whose consequences are significant.

8. Governance and Decision Rights

Architecture governance establishes who may make which decisions, according to what criteria, with what evidence and through which escalation route. It is not simply a committee meeting. Effective governance integrates architecture into investment planning, procurement, security review, delivery assurance and operational change.

Typical governance mechanisms include:

• architecture principles and mandatory standards;
• review gates for significant initiatives;
• design authorities or architecture boards;
• approved technology and pattern catalogues;
• exception and waiver processes;
• architecture decision records;
• compliance evidence and post-implementation review;
• metrics for risk, reuse, technical debt and business outcomes.

Governance must balance control with delivery speed. If every minor decision requires central approval, teams may bypass governance. If governance is purely advisory, enterprise standards may be ignored. A risk-based model delegates routine decisions and escalates decisions with broad, irreversible or high-impact consequences.

Architecture decisions should be explicit about uncertainty. A decision record may state the context, options considered, selected option, rationale, consequences, assumptions and review date. This is particularly valuable where technologies evolve rapidly or evidence is incomplete.

9. Case Study: Consolidating a University Student-Service Environment

The following is an illustrative case, not a report of a specific university.

Background

A university has grown through mergers and departmental expansion. Students use separate portals for admissions, registration, fees, accommodation and support. Staff maintain several copies of student contact information. Senior management wants a coherent digital student experience and reliable reporting.

Problem

The immediate proposal is to purchase a new “single student portal.” Initial analysis shows that the portal alone will not solve the underlying problems. Identity data is inconsistent, application responsibilities overlap, interfaces are undocumented and several departments have legally or operationally distinct processes. A replacement project without enterprise analysis could reproduce fragmentation behind a new interface.

Analysis

An architecture team identifies stakeholders: students, academic departments, registry staff, finance, student support, information security, privacy officers, technology operations and external regulators. Their concerns differ. Students need simplicity and accessibility; finance needs accurate fee status; privacy officers need lawful processing and controlled disclosure; operations needs supportability and resilience.

The team develops a capability map and identifies capabilities such as student identity, enrolment, payment, accommodation, case management, communication and reporting. It inventories applications and maps data ownership. It discovers three competing records for email address, inconsistent identifiers and several informal spreadsheet integrations.

Architectural principles are agreed: one authoritative source for each critical data element, explicit APIs for system integration, privacy by design, and reuse of common identity services. The team defines a target architecture in which a shared identity service supports authentication, domain systems remain accountable for their data, and the portal consumes governed services rather than becoming a new master database.

Approach and Solution

The university chooses a staged transition:

1. Establish an enterprise identity service and common student identifier.
2. Define data ownership, quality rules and privacy classifications.
3. Publish interfaces for enrolment and fee status.
4. Build a portal that orchestrates services without duplicating authoritative records.
5. Retire redundant departmental interfaces after adoption and service validation.
6. Introduce reporting data products with documented lineage and access controls.

The architecture board approves exceptions where legacy applications cannot yet expose modern interfaces. Temporary integration adapters are documented with owners, risks and retirement dates.

Outcome

The university reduces duplicate data entry and gives students a more consistent entry point. Reporting becomes more reliable because definitions and lineage are documented. The programme takes longer than a portal-only procurement but avoids creating another isolated system. Some local processes remain because they reflect legitimate departmental differences; standardisation is applied where it improves value and control rather than as an end in itself.

Learning Points

First, a visible user-interface problem may be caused by deeper capability, data and governance issues. Second, enterprise architecture does not require every process or system to be identical. Third, authoritative data ownership and transition planning are as important as target-state diagrams. Finally, architecture creates value when it changes decisions and outcomes, not merely when it produces documentation.

10. Challenges, Limitations and Risks

Enterprise architecture is difficult because organisations are socio-technical systems. Formal models cannot fully capture politics, informal work, culture, tacit knowledge or rapidly changing markets.

Stale documentation is a major risk. Architecture repositories must be connected to delivery and operational processes, with ownership and review triggers.

Excessive standardisation can suppress innovation and ignore legitimate local needs. Standards should be justified by outcomes such as interoperability, security or economic value.

Analysis paralysis occurs when teams model indefinitely without making decisions. Time-boxed analysis, explicit decision criteria and incremental architecture can reduce this risk.

False precision arises when diagrams appear authoritative despite uncertain assumptions or poor source data. Models should indicate confidence, status and evidence.

Tool-driven practice occurs when an organisation purchases a repository tool before defining governance, stakeholders and information needs. Tools support practice; they do not create it.

Architecture as a gatekeeping function can damage trust. Architects should engage early, explain trade-offs and provide enabling patterns rather than merely reject proposals.

Vendor influence and lock-in require careful assessment. Procurement should distinguish open standards from marketing claims, evaluate exit costs and consider portability, skills and data access.

11. Ethical, Security and Regulatory Considerations

Architecture decisions distribute benefits, risks and power. They can determine who is visible to an organisation, who receives a service, how decisions are automated and how personal information is used.

Privacy should be addressed through purpose limitation, data minimisation, access control, retention management, transparency and mechanisms for correction. Security architecture should consider confidentiality, integrity, availability, authenticity and accountability. These properties must be related to business impact rather than treated as abstract technical ideals.

Architects working with artificial intelligence must examine data provenance, bias, explainability, human oversight, model drift, security and accountability. An AI component may change the architecture because it introduces training-data dependencies, model-serving infrastructure, monitoring requirements and new failure modes. “AI-enabled” is not itself an architectural justification; the use case, risks and measurable value must be clear.

Regulatory obligations vary by jurisdiction and sector. Architecture teams should involve legal, compliance and risk specialists early, record applicable obligations and avoid treating compliance as a checklist detached from system design. Accessibility is also an architectural concern: interfaces, identity processes and service channels should support users with diverse abilities and circumstances.

12. Contemporary Developments and Professional Practice

Cloud computing has shifted architecture from fixed infrastructure planning toward service selection, platform governance, resilience engineering, cost management and shared responsibility for security. Microservices and APIs can improve independent evolution, but they also introduce distributed-systems complexity, observability needs and operational overhead. Event-driven architectures can reduce temporal coupling but require careful handling of ordering, duplication, replay and semantic consistency.

Platform engineering seeks to provide reusable internal capabilities that make secure and compliant delivery easier for product teams. Data mesh approaches emphasise domain ownership and data products, while still requiring shared governance, interoperability and quality expectations. Zero-trust approaches challenge implicit network trust and require explicit identity, policy and continuous evaluation.

These developments do not eliminate foundational architecture concepts. They increase the importance of clear boundaries, stakeholder concerns, principles, decision records, data ownership and governance. New technology should be assessed in relation to business capabilities, operating constraints and risk—not adopted because it is fashionable.

Best practice can be summarised as follows:

1. Begin with outcomes, capabilities and stakeholder concerns.
2. Establish principles before evaluating detailed products.
3. Separate current, target and transition states.
4. Make assumptions, dependencies and trade-offs explicit.
5. Use multiple views appropriate to different audiences.
6. Treat information ownership, security, privacy and resilience as design concerns.
7. Govern exceptions rather than pretending they do not exist.
8. Connect architecture to investment, delivery and operations.
9. Prefer incremental, evidence-based change over speculative perfection.
10. Measure whether architecture improves outcomes, risk, adaptability or cost.

Chapter Summary

Enterprise IT architecture provides a structured way to connect business strategy with organisational capabilities, information, applications and technology. Enterprise architecture addresses the whole enterprise and includes governance; solution architecture focuses on a particular change while maintaining alignment with enterprise direction. Architecture differs from detailed design and implementation because it concentrates on significant structures, boundaries, relationships and decisions with lasting consequences.

Abstraction levels allow different audiences to understand architecture without unnecessary detail. Current, target and transition architectures support realistic transformation planning. Principles guide decisions, while viewpoints and views ensure that stakeholder concerns are represented appropriately. Artifacts such as capability maps, application catalogues, data models, roadmaps and decision records make architecture visible and governable.

Effective architecture depends on traceability from strategy to capabilities, processes, information, applications, technology and measurable outcomes. It must balance standardisation with autonomy, control with agility, and innovation with security, privacy, accessibility and regulatory responsibility. Architecture creates value not through diagrams alone but through better decisions, reduced unnecessary complexity and improved organisational ability to change.

Key Terms

Enterprise architecture: The coordinated practice of analysing, planning, communicating and governing enterprise-wide structure and change.

Solution architecture: The structure and behaviour of a specific solution to a defined business or technical problem.

Business architecture: The description of strategy, capabilities, value streams, organisation and operating model.

Data architecture: The structure, ownership, meaning, movement and lifecycle of organisational data.

Application architecture: The organisation of software applications, services, responsibilities and interactions.

Technology architecture: The platforms, infrastructure, networks and technical services that enable applications.

Stakeholder: A person, group or organisation that affects, is affected by or is interested in an architecture.

Concern: A matter of interest or importance to a stakeholder.

Viewpoint: Conventions for constructing and interpreting an architecture view.

View: A representation of a system from a particular viewpoint.

Artifact: A concrete architecture work product or document.

Architectural principle: An enduring rule or preference that guides architecture decisions.

Capability: What an organisation must be able to do to achieve its objectives.

Current-state architecture: The documented description of the existing environment.

Target-state architecture: The intended future architecture.

Transition architecture: An intermediate architecture that enables movement toward a target state.

Architecture governance: Decision rights, standards, reviews and controls for maintaining architectural coherence.

System of record: The authoritative source for a defined data domain or information element.

Traceability: The ability to relate strategy, requirements, decisions, implementations and outcomes.

Technical debt: The future cost or constraint created by expedient technical decisions or deferred improvement.

Review Questions

Short Answer Questions

1. Define enterprise architecture and distinguish it from solution architecture.
2. What is the difference between a viewpoint, a view and an artifact?
3. Why are business capabilities useful in architecture planning?
4. State four examples of architectural principles.
5. What is the purpose of a transition architecture?

Long Answer Questions

1. Explain the four commonly recognised enterprise architecture domains and discuss their interdependencies.
2. Describe how an organisation can translate business strategy into IT systems using a traceability chain.
3. Discuss the role of stakeholders and concerns in selecting architecture views.
4. Explain the purpose of architecture governance and evaluate the risks of excessive or insufficient governance.
5. Compare current-state, target-state and transition architectures, using an organisational example.

Analytical / Application Questions

1. An organisation has five customer databases with inconsistent identifiers. Analyse the architectural concerns, principles and transition steps you would recommend.
2. A project proposes a new application that duplicates an existing capability but promises faster delivery. How should an architecture review evaluate the proposal?
3. Design a stakeholder-and-view matrix for a digital public-service platform. Identify at least five stakeholders, their concerns and the architecture views needed to address them.

Multiple Choice Questions with Answers

Question 1

Which statement best defines enterprise architecture?

A. The coding standard used by a software development team

B. The coordinated practice of analysing, planning, communicating and governing enterprise-wide change

C. The procurement of cloud infrastructure for an organisation

D. The detailed design of a single database

Correct Answer: B. The coordinated practice of analysing, planning, communicating and governing enterprise-wide change

Question 2

What is the primary focus of solution architecture?

A. The structure and behaviour of a specific solution to a defined problem

B. The annual financial audit of the enterprise

C. The recruitment structure of the IT department

D. The replacement of all enterprise applications at once

Correct Answer: A. The structure and behaviour of a specific solution to a defined problem

Question 3

Which item is an example of a business capability?

A. PostgreSQL version 16

B. A particular REST endpoint

C. Customer authentication

D. A fibre-optic cable

Correct Answer: C. Customer authentication

Question 4

What is the purpose of an architectural principle?

A. To provide an enduring rule or preference that guides decisions

B. To list every line of production code

C. To replace all stakeholder consultation

D. To guarantee that projects never change scope

Correct Answer: A. To provide an enduring rule or preference that guides decisions

Question 5

A viewpoint is best described as:

A. A person who approves an architecture

B. A physical server location

C. Conventions for constructing and interpreting a view

D. The final deployed version of a system

Correct Answer: C. Conventions for constructing and interpreting a view

Question 6

Which architecture describes an intended future arrangement?

A. Current-state architecture

B. Target-state architecture

C. Incident architecture

D. Retrospective architecture

Correct Answer: B. Target-state architecture

Question 7

Why is a transition architecture useful?

A. It removes the need for a target state

B. It enables progressive movement toward a target when direct change is impractical

C. It describes only obsolete systems

D. It prevents organisations from using interim solutions

Correct Answer: B. It enables progressive movement toward a target when direct change is impractical

Question 8

Which practice most directly supports information accountability?

A. Allowing every application to modify every data element

B. Defining ownership, quality responsibilities, classification and lifecycle controls

C. Storing all information indefinitely

D. Avoiding data models until implementation

Correct Answer: B. Defining ownership, quality responsibilities, classification and lifecycle controls

Question 9

What is a major risk of excessive architecture standardisation?

A. It can suppress innovation and ignore legitimate local needs

B. It always reduces security

C. It makes stakeholder concerns easier to identify

D. It guarantees vendor independence

Correct Answer: A. It can suppress innovation and ignore legitimate local needs

Question 10

Which sequence best represents strategic traceability?

A. Technology → code → procurement → strategy → outcomes

B. Strategy → outcomes → capabilities → processes → information and applications → technology services

C. Applications → vendors → projects → strategy → regulators

D. Roadmap → servers → principles → capabilities → strategy

Correct Answer: B. Strategy → outcomes → capabilities → processes → information and applications → technology services