Organizational Model for Enterprise Architecture

1. Case Study Overview

This case study explains how an organization can produce the Organizational Model for Enterprise Architecture, one of the key deliverables of the TOGAF Architecture Development Method Preliminary Phase.

The case organization is a fictional but realistic company:

Northstar Retail Group, a large omnichannel retailer operating physical stores, e-commerce platforms, warehouses, a customer loyalty program, and regional delivery services.

Northstar has grown through acquisitions and now experiences:

Duplicated applications across business units
Inconsistent data definitions
Slow delivery of strategic technology initiatives
Poor visibility of technology risks
Unclear ownership of architecture decisions
Limited coordination between business, information, technology, security, and project teams

The executive committee decides to establish a formal Enterprise Architecture function using TOGAF.

The required deliverable is an Organizational Model for Enterprise Architecture covering:

Scope of the enterprise architecture function
Organizational structure and roles
Responsibilities and authority
Governance structure and reporting relationships

2. Purpose of the Deliverable

The Organizational Model for Enterprise Architecture defines how architecture will operate within the enterprise.

It answers four fundamental questions:

What is Enterprise Architecture responsible for?
Who performs architecture activities?
What authority do architects and governance bodies have?
How are architecture decisions governed, communicated, escalated, and reported?

Without this deliverable, an architecture practice may become an informal advisory group with unclear responsibilities. It may produce documents but have little influence over investment decisions, solution delivery, risk management, or business transformation.

The organizational model therefore establishes the architecture function as an operating capability rather than merely a collection of architecture diagrams.

3. Business Context

Northstar Retail Group operates in five major business areas:

Business area	Main responsibilities
Customer and Digital	E-commerce, mobile applications, customer experience, loyalty
Stores and Merchandising	Stores, pricing, promotions, product management
Supply Chain	Warehousing, logistics, inventory, supplier integration
Finance and Corporate Services	Finance, procurement, human resources, legal
Technology and Operations	Infrastructure, applications, cybersecurity, service management

The organization has approximately:

18,000 employees
450 retail stores
Operations in three countries
Annual revenue of approximately $4 billion
More than 600 business and technology applications
Multiple cloud platforms and data centers
Several major transformation programs

The Chief Information Officer has previously managed technology architecture informally through the IT department. However, the executive committee now wants architecture to support enterprise-wide decisions, including business operating model changes, data governance, cybersecurity, sourcing, and transformation investment.

The organization therefore needs an architecture function that is:

Enterprise-wide rather than IT-only
Connected to strategic planning
Integrated with portfolio and project governance
Independent enough to challenge individual initiatives
Practical enough to support delivery teams

4. Objectives of the Architecture Organization

The objectives are agreed during the Preliminary Phase.

The Enterprise Architecture function will:

Align business strategy, operating models, information, applications, and technology.
Define and maintain the enterprise architecture vision and target states.
Identify opportunities for business simplification and standardization.
Reduce duplication and unnecessary technology costs.
Improve interoperability and reuse.
Strengthen information security, privacy, resilience, and regulatory compliance.
Support investment prioritization and transformation planning.
Provide architecture guidance to programs and solution teams.
Establish architecture principles, standards, and reference models.
Provide governance over significant architecture decisions.
Maintain the architecture repository and architecture knowledge base.
Measure the effectiveness of architecture decisions and investments.

5. Method Used to Produce the Deliverable

Northstar uses a structured approach to produce the Organizational Model.

Step 1: Confirm the business drivers

The architecture organization should not be designed in isolation. The team begins by identifying the business pressures that require architecture capability.

Workshops are held with:

Chief Executive Officer
Chief Information Officer
Chief Financial Officer
Chief Operating Officer
Chief Digital Officer
Chief Information Security Officer
Business unit leaders
Program and portfolio management
Procurement
Risk and compliance
Human resources

The main drivers identified are:

Business driver	Architecture implication
Omnichannel growth	Architecture must cover customer, digital, store, and supply-chain capabilities
Acquisitions	Architecture must support integration and rationalization
Regulatory pressure	Security, privacy, risk, and compliance must be embedded in architecture governance
Rising technology costs	Architecture must influence investment and platform decisions
Faster digital delivery	Architecture must provide reusable standards and lightweight decision-making
Data quality problems	Data architecture and information governance must be part of the function
Cloud adoption	Technology architecture must cover cloud principles, platforms, resilience, and sourcing

The result is a decision that Enterprise Architecture will be an enterprise capability, not simply an IT design authority.

Step 2: Define the scope of the architecture function

The team then determines what areas are inside and outside the initial scope.

2.1 Scope dimensions

Architecture scope is defined across several dimensions:

Organizational scope
Geographic scope
Business scope
Architecture domain scope
Lifecycle scope
Decision scope
Governance scope
Repository scope

2.2 Organizational scope

The function will initially cover:

Corporate headquarters
All retail operations
E-commerce and mobile channels
Warehousing and logistics
Customer loyalty services
Shared corporate services
Technology platforms used by Northstar

Acquired companies will be incorporated progressively through transition planning.

2.3 Geographic scope

Northstar operates in three countries. Enterprise principles and strategic architectures will apply across the group, while local variations will be allowed where required by:

Legal obligations
Tax rules
Labor regulations
Market-specific operating requirements
Local customer or supplier practices

2.4 Architecture domains

The architecture function will cover the following domains:

Architecture domain	Scope
Business Architecture	Capabilities, value streams, business processes, organization, operating model
Data Architecture	Information concepts, data ownership, data flows, master data, data quality, analytics
Application Architecture	Application portfolio, application services, integration, APIs, rationalization
Technology Architecture	Infrastructure, networks, platforms, cloud, devices, technical services
Security Architecture	Identity, access, cybersecurity, resilience, privacy, security controls
Integration Architecture	APIs, events, middleware, interfaces, integration standards
Solution Architecture	Architecture of individual initiatives and products within enterprise constraints

Security Architecture is treated as an integrated cross-cutting domain but is governed through strong collaboration with the CISO organization.

2.5 Lifecycle scope

The architecture function will participate in:

Strategy development
Business case preparation
Portfolio planning
Program initiation
Solution design
Procurement and sourcing
Implementation assurance
Transition to operations
Post-implementation review
Architecture compliance and continuous improvement

2.6 Initial exclusions

To avoid overextending the new function, the following are not initially owned by Enterprise Architecture:

Detailed project management
Day-to-day system administration
Detailed software coding standards owned by engineering teams
Operational service management
Vendor contract management
Detailed process documentation below the agreed architecture level
Routine low-risk solution design that follows approved standards

These activities may interact with architecture but are owned by other functions.

6. Scope Statement for the Deliverable

Northstar documents the agreed scope in the following formal statement:

The Northstar Enterprise Architecture function defines, governs, and maintains the business, data, application, technology, security, integration, and solution architectures required to achieve the enterprise strategy. Its scope includes all major business units, shared services, strategic technology platforms, significant transformation initiatives, material technology investments, and architecture decisions that may affect enterprise risk, interoperability, information management, resilience, regulatory compliance, or long-term cost.

The function will not replace business ownership, delivery management, product ownership, engineering management, information security operations, or service management. Instead, it will establish architecture direction, decision criteria, constraints, reusable patterns, and governance mechanisms for those areas.

7. Determine the Required Architecture Capability

The next question is not only what architecture should cover, but what level of capability is required.

Northstar assesses itself against five capability dimensions:

Capability dimension	Current state	Required state
Governance	Informal and inconsistent	Formal decision rights and escalation
People	Small group of technical architects	Multidomain architecture team
Processes	Project-specific review	Integrated lifecycle governance
Methods	Inconsistent documentation	Standardized architecture method and viewpoints
Tools and repository	Scattered documents	Managed architecture repository
Measurement	No architecture metrics	Defined performance and compliance measures

The assessment shows that Northstar does not need a large centralized architecture department immediately. It needs a federated architecture model.

8. Select the Organizational Model

Northstar considers three organizational options.

Option 1: Centralized architecture function

All architects report to a Chief Architect or Enterprise Architecture Director.

Advantages

Consistent standards
Strong independence
Easier capability development
Clear architecture accountability

Disadvantages

Can become disconnected from business units
May create a bottleneck
May be perceived as an IT control function

Option 2: Fully decentralized architecture

Architects are embedded entirely within business units or delivery teams.

Advantages

Close to business needs
Fast local decision-making
Strong delivery alignment

Disadvantages

Inconsistent standards
Duplicated architecture practices
Difficult enterprise-wide prioritization
Weak independence

Option 3: Federated architecture function

A central Enterprise Architecture Office establishes principles, methods, standards, and enterprise direction. Domain and solution architects remain connected to business units, product teams, and technology groups.

Advantages

Enterprise consistency with local responsiveness
Better connection to business and delivery
Scalable across multiple business units
Supports shared governance

Disadvantages

Requires clear role definitions
Matrix reporting can create conflicts
Requires strong communication and escalation mechanisms

Northstar selects the federated model.

9. Proposed Organizational Structure

9.1 High-level structure

The architecture organization is structured as follows:

Board / Executive Committee
          |
    CIO / Executive Sponsor
          |
Enterprise Architecture Council
          |
Chief Architect / Head of Enterprise Architecture
          |
Enterprise Architecture Office
          |
-------------------------------------------------
|          |           |           |              |
Business   Data        Application Technology    Security
Architecture Architecture Architecture Architecture Architecture
          |
   Architecture Review Board
          |
 Solution Architects and Domain Architecture Communities

This structure separates:

Strategic architecture direction
Architecture standards and methods
Domain architecture
Solution-level architecture
Architecture governance
Delivery assurance

9.2 Reporting structure

The recommended reporting relationships are:

The Chief Architect reports to the CIO.
The Enterprise Architecture Office reports functionally to the Chief Architect.
Domain architects report administratively to the Chief Architect or relevant technology/business executive, depending on the domain.
Solution architects report administratively to delivery or product organizations but functionally to the architecture community.
Security architects maintain a formal relationship with both the Chief Architect and the CISO.
Data architects maintain a formal relationship with both the Chief Architect and the Chief Data Officer or equivalent data executive.
Architecture governance decisions are made through the Architecture Review Board and escalated to the Enterprise Architecture Council when required.

This model balances organizational practicality with architectural independence.

10. Roles in the Architecture Organization

10.1 Executive Sponsor

The Executive Sponsor is usually a senior executive who supports the architecture capability and removes organizational barriers.

For Northstar, the CIO is the primary Executive Sponsor.

Responsibilities

Establish the importance of enterprise architecture
Secure executive support and funding
Resolve conflicts beyond the authority of the Chief Architect
Ensure architecture is connected to enterprise strategy
Support enforcement of architecture decisions
Sponsor the Architecture Charter

Authority

The Executive Sponsor can:

Approve the architecture mandate
Escalate noncompliance to the executive committee
Approve major exceptions
Resolve disputes between business units and architecture governance

10.2 Chief Architect

The Chief Architect is accountable for the architecture capability as a whole.

Responsibilities

Define and maintain the architecture operating model
Lead development of the Enterprise Architecture Charter
Establish architecture principles and standards
Chair or coordinate the Architecture Review Board
Advise executives on architecture risks and opportunities
Ensure architecture is integrated with investment and portfolio governance
Manage the architecture roadmap
Maintain the architecture capability maturity plan
Coordinate domain and solution architecture
Report architecture performance to executives

Authority

The Chief Architect can:

Require architecture review for initiatives within the defined scope
Approve architecture standards and reference patterns within delegated authority
Reject or return architecture submissions that do not meet requirements
Escalate material architecture risks
Require corrective actions for architecture noncompliance
Recommend investment or decommissioning decisions
Approve low- and medium-risk architecture decisions within the authority matrix

The Chief Architect cannot independently approve business funding, override legal requirements, or replace accountable business owners.

10.3 Enterprise Architecture Office

The Enterprise Architecture Office provides the coordination and administration required to operate the practice.

Responsibilities

Maintain the architecture repository
Manage architecture processes and templates
Maintain the architecture principles catalog
Coordinate architecture review meetings
Track decisions, actions, risks, waivers, and exceptions
Maintain the architecture roadmap
Produce reports and dashboards
Manage architecture communications
Support training and community development
Coordinate architecture planning cycles

Authority

The Enterprise Architecture Office can:

Request required architecture artifacts
Validate submissions for completeness
Maintain the official architecture decision record
Publish approved architecture standards
Track compliance actions
Escalate overdue decisions and unresolved risks

10.4 Business Architect

The Business Architect connects enterprise strategy, capabilities, value streams, operating models, and organizational design.

Responsibilities

Model business capabilities
Define business architecture baselines and targets
Analyze business impacts of transformation
Identify capability gaps
Align business and technology roadmaps
Support business case development
Clarify business outcomes and measures
Ensure architecture reflects business priorities

Authority

The Business Architect can:

Recommend capability priorities
Challenge technology proposals that lack business value
Require clarification of business outcomes
Approve business architecture artifacts within delegated authority

Business architects do not own business strategy; they help translate it into architecture.

10.5 Data Architect

The Data Architect is responsible for the enterprise information perspective.

Responsibilities

Define data principles and information standards
Establish conceptual and logical data models
Define data ownership and stewardship requirements
Support master data management
Identify critical information assets
Govern data flows and integration
Support privacy, retention, quality, and lineage requirements
Align analytical, operational, and reporting data structures

Authority

The Data Architect can:

Reject designs that create unacceptable duplication or data quality risk
Require data ownership to be assigned
Approve data architecture patterns within delegated limits
Escalate data policy conflicts to the Data Governance Council

10.6 Application Architect

The Application Architect manages the application landscape and its evolution.

Responsibilities

Maintain the application portfolio
Define application principles and reference architectures
Identify duplication and rationalization opportunities
Define application integration patterns
Support API and service architecture
Assess application lifecycle and technical debt
Review solution architecture proposals
Support application modernization planning

Authority

The Application Architect can:

Challenge proposals that duplicate existing functionality
Require reuse of approved platforms where appropriate
Approve application architecture within assigned thresholds
Recommend application retirement, consolidation, or replacement

10.7 Technology Architect

The Technology Architect defines the technology platforms and infrastructure required by the enterprise.

Responsibilities

Define technology standards and reference platforms
Establish cloud, network, infrastructure, and hosting principles
Assess resilience and scalability
Support technology sourcing decisions
Define technology lifecycle standards
Review platform and infrastructure proposals
Identify technical debt and modernization requirements

Authority

The Technology Architect can:

Approve or reject technology choices against enterprise standards
Require approved platform patterns
Escalate unsupported or high-risk technologies
Recommend platform consolidation

10.8 Security Architect

The Security Architect ensures that architecture decisions reflect security and resilience requirements.

Responsibilities

Define security architecture principles
Review identity, access, encryption, network, and application security
Support threat modeling
Evaluate security risks and controls
Ensure alignment with security policies
Coordinate with the CISO organization
Review exceptions to security standards
Support privacy and regulatory requirements

Authority

The Security Architect can:

Block designs that create unacceptable security risk
Require security controls or remediation
Escalate unresolved risks to the CISO
Approve security architecture within delegated authority

10.9 Solution Architect

The Solution Architect applies enterprise and domain architecture to a specific initiative, product, or solution.

Responsibilities

Develop solution architecture
Translate requirements into architecture decisions
Identify dependencies and constraints
Ensure alignment with principles and standards
Coordinate application, data, technology, and security concerns
Produce architecture decision records
Support delivery teams
Monitor architecture during implementation
Escalate deviations and risks

Authority

The Solution Architect can:

Make solution-level decisions within the approved architecture boundary
Recommend alternatives
Reject designs that violate mandatory standards
Request architecture review when scope or risk changes
Approve detailed solution decisions within delegated thresholds

The Solution Architect does not unilaterally change enterprise standards or principles.

10.10 Architecture Review Board

The Architecture Review Board is the primary operational governance body.

Membership

The board includes:

Chief Architect, Chair
Business Architecture Lead
Data Architecture Lead
Application Architecture Lead
Technology Architecture Lead
Security Architecture Lead
Relevant business representative
Portfolio or program representative
Risk, compliance, or legal representative when required
Solution architect for the initiative under review

Responsibilities

Review architecture proposals
Confirm alignment with principles and standards
Assess cross-domain impacts
Review exceptions and waivers
Identify risks and dependencies
Confirm architecture readiness for major delivery stages
Maintain architecture decisions
Escalate material matters to the Enterprise Architecture Council

Authority

The board can:

Approve architecture proposals within its delegated limit
Approve temporary exceptions
Require amendments or further analysis
Place conditions on approval
Reject proposals that fail mandatory requirements
Escalate decisions outside its authority

10.11 Enterprise Architecture Council

The Enterprise Architecture Council is the senior governance body for architecture.

Membership

The council includes:

CIO, Chair
Chief Architect
Chief Digital Officer
Chief Data Officer or equivalent
Chief Information Security Officer
Chief Operating Officer
CFO or finance representative
Business unit executives
Head of Portfolio Management
Other executives as required

Responsibilities

Approve enterprise architecture direction
Approve major principles and standards
Resolve cross-business conflicts
Approve target architecture and major transition states
Prioritize architecture-led initiatives
Review significant architecture risks
Approve major exceptions
Align architecture with business and investment strategy
Review architecture performance

Authority

The council can:

Approve enterprise architecture principles
Approve target-state architecture
Approve major deviations
Direct business units to comply with mandatory architecture decisions
Escalate unresolved issues to the executive committee
Require funding or remediation for material architecture risks

11. Responsibility and Authority Matrix

A responsibility matrix makes the model operational.

The following simplified RACI matrix is created for Northstar.

Activity	Executive Sponsor	Chief Architect	Domain Architect	Solution Architect	Architecture Review Board	Business Owner	CISO/CFO/Other Executive
Approve architecture mandate	A	R	C	I	C	C	C
Define architecture principles	A	R	C	C	C	C	C
Define business architecture	I	A	R	C	C	R	C
Define data standards	I	A	R	C	C	C	C
Develop solution architecture	I	A	C	R	C	C	C
Review major solution	I	A	R	R	C	C	C
Approve architecture exception	I	R	C	C	A	C	C
Approve major architecture deviation	C	R	C	C	R	C	A
Maintain architecture repository	I	A	R	R	C	I	I
Report architecture risks	C	A	R	R	C	C	C
Approve target architecture	C	R	C	I	C	C	A
Enforce architecture compliance	A	R	R	R	A	C	C

RACI legend:

R — Responsible
A — Accountable
C — Consulted
I — Informed

The matrix prevents common problems such as:

A solution architect being held accountable for enterprise standards
A business owner being excluded from architecture decisions
Security being treated as an afterthought
The Architecture Review Board making decisions without executive authority
The Chief Architect becoming responsible for every detailed technical decision

12. Decision Rights and Authority Levels

Northstar defines decision authority according to the potential impact of a decision.

Decision category	Example	Normal authority
Team-level	Detailed implementation choice within an approved pattern	Delivery team or solution architect
Solution-level	Selection of application components for a project	Solution Architect / Architecture Review Board
Domain-level	Data model, integration pattern, platform selection	Domain Architect / Architecture Review Board
Enterprise-level	Enterprise principle, strategic platform, target architecture	Enterprise Architecture Council
Executive-level	Major funding, risk acceptance, strategic exception	Executive Committee

12.1 Authority thresholds

An architecture decision must be escalated when it involves one or more of the following:

More than one business unit
A material security or privacy risk
A material regulatory risk
A new strategic platform
Significant vendor or sourcing commitment
Major duplication of existing capability
Long-term lock-in
Significant change to the target architecture
Major exception to an enterprise principle
Impact on enterprise resilience or business continuity
A financial impact above an agreed threshold

For example:

A project team may choose between two approved database configurations.
The Architecture Review Board may approve a new integration pattern for one business domain.
The Enterprise Architecture Council must approve adoption of a new enterprise-wide cloud platform.
The executive committee must approve acceptance of a critical unresolved cybersecurity risk.

13. Governance Structure

Northstar establishes a layered architecture governance model.

13.1 Enterprise governance layer

Enterprise Architecture Council

Meets monthly or when major decisions are required.

Typical agenda:

Review strategic architecture matters
Approve target states and principles
Review major exceptions
Review significant architecture risks
Resolve conflicts between business units
Review architecture performance
Align architecture priorities with investment planning

13.2 Operational governance layer

Architecture Review Board

Meets weekly or biweekly.

Typical agenda:

Review new architecture submissions
Review solution designs
Assess exceptions
Track open conditions
Review architecture risks and dependencies
Confirm compliance with standards
Escalate unresolved matters

13.3 Domain governance layer

Domain Architecture Communities

Separate communities may exist for:

Business Architecture
Data Architecture
Application Architecture
Technology Architecture
Security Architecture
Integration Architecture

These communities develop standards, patterns, models, and guidance.

13.4 Delivery governance layer

Architecture is integrated into the project and product lifecycle.

Architecture checkpoints occur at:

Opportunity identification
Business case
Initiation
Solution design
Procurement
Build readiness
Implementation readiness
Transition to operations
Post-implementation review

14. Reporting Relationships

The reporting model is documented explicitly.

14.1 Formal reporting

Role	Administrative reporting	Functional reporting
Chief Architect	CIO	Enterprise Architecture Council
Enterprise Architecture Office	Chief Architect	Chief Architect
Business Architect	Chief Architect or business transformation executive	Chief Architect
Data Architect	Chief Data Officer or Chief Architect	Chief Architect
Application Architect	Chief Architect or CTO	Chief Architect
Technology Architect	CTO or Chief Architect	Chief Architect
Security Architect	CISO	Chief Architect for architecture matters
Solution Architect	Program, product, or technology leader	Domain Architect and Chief Architect
Architecture analyst	Enterprise Architecture Office	Relevant architecture lead

This arrangement ensures that architects remain connected to delivery while preserving architecture consistency.

14.2 Escalation relationships

A solution architect escalates:

Technical disagreement to the relevant Domain Architect
Cross-domain disagreement to the Chief Architect
Material risk or unresolved exception to the Architecture Review Board
Enterprise-wide conflict to the Enterprise Architecture Council
Risk beyond council authority to the executive committee

15. Architecture Governance Process

The Organizational Model should include a practical governance process.

Step 1: Initiation

A business unit or delivery team identifies a new initiative.

The initiative owner completes an initial architecture impact assessment covering:

Business capability affected
Data affected
Applications involved
Technology and cloud requirements
Security and privacy impact
Integration requirements
Estimated cost and duration
Potential reuse of existing capabilities

Step 2: Classification

The initiative is classified as:

Low architecture impact
Moderate architecture impact
High architecture impact
Strategic or enterprise impact

Classification determines the level of review required.

Step 3: Architecture assignment

The Chief Architect or Enterprise Architecture Office assigns:

A solution architect
Relevant domain architects
Security and data specialists where necessary
A review route and expected decision date

Step 4: Architecture development

The solution architect develops the required artifacts, which may include:

Architecture Definition Document
Context diagram
Capability impact assessment
Application and technology view
Data flow model
Security architecture
Integration design
Architecture decision records
Risks and assumptions
Transition dependencies

Step 5: Architecture review

The Architecture Review Board assesses:

Alignment with principles
Alignment with target architecture
Reuse and duplication
Security and compliance
Cost and complexity
Interoperability
Operational supportability
Resilience
Vendor and technology risk
Delivery feasibility

Step 6: Decision

The board issues one of the following decisions:

Approved
Approved with conditions
Returned for revision
Rejected
Escalated
Approved as an exception

Step 7: Compliance monitoring

During implementation, the solution architect monitors whether the delivered solution remains aligned with the approved architecture.

Material changes require reassessment.

Step 8: Closure and learning

After implementation:

Architecture decisions are captured
Deviations are recorded
Lessons learned are documented
The repository is updated
Architecture debt is recorded
Reusable patterns are identified

16. Architecture Principles and Their Relationship to the Organization

The organizational model must show how principles are created, approved, and enforced.

Northstar establishes the following initial principles:

Principle	Meaning	Primary owner
Business value first	Architecture decisions must support measurable business outcomes	Business Architecture
Enterprise reuse	Existing capabilities should be reused where practical	Chief Architect
Data is an enterprise asset	Data should have clear ownership, quality rules, and lifecycle controls	Data Architecture
Secure by design	Security and privacy must be incorporated from the beginning	Security Architecture
Cloud and platform pragmatism	Platforms should be selected based on business, risk, cost, and operational needs	Technology Architecture
Interoperability by design	Systems should use approved integration patterns and standards	Application and Integration Architecture
Simplicity before customization	Standard capabilities should be preferred over unnecessary customization	Application Architecture
Resilience is mandatory	Critical services must meet agreed availability and recovery requirements	Technology and Security Architecture
Decisions must be traceable	Significant architecture decisions must be recorded and reviewable	Enterprise Architecture Office

The organizational model assigns responsibility for maintaining each principle and defines who can approve changes.

17. Architecture Repository Responsibilities

A functioning architecture organization requires a controlled repository.

Northstar’s repository includes:

Architecture principles
Business capability maps
Value streams
Organization and operating models
Information and data models
Application portfolio
Technology standards
Reference architectures
Solution architectures
Integration patterns
Security patterns
Architecture decision records
Exceptions and waivers
Architecture roadmaps
Technology lifecycle information
Risks, dependencies, and technical debt

Repository ownership

Repository content	Owner
Business architecture	Business Architecture Lead
Data models and standards	Data Architecture Lead
Application portfolio	Application Architecture Lead
Technology standards	Technology Architecture Lead
Security patterns	Security Architecture Lead
Solution architecture records	Solution Architect
Governance decisions and exceptions	Enterprise Architecture Office
Enterprise repository	Chief Architect

The repository must distinguish between:

Approved content
Draft content
Superseded content
Restricted content
Work-in-progress material

18. Deliverables Produced by the Architecture Organization

The Organizational Model identifies the key outputs of the Enterprise Architecture function.

Strategic outputs

Enterprise Architecture Charter
Architecture principles
Enterprise architecture vision
Target architecture
Architecture capability roadmap
Enterprise architecture roadmap
Architecture maturity assessment

Domain outputs

Business capability maps
Data architecture models
Application portfolio and rationalization roadmap
Technology reference models
Security architecture principles
Integration standards
Domain roadmaps

Initiative outputs

Architecture impact assessment
Solution architecture
Architecture decision records
Security architecture assessment
Data impact assessment
Exception request
Architecture compliance assessment
Transition architecture
Implementation governance report

Governance outputs

Architecture Review Board decisions
Architecture Council decisions
Standards and patterns
Exception register
Architecture risk register
Compliance dashboard
Architecture performance report

19. Interfaces with Other Organizational Functions

Enterprise Architecture cannot operate independently. The organizational model defines its relationships with other governance and management functions.

19.1 Strategy and planning

Enterprise Architecture receives:

Strategic goals
Business operating model changes
Growth plans
Market and regulatory requirements

Enterprise Architecture provides:

Capability assessments
Target architectures
Transformation options
Technology implications
Strategic risks
Roadmaps

19.2 Portfolio management

Portfolio management uses architecture input to:

Prioritize investments
Identify dependencies
Avoid duplication
Assess technology risk
Sequence transformation initiatives
Identify opportunities for shared platforms

Architecture does not replace portfolio governance. It provides structured architectural analysis to improve investment decisions.

19.3 Finance

Finance works with Enterprise Architecture to assess:

Total cost of ownership
Cost of technical debt
Platform consolidation
Investment options
Business case assumptions
Benefits realization

19.4 Procurement

Procurement consults architecture before:

Selecting strategic vendors
Procuring enterprise platforms
Renewing major technology contracts
Entering long-term outsourcing arrangements
Introducing new technology categories

19.5 Information security and risk

Security and risk organizations work with architecture to:

Identify architecture risks
Define mandatory security controls
Assess exceptions
Support regulatory compliance
Review resilience requirements
Monitor remediation

19.6 Project and product delivery

Architecture supports delivery by:

Providing reusable patterns
Reviewing solution designs
Clarifying constraints
Identifying dependencies
Reducing rework
Monitoring material deviations

The objective is to integrate architecture into delivery rather than create a separate approval bureaucracy.

20. Example: Applying the Organizational Model to a Business Initiative

Northstar launches a program called One Customer Experience.

The objective is to provide customers with:

A unified loyalty profile
Consistent pricing and promotions
Cross-channel order visibility
Personalized offers
A common customer service experience

The initiative affects:

E-commerce
Mobile applications
Stores
Loyalty
Customer service
Marketing
Data platforms
Cybersecurity
Integration services

20.1 Initial assessment

The initiative is classified as strategic and high architecture impact because it:

Spans multiple business units
Introduces shared customer data
Requires cross-channel integration
Affects privacy and consent
Requires major application changes
Involves a new customer data platform

20.2 Architecture involvement

The Chief Architect assigns:

Business Architect
Data Architect
Application Architect
Technology Architect
Security Architect
Integration Architect
Lead Solution Architect

20.3 Architecture questions

The team addresses:

What is the enterprise definition of a customer?
Who owns the customer master record?
Which systems remain authoritative for customer data?
How will consent be captured and managed?
Which applications will be replaced or integrated?
Should the solution use APIs, events, or batch integration?
What customer data may be shared across countries?
What availability and recovery objectives are required?
Which cloud and data platform standards apply?
What capabilities should be centralized versus embedded?

20.4 Governance outcome

The Architecture Review Board approves the solution subject to conditions:

A single enterprise customer data definition must be adopted.
All new customer integrations must use approved APIs or event patterns.
Customer consent and privacy controls must be documented.
The solution must use the approved identity platform.
A transition plan must be created for retiring duplicated loyalty capabilities.
Data ownership must be assigned to the Customer and Marketing business functions.
Any deviation from the approved architecture must return to the board.

The Enterprise Architecture Council approves the target architecture because the initiative changes the enterprise operating model and introduces a strategic data platform.

This example demonstrates how the organizational model converts architecture from documentation into governed decision-making.

21. Performance Measures for the Architecture Function

The organizational model should define how success will be measured.

Northstar adopts the following measures:

Measure	Example target
Major initiatives receiving architecture review	100%
Architecture decisions completed within agreed service level	At least 90%
Projects using approved reference patterns	At least 80%
Exceptions with documented risk acceptance	100%
Duplicate applications retired	Annual improvement target
Reuse of shared services and platforms	Year-on-year improvement
Material architecture risks without owner	Zero
Architecture artifacts stored in the repository	At least 95%
Architecture review rework rate	Declining trend
Technology standards with lifecycle owner	100%
Security issues identified before implementation	Increasing initially, then stabilizing
Business satisfaction with architecture support	Measured through surveys

Metrics should not encourage architecture teams to approve everything quickly. They should measure decision quality, business value, risk reduction, reuse, and delivery support.

22. Implementation Roadmap

Northstar implements the organizational model over twelve months.

Phase 1: Establish the mandate — Months 1–2

Activities:

Approve the Enterprise Architecture Charter
Appoint the Chief Architect
Confirm executive sponsorship
Define initial scope
Establish the Architecture Review Board
Identify key stakeholders
Publish the architecture operating model

Outputs:

Approved charter
Initial organizational model
Governance calendar
Role descriptions
Initial authority matrix

Phase 2: Build the core capability — Months 3–5

Activities:

Recruit or assign domain architects
Create the Enterprise Architecture Office
Define architecture principles
Establish templates and review criteria
Build the initial repository
Define the architecture intake process
Train project and portfolio teams

Outputs:

Architecture team
Principles catalog
Review process
Repository
Architecture templates
Initial capability map

Phase 3: Integrate with planning and delivery — Months 6–8

Activities:

Connect architecture to portfolio planning
Add architecture gates to the delivery lifecycle
Establish architecture impact assessment
Define exception management
Start domain architecture communities
Publish reference architectures

Outputs:

Integrated lifecycle
Architecture review dashboard
Exception register
Reference architectures
Domain roadmaps

Phase 4: Improve and scale — Months 9–12

Activities:

Evaluate architecture performance
Review reporting relationships
Refine decision thresholds
Extend the model to acquired companies
Improve repository quality
Establish architecture training
Conduct maturity assessment

Outputs:

Capability improvement plan
Revised organization model
Architecture maturity assessment
Enterprise architecture roadmap
Continuous improvement backlog

23. Risks and Mitigations

Risk 1: Architecture becomes an IT-only function

Impact: Business leaders do not recognize its value.

Mitigation:

Include business architecture
Assign business representatives to governance bodies
Link architecture outcomes to business measures
Require business ownership of capabilities and outcomes

Risk 2: Architecture becomes a bottleneck

Impact: Projects experience delays.

Mitigation:

Use risk-based review
Delegate low-risk decisions
Publish standards and reusable patterns
Define service levels
Use lightweight architecture review for small initiatives

Risk 3: Roles are unclear

Impact: Conflicts and duplicated work.

Mitigation:

Publish role descriptions
Maintain a RACI matrix
Define authority thresholds
Use decision records

Risk 4: Architects lack authority

Impact: Architecture recommendations are ignored.

Mitigation:

Obtain executive sponsorship
Link architecture approval to portfolio and funding processes
Establish escalation procedures
Track and report exceptions

Risk 5: Architecture is disconnected from delivery

Impact: Target architectures remain theoretical.

Mitigation:

Assign solution architects to major initiatives
Include architecture checkpoints in delivery
Monitor implementation compliance
Maintain transition architectures

Risk 6: Security and data are treated as separate reviews

Impact: Late discovery of significant risks.

Mitigation:

Include security and data architects early
Integrate security and data checkpoints into architecture review
Define mandatory requirements
Establish joint exception management

Risk 7: The architecture repository becomes outdated

Impact: Decisions are based on inaccurate information.

Mitigation:

Assign content owners
Include repository updates in delivery closure
Record architecture lifecycle dates
Conduct periodic content reviews
Link repository data to portfolio and service management systems where possible

24. Example Deliverable Structure

Northstar’s final Organizational Model for Enterprise Architecture is issued as a controlled document with the following structure:

1. Document purpose

Explains why the organizational model exists and how it supports the Enterprise Architecture Charter.

2. Business context

Describes organizational drivers, strategic goals, and architecture challenges.

3. Architecture objectives

Defines the outcomes expected from the architecture function.

4. Scope

Defines:

Organizational scope
Geographic scope
Business scope
Domain scope
Lifecycle scope
Decision scope
Exclusions

5. Architecture operating model

Describes the selected federated architecture model and how centralized and distributed responsibilities interact.

6. Organization structure

Includes:

Organization chart
Reporting relationships
Architecture communities
Governance bodies
Administrative and functional reporting

7. Roles and responsibilities

Defines each role, expected competencies, responsibilities, and authority.

8. Governance model

Defines:

Enterprise Architecture Council
Architecture Review Board
Domain architecture communities
Delivery checkpoints
Escalation paths

9. Decision rights

Defines authority thresholds, approval rights, exceptions, and escalation.

10. Responsibility matrix

Contains RACI assignments for key architecture activities.

11. Interfaces

Describes relationships with:

Strategy
Portfolio management
Finance
Procurement
Security
Risk
Data governance
Project and product delivery
Operations

12. Processes and lifecycle

Defines architecture intake, review, approval, compliance, exception, and closure processes.

13. Repository and information management

Defines ownership, maintenance, access, and lifecycle of architecture content.

14. Performance management

Defines metrics, reporting, maturity assessment, and continuous improvement.

15. Implementation roadmap

Describes how the architecture organization will be introduced and matured.

16. Appendices

May include:

Organization chart
RACI matrix
Authority matrix
Role profiles
Governance calendar
Architecture review form
Exception form
Decision record template
Initial stakeholder map

25. Example Executive Summary for the Final Deliverable

The following is an example of the executive summary Northstar could include.

Northstar Retail Group will establish a federated Enterprise Architecture function responsible for aligning business strategy, operating models, information, applications, technology, security, and transformation initiatives. The function will operate across all Northstar business units and countries, with local variations permitted where required by legal, regulatory, or operational conditions.

The Chief Architect will lead the function and report to the CIO. The Enterprise Architecture Office will coordinate methods, standards, repository management, governance administration, and reporting. Domain architects will provide expertise across business, data, application, technology, security, and integration architecture. Solution architects will support programs and products while maintaining functional alignment with enterprise architecture standards.

The Enterprise Architecture Council will provide executive-level governance and approve enterprise principles, target architectures, major exceptions, and strategic architecture decisions. The Architecture Review Board will govern operational architecture decisions, review solution architectures, assess compliance, and escalate matters beyond its delegated authority.

Enterprise Architecture will have authority to require architecture review for initiatives within the agreed scope, approve architecture decisions within defined thresholds, require remediation of noncompliant designs, and escalate material risks and exceptions. It will not replace business ownership, project management, product ownership, engineering management, security operations, or service management.

The organizational model will be implemented incrementally over twelve months, beginning with the architecture mandate and governance structure, followed by capability development, integration with portfolio and delivery processes, and continuous improvement.

26. Quality Criteria for the Deliverable

Before approval, Northstar evaluates the deliverable against the following criteria.

The organizational model should:

Have explicit executive sponsorship
Define a clear enterprise architecture mandate
Clearly state what is in and out of scope
Cover business, data, application, technology, security, and solution architecture
Define roles and responsibilities
Distinguish accountability from responsibility
Establish decision rights
Define governance bodies and their authority
Explain reporting relationships
Define escalation routes
Integrate architecture with strategy, funding, procurement, security, and delivery
Include a practical review and exception process
Identify repository ownership
Define performance measures
Provide an implementation roadmap
Be understandable to executives, architects, delivery teams, and business stakeholders

27. Final Outcome

At the end of the Preliminary Phase, Northstar has more than an organization chart. It has an agreed architecture operating model that defines:

The purpose and boundaries of Enterprise Architecture
The architecture domains it covers
The people and roles required
The authority of architects and governance bodies
The way architecture decisions are made
The relationship between architecture and delivery
The process for handling exceptions and risks
The reporting and escalation mechanisms
The measures used to assess architecture effectiveness

The deliverable provides the foundation for the next phases of the TOGAF ADM. It enables Northstar to proceed into architecture vision and subsequent architecture development with a clear understanding of who will participate, how decisions will be governed, and how architecture will influence enterprise transformation.

In practical terms, a successful Organizational Model for Enterprise Architecture ensures that Enterprise Architecture is not merely a documentation function. It becomes a recognized management capability that connects strategy, business change, information, technology, governance, investment, and delivery.