Section 1: Preliminary Phase Overview
The Preliminary Phase is the foundation upon which all subsequent ADM activity rests. It answers the critical question: Is this organisation ready to do architecture work? Without proper preparation, even the most rigorous ADM execution will produce outputs that nobody adopts, no governance body enforces, and no stakeholder understands.
The phase of the ADM that prepares an organisation to undertake successful enterprise architecture projects. It defines where, what, why, who, and how architecture work will be done in the enterprise, and establishes the Architecture Capability required to support the architecture practice. — The Open Group, TOGAF Standard
Position in the ADM
The Preliminary Phase is deliberately positioned before Phase A (Architecture Vision) and is not assigned a letter. It precedes the iterative ADM cycle. While all other phases (A through H) are repeated cyclically as the enterprise evolves, the Preliminary Phase establishes the enduring capability that all those cycles depend on. However, the Preliminary Phase is revisited whenever the scope, context, or governance of the architecture practice changes significantly — for example, when the organisation merges with another, adopts a new regulatory regime, or substantially changes its strategic direction.
Six Key Purposes
- Define the scope — Determine which part of the enterprise the architecture practice will cover.
- Establish architecture principles — Define the governing principles that all architecture work must respect.
- Tailor the ADM — Adapt TOGAF to the specific context, culture, and constraints of the organisation.
- Establish governance — Define who has authority over architecture decisions and how compliance is enforced.
- Define team and organisation — Identify who will perform architecture work and how the architecture team is structured.
- Set up the Architecture Repository — Create the storage infrastructure for all architecture artefacts.
Inputs and Outputs
| Inputs | Outputs |
|---|---|
| TOGAF Standard (all parts) | Architecture Principles (documented, categorised) |
| Other relevant architecture frameworks (Zachman, FEAF, DODAF) | Tailored ADM — adapted to the organisation's context |
| Business strategy and goals | Architecture Governance Framework — structures, processes, roles |
| IT strategy and IT policies | Architecture team and organisation — defined roles, responsibilities |
| Existing architecture documentation | Architecture Repository — initial structure established |
| Organisational structure and culture | Re-usable architecture building blocks (initial set) |
| Regulatory and legal environment | Architecture Capability Assessment |
| Board-level commitment and sponsorship | Request for Architecture Work (triggers Phase A) |
Part 1 exams frequently ask: "Which of the following is NOT an output of the Preliminary Phase?" The most common traps are: Architecture Vision (output of Phase A, not Preliminary), Architecture Definition Document (output of Phases B/C/D), and Statement of Architecture Work (also Phase A). The Preliminary Phase outputs are foundational structures — principles, governance, the tailored ADM — not deliverables describing specific architecture content.
Section 2: Tailoring the ADM
TOGAF is explicitly designed to be tailored. The standard describes a comprehensive method, but no organisation needs or should implement every step, template, and technique verbatim. Tailoring is the act of adapting the ADM — its phases, steps, inputs, outputs, and techniques — to reflect the organisation's specific circumstances without losing the fundamental rigour and traceability that TOGAF provides.
The process of adapting the ADM and the TOGAF framework to suit the specific needs of an organisation, including integrating it with other frameworks, adjusting the depth and breadth of phases, and modifying terminology to match the organisation's culture and existing processes.
Integrating Other Frameworks
TOGAF is not designed to exist in isolation. Most organisations already use other management frameworks, and the Preliminary Phase is where the architect decides how TOGAF co-exists, integrates, or is subordinated to those frameworks. The following are the most commonly cited in the OGEA-103 exam:
Part 2 scenarios often place you in an organisation that "already uses COBIT" or "is heavily Agile." The correct response is never to abandon TOGAF — instead, you tailor the ADM in the Preliminary Phase to integrate with the existing framework. ITIL aligns with service management outputs; COBIT aligns with governance and control objectives; Agile/SAFe requires mapping ADM iterations to sprint boundaries.
Scope Dimensions for Tailoring
When tailoring the ADM, the architect must explicitly define four scope dimensions. These also appear in Phase A scoping decisions:
| Dimension | Question it Answers | Example Values |
|---|---|---|
| Breadth | Which part of the enterprise is covered? | Whole enterprise / a single division / a geography |
| Depth | How detailed will the architecture be? | Conceptual / logical / physical; segment / capability |
| Time period | What time horizon does the architecture address? | 3 years / 5 years / 10 years |
| Architecture domains | Which BDAT domains are in scope? | All four / Business and Data only / Technology only |
Tailoring for Agile EA
Many organisations run agile delivery at scale and ask: "How can TOGAF work at sprint speed?" The ADM is designed to be iterative and adaptive. Key tailoring approaches for agile contexts include:
- Compress phases: Run Phases A–D concurrently at a light depth to produce a "just enough" architecture view before PI planning.
- Lightweight artefacts: Use architecture canvases and one-page views instead of full ADDs.
- Continuous iteration: Each PI or sprint boundary can trigger a mini-ADM cycle for impacted components.
- Embedded architects: Architects join delivery teams rather than working in a separate function.
- Architecture Runway: Maintain 1–2 PI ahead of delivery so teams never wait for architectural decisions.
Section 3: Architecture Principles in Depth
Architecture Principles are among the most heavily tested topics in the OGEA-103 exam. They are the primary output of the Preliminary Phase and the governing rules that constrain all architecture decisions throughout the ADM lifecycle. Getting principles right is the difference between an architecture practice that produces coherent, consistent designs and one that drifts into ad hoc decision-making.
Five Characteristics of a Good Principle
TOGAF defines five qualities that every well-formed architecture principle must exhibit. Examiners test these both in Part 1 (recall) and Part 2 (scenario evaluation — "which principle statement best meets the five criteria?"):
The Four-Part Principle Format
Every architecture principle must be documented using a four-part structure. This is a high-frequency exam topic — examiners present a principle component and ask you to identify which part it represents:
| Component | Purpose | Example |
|---|---|---|
| Name | A short, memorable label that conveys the essence. Typically 2–5 words. | "Data is an Asset" |
| Statement | A clear, unambiguous declaration of the fundamental rule. Should stand alone without context. | "Data is a valuable corporate resource; it has real, measurable value." |
| Rationale | The business reason — why this principle exists and why it matters. Links to business strategy. | "Information is the foundation of all business decisions. Managing it well enables better outcomes and reduces cost." |
| Implications | The practical consequences — what must be done, what changes, what resources are required. The most detailed and longest section. | "All data must be classified; a Data Steward must be appointed; a data dictionary must be maintained." |
The most commonly confused components are Statement vs Implications. Remember: the Statement is the aspirational declaration (what we believe); the Implications are the mandatory consequences (what we must do). If the text says "must," "shall," or "will be required to," it is almost certainly an Implication. The Rationale always explains why — look for business justification language.
Principle Categories: BDAT
Architecture principles align with the four TOGAF architecture domains. Each category governs a different layer of the enterprise:
| Category | Domain | Typical Focus Areas | Example Principles |
|---|---|---|---|
| Business Principles | Business Architecture | Organisational strategy, customer service, process efficiency | Business Continuity; Service Orientation; Common Use Applications |
| Data Principles | Data Architecture | Data ownership, quality, privacy, sharing | Data is an Asset; Data Trustee; Data Accessibility; Data Security |
| Application Principles | Application Architecture | Integration, independence, ease of use | Technology Independence; Ease of Use; Common Use; Requirements-Based Change |
| Technology Principles | Technology Architecture | Standards, interoperability, security, scalability | Interoperability; Vendor Neutrality; Responsive Change Management; Security |
20 Canonical Example Principles
The TOGAF Standard provides a widely cited set of example principles across all four domains. The following table summarises 20 of the most important ones for the exam:
| # | Principle Name | Domain | Core Statement / Intent |
|---|---|---|---|
| 1 | Business Continuity | Business | Enterprise operations must continue regardless of system events; continuity is non-negotiable. |
| 2 | Common Use Applications | Business | Development of applications used across the enterprise is preferred over solutions that are only provided to specific entities. |
| 3 | Service Orientation | Business | The enterprise is oriented toward services, both in what it delivers and how it structures its internal operations. |
| 4 | Compliance with Law | Business | Enterprise IT must meet all legal and regulatory obligations. |
| 5 | IT Responsibility | Business | The IT function is responsible for owning and implementing IT processes and infrastructure. |
| 6 | Data is an Asset | Data | Data is a valuable corporate resource; it has real, measurable value. |
| 7 | Data is Shared | Data | Users of data have access to all data not explicitly prohibited by access controls. |
| 8 | Data is Accessible | Data | Data is accessible for users to perform their functions. |
| 9 | Data Trustee | Data | Each data element has a trustee accountable for data quality. |
| 10 | Common Vocabulary and Data Definitions | Data | Data is defined consistently throughout the enterprise; definitions are understandable and available to all users. |
| 11 | Data Security | Data | Data is protected from unauthorised use and disclosure. |
| 12 | Technology Independence | Application | Applications are independent of specific technology choices, enabling technology changes without impacting business operations. |
| 13 | Ease of Use | Application | Applications are easy to use; the underlying technology is transparent so users can focus on their tasks. |
| 14 | Requirements-Based Change | Application | Only in response to business needs are changes to applications made. |
| 15 | Responsive Change Management | Technology | Changes to the IT environment are implemented in a timely manner. |
| 16 | Control Technical Diversity | Technology | Diversity of technology is controlled to minimise the non-trivial cost of maintaining expertise in and connectivity between multiple processing environments. |
| 17 | Interoperability | Technology | Software and hardware should conform to defined standards that promote interoperability, portability, and scalability. |
| 18 | Vendor Neutrality | Technology | The enterprise does not create a dependency on specific technology vendors; proprietary solutions are avoided. |
| 19 | Security | Technology | All IT systems must be appropriately secured; access is controlled and monitored. |
| 20 | Change Based on Need | Technology | Only changes mandated by business need are made to the IT environment, preventing technology churn. |
Principle Conflicts and Resolution
In practice, principles can conflict. For example, "Ease of Use" may conflict with "Security" — a highly secure system with complex authentication may be hard to use. The Preliminary Phase must establish how conflicts are resolved. TOGAF recommends:
- Prioritisation: Assign a relative priority to principles so that when conflicts arise, the higher-priority principle governs.
- Escalation path: Define who has authority to adjudicate conflicts — typically the Architecture Board.
- Exception process: Define a formal waiver or exception process for cases where a principle cannot be upheld, with documented rationale and compensating controls.
- Documented resolution: All conflict resolutions become architecture decisions, stored in the Architecture Repository.
Part 2 scenarios often describe a situation where two principles conflict and ask what the architect should do. The TOGAF-correct answer almost always involves: (1) escalating to the Architecture Board, (2) documenting the conflict and the resolution rationale, and (3) recording the decision in the Architecture Repository. Never abandon a principle silently — it must go through governance.
Section 4: Establishing Architecture Capability
The Architecture Capability Framework provides guidance on how to set up and run an architecture practice within an organisation. It is the organisational and operational infrastructure that enables the ADM to function. Without a defined capability, architecture work is ad hoc, inconsistent, and easily marginalised.
A structured set of reference materials for establishing and operating an architecture function within an enterprise. It covers: Architecture Board, Architecture Contracts, Architecture Governance, Architecture Maturity Models, Architecture Skills Framework, and the Architecture Repository.
The Architecture Board
The Architecture Board is the primary governance body for the enterprise architecture practice. It is a cross-organisational group responsible for overseeing the implementation and management of the enterprise architecture. Key responsibilities:
- Approve architecture principles
- Endorse major architecture decisions
- Oversee architecture compliance
- Manage architecture contracts
- Issue waivers and exceptions
- Resolve principle conflicts
- Conduct architecture reviews
- Ensure consistency across domains
- Manage the Architecture Repository
- Communicate architecture decisions
- Advocate architecture value to leadership
- Report on compliance metrics
The Architecture Board typically comprises: the Chief Architect (chair), domain architects (business, data, application, technology), and representatives from key business units and IT functions. Board size should be manageable — typically 8–12 members — to enable effective decision-making.
Architecture Repository
The Architecture Repository is the storage and management system for all architecture artefacts. It is structured into six classes of artefact:
| Class | Content |
|---|---|
| Architecture Metamodel | Defines the types of artefacts, their relationships, and how they are governed |
| Architecture Landscape | The actual enterprise architecture artefacts at strategic, segment, and capability levels |
| Standards Information Base (SIB) | Technology standards, product lifecycles, vendor information, approved patterns |
| Reference Library | Reference architectures, guidelines, templates, patterns from internal and external sources |
| Governance Log | Compliance assessments, waivers, dispensations, decisions, Architecture Contracts |
| Architecture Capability | The capability model, skills assessments, training records, maturity assessments |
Architecture Maturity Model (Levels 1–5)
The TOGAF Architecture Capability Framework includes a maturity model that allows an organisation to assess the current state of its architecture practice and plan improvements. The five levels are:
Architecture is ad hoc, unpredictable. Success depends on individual heroics. No repeatable process exists.
Basic processes are established. Architecture success can be repeated. Limited consistency across the enterprise.
Architecture process is documented, standardised, and integrated. Organisation-wide adoption. Architecture Board active.
Architecture is measured and controlled. Detailed metrics collected. Continuous improvement in place.
Continuous improvement driven by quantitative feedback. Architecture proactively enables business innovation.
Architecture Skills Framework
The Architecture Skills Framework defines the roles, skills, and experience levels required to staff the architecture practice. It covers:
- Role definitions: Chief Enterprise Architect, Domain Architect, Solution Architect, Architecture Analyst, Architecture Board Member
- Skill categories: Generic skills (communication, leadership), business skills (enterprise management, industry knowledge), IT skills (technical architecture, standards), and legal/regulatory skills
- Proficiency levels: Awareness, Knowledge, Application, Expert
- Certification alignment: OGEA certification levels mapped to expected proficiency profiles
Section 5: Architecture Governance Framework
Architecture governance ensures that the architecture practice operates in an effective, controlled, and transparent manner. It defines the structures, processes, and controls that ensure architecture decisions are made correctly, communicated broadly, and enforced consistently.
The practice and orientation by which enterprise architectures and other architectures are managed and controlled at an enterprise-wide level. It includes the processes, structures, and decision rights that ensure architecture delivers value, maintains compliance, and aligns with business objectives.
Three Governance Levels
TOGAF describes governance operating at three levels within a typical enterprise:
Policy Management
The governance framework manages policies through a defined lifecycle:
- Policy formulation: Policies are drafted based on principles, regulations, and business strategy.
- Review and approval: Policies are reviewed by stakeholders and approved by the Architecture Board.
- Communication: Approved policies are published to all relevant parties.
- Compliance monitoring: Projects and solutions are reviewed against policies.
- Exception handling: Non-compliance is escalated; waivers are issued with documented conditions.
- Policy review and update: Policies are periodically reviewed; changes follow the same lifecycle.
Architecture Contracts
Architecture Contracts are joint agreements between development partners and sponsors on the deliverables, quality, and fitness-for-purpose of an architecture. They are a key governance tool that bridges the gap between architectural intent and project delivery.
| Contract Element | Description |
|---|---|
| Scope | What is being built, which architecture domains it covers, boundaries and exclusions |
| Conformance requirements | Which principles, standards, and patterns must be followed |
| Architecture deliverables | Which architecture artefacts will be produced, reviewed, and approved |
| Review gates | When architecture review points occur within the project lifecycle |
| Acceptance criteria | How compliance with the architecture will be measured and confirmed |
| Escalation procedures | What happens when the project needs to deviate from the approved architecture |
Architecture Contracts are used in Phase G (Implementation Governance) as the primary tool for ensuring delivered solutions conform to the approved architecture. However, the framework for contracts — how they work, what they contain, and the governance process — is established in the Preliminary Phase. Do not confuse where contracts are defined (Preliminary) with where they are applied (Phase G).
Section 6: Business Scenarios and Organisational Context
Before the architecture practice can operate effectively, the architects must deeply understand the organisational context in which it will work. The Preliminary Phase involves gathering intelligence about the organisation's internal and external environment, identifying key business drivers, and understanding the constraints and opportunities that will shape all subsequent architecture work.
Business Scenarios Technique
Business Scenarios are a technique for identifying and documenting the business requirements that an architecture must address. Although the technique is used most prominently in Phase A (Architecture Vision), the groundwork is laid in the Preliminary Phase when architects develop an understanding of the business context.
A Business Scenario contains five elements:
- Problem description: What business problem is being addressed?
- Business and technical environment: Current state context — people, processes, systems, data.
- Objectives and measures of success: What would success look like? How would it be measured?
- Human actors: The people involved — their roles, goals, and constraints.
- Computer actors: The systems and data stores involved.
PESTLE Analysis in EA Context
PESTLE analysis is used in the Preliminary Phase to understand the external drivers that must be reflected in the architecture. For the OGEA-103 exam, you should be able to map each PESTLE dimension to architecture implications:
| PESTLE Factor | What it Examines | Architecture Implication Example |
|---|---|---|
| Political | Government policy, trade agreements, public sector mandates | Government cloud mandates require data sovereignty principles; public sector architecture standards apply |
| Economic | Market conditions, cost pressures, investment cycles | Economic downturn drives cost-optimisation principles; rationalisation of application portfolio |
| Social | Demographics, workforce changes, customer behaviour trends | Remote working surge drives mobile-first and zero-trust security principles |
| Technological | Emerging technologies, digital disruption, IT evolution | Cloud-native adoption drives technology independence and vendor neutrality principles |
| Legal | Regulations, compliance requirements, data protection laws | GDPR drives data privacy and data security principles; data trustee roles become mandatory |
| Environmental | Sustainability, ESG requirements, carbon reporting | Net-zero commitments drive sustainable IT principles; green data centre standards mandated |
Identifying Key Business Drivers
Key business drivers are the forces that compel an organisation to undertake architecture work. Identifying them in the Preliminary Phase ensures all subsequent ADM phases stay grounded in real business needs. Typical drivers include:
- Merger or acquisition: Need to integrate disparate IT estates
- Regulatory change: New compliance requirements demand new controls and data governance
- Digital transformation: Need to compete with digital-native competitors
- Cost reduction mandate: Board directive to reduce IT spend by rationalising the portfolio
- Customer experience improvement: Competitive pressure driving omnichannel capability
- Operational resilience: Post-incident requirements for improved business continuity
Section 7: Common Exam Topics on the Preliminary Phase
What is NOT an Output of the Preliminary Phase
This is the single most frequently tested question type on this topic. Memorise the key non-outputs:
| NOT a Preliminary Phase Output | Where it Actually Comes From |
|---|---|
| Architecture Vision | Phase A — Architecture Vision |
| Statement of Architecture Work | Phase A — Architecture Vision |
| Architecture Definition Document | Phases B, C, D |
| Architecture Roadmap | Phase E (draft), Phase F (finalised) |
| Architecture Contract (specific project) | Phase G — Implementation Governance |
| Gap Analysis | Phases B, C, D |
| Stakeholder Map / Communication Plan | Phase A — Architecture Vision |
Preliminary Phase vs Phase A: Key Distinctions
| Dimension | Preliminary Phase | Phase A — Architecture Vision |
|---|---|---|
| Purpose | Prepare the organisation to do architecture work | Define the vision for a specific architecture engagement |
| Scope | Enterprise-wide, enduring | Specific ADM cycle, bounded by the Statement of Architecture Work |
| When run | Once initially; revisited when context changes significantly | At the start of every ADM iteration |
| Key outputs | Principles, tailored ADM, governance framework, architecture capability | Architecture Vision, Statement of Architecture Work, stakeholder map, communication plan |
| Sponsor relationship | Requires board-level or executive mandate | Requires specific project sponsor approval for the Statement of Architecture Work |
| Governance trigger | Produces the governance framework | Operates within the governance framework established by Preliminary |
Framework Integration Questions
OGEA-103 Part 2 often presents organisations already using ITIL, COBIT, or Agile frameworks and asks how TOGAF should be integrated. Key rules: (1) TOGAF does not replace other frameworks — it integrates. (2) Tailoring decisions are always made in the Preliminary Phase. (3) The correct approach is to identify overlaps, harmonise terminology, and use TOGAF where it adds value (strategic architecture direction) while respecting existing processes for service management, project delivery, and IT governance.
Common Mistakes in Exam Answers
- Confusing the Preliminary Phase with Phase A — candidates often assign Phase A outputs (Architecture Vision, Statement of Architecture Work) to the Preliminary Phase.
- Stating that the Preliminary Phase is "never revisited" — it is revisited when the organisation's context changes materially.
- Confusing the "Statement" component with "Implications" in the four-part principle format — both are declarations but serve completely different purposes.
- Claiming that principle conflicts should be silently resolved by the architect — they must be escalated to the Architecture Board and documented.
- Treating the Architecture Repository as only relevant from Phase B onwards — the repository structure is set up in the Preliminary Phase.
- Assuming TOGAF replaces ITIL or COBIT — TOGAF integrates and complements other frameworks; it does not supersede them.
- Placing "Architecture Capability" as an output of Phase A — it is established in the Preliminary Phase.
Revision Summary — Chapter 02
- The Preliminary Phase prepares the organisation to do architecture work; it is NOT a lettered phase (A–H) and precedes the ADM cycle, but can be revisited when context changes.
- Key outputs are: Architecture Principles, tailored ADM, governance framework, architecture team definition, initial Architecture Repository, and the architecture capability assessment.
- Architecture Vision, Statement of Architecture Work, stakeholder map, and Gap Analysis are NOT Preliminary Phase outputs — they belong to Phase A or later phases.
- Principles have five qualities: Understandable, Robust, Complete, Consistent, Stable. They are documented in four parts: Name, Statement, Rationale, Implications.
- "Must," "shall," and "will be required to" language in a principle component = Implication. Explanatory "why" language = Rationale. The aspirational declaration = Statement.
- TOGAF integrates with ITIL (service management), COBIT (governance), PRINCE2 (project delivery), and Agile/SAFe (iterative delivery) — tailoring decisions are made in Preliminary.
- Scope is defined across four dimensions: Breadth, Depth, Time period, Architecture domains (BDAT).
- The Architecture Board is the governance body; it approves principles, adjudicates conflicts, manages waivers, and oversees compliance.
- The Architecture Repository has six classes: Metamodel, Architecture Landscape, Standards Information Base, Reference Library, Governance Log, Architecture Capability.
- Maturity levels run from 1 (Initial / ad hoc) to 5 (Optimising / quantitatively driven).
- Architecture Contracts define conformance requirements for projects; the contract framework is established in Preliminary, but specific contracts are applied in Phase G.
- PESTLE analysis maps external drivers (Political, Economic, Social, Technological, Legal, Environmental) to architecture principles and constraints.
Practice Questions
Test your understanding of the Preliminary Phase. Click a question to reveal the answer and explanation.
A. Develop the Architecture Vision and obtain sponsor approval for the architecture programme
B. Prepare the organisation to do architecture work by establishing principles, governance, and the architecture capability
C. Define the Baseline and Target Architectures for the Business domain
D. Perform a gap analysis between the current IT environment and the target technology architecture
Explanation: Option B is correct. The Preliminary Phase is fundamentally about preparation — it establishes the foundations that all subsequent ADM phases rely on. Option A describes the purpose of Phase A (Architecture Vision). Options C and D describe activities in Phases B and D respectively. The Preliminary Phase does not produce any specific architecture content for a particular domain; it produces the governance structures, principles, and capability that enable domain architectures to be developed correctly.
A. Name
B. Statement
C. Rationale
D. Implications
Explanation: Option D is correct. The text contains specific, mandatory requirements ("must be encrypted," "must be retained") with precise technical details (AES-256, 12 months). These are the practical consequences of upholding the principle — which is the definition of Implications. The Statement would be broader and aspirational: "Personal data is protected and treated with the utmost confidentiality." The Rationale would explain the business and legal reasons why. The Name would be a short label like "Data Security."
A. Replace ITIL and COBIT with the TOGAF governance and service management processes
B. Run TOGAF in parallel with ITIL and COBIT, keeping the three frameworks completely separate
C. Tailor the ADM to integrate with ITIL and COBIT, aligning terminology, processes, and governance to create a coherent framework landscape
D. Postpone TOGAF adoption until ITIL and COBIT are decommissioned
Explanation: Option C is correct. TOGAF is explicitly designed to co-exist with and complement other frameworks. ITIL covers service management (which maps to ADM phases F and G from a service transition perspective), while COBIT provides the IT governance control framework that the Architecture Governance layer should align with. Tailoring in the Preliminary Phase means identifying overlaps, harmonising terminology, and integrating processes. Options A, B, and D all contradict the TOGAF approach: TOGAF does not replace other frameworks (A), running them in complete isolation creates confusion and duplication (B), and postponing adoption is not a valid response (D).
A. Architect X is correct — overlapping principles violate the "Consistent" characteristic and one must be removed immediately
B. Architect Y is correct — the principles should be reviewed for overlap; if they are genuinely redundant, they may be consolidated, but this decision should go through the Architecture Board
C. Neither architect is correct; principle overlap is acceptable and requires no action
D. The Chief Architect should resolve this unilaterally without Board involvement
Explanation: Option B is correct. "Technology Independence" (applications are independent of specific technology choices) and "Vendor Neutrality" (no dependency on specific vendors) are distinct though related. Technology Independence is Application domain; Vendor Neutrality is Technology domain. They address different architecture concerns. However, if on review they are found to overlap significantly, consolidation is appropriate — but this is a governance decision to be made by the Architecture Board, not a unilateral call. Option A applies the "Consistent" characteristic too aggressively — overlap is not the same as contradiction. Option D bypasses the governance structure.
A. Level 1 — Initial
B. Level 2 — Repeatable
C. Level 3 — Defined
D. Level 5 — Optimising
Explanation: Option C is correct. Level 3 (Defined) is characterised by: documented and standardised architecture processes, organisation-wide adoption, an active Architecture Board, and integration of architecture compliance into project gates. Level 2 (Repeatable) would show processes that work but are not yet standardised enterprise-wide. Level 4 (Managed) requires detailed quantitative metrics and measurement-driven improvement — the scenario does not mention metrics. Level 5 (Optimising) requires continuous quantitative improvement and architecture proactively driving business innovation — also not evident here. Level 1 (Initial) is ad hoc — clearly not this organisation.