TOGAF® ADM Phase C – Develop the Application Architecture

We develop information systems architecture, which is made of the application architecture and data architecture, in TOGAF ADM Phase C. Application Architecture is one of the four foundational enterprise architecture domains. TOGAF is very clear - application and data architecture are inseparable and exists to enable the business architecture.

In a modern digitally transformed enterprise, choices in one architecture domain enable, deliver, or block outcomes in other domains. Business objectives depend upon the right IT Architecture.

Best practice application architecture will focus on critical constraints that limit freed of choice purchasing, integrating and developing software. Application architecture will tell you when to use SaaS, buy commercial software, whether to use large suites or not, or and when to spend on custom development. System boundaries and integration standards are critical. Lastly, your enterprise application architecture will drive agile development. Without these top-level constraints, detail inside an application is of little practical value.

TOGAF® ADM Phase C—Develop the Application Architecture

At a Glance

TOGAF ADM Overview

The TOGAF ADM is a method to develop knowledge. We focus every ADM Phase on developing specific knowledge required for an enterprise architecture. TOGAF ADM is the core of the TOGAF Standard. It is the only scalable universal method to develop enterprise architecture appropriate for every level of detail. Like all logical models, it needs to be expanded to cover different levels of detail - strategy, portfolio, project, and solution delivery.

If you need an overview of the TOGAF ADM, please read the TOGAF ADM Phases Explained.

What is TOGAF Phase C?

In TOGAF Phase C, you are creating the application architecture. Application architects lead the development of your application architecture.

What is Application Architecture?

An application architecture is a description of your complete software portfolio that tells you when to buy, when to use SaaS, and when to build. It tells you where you should put boundaries between systems. It tells you how you will approach your software lifecycle.

We can guarantee that your current application architecture is not aligned with your business architecture. An application architecture requires a business architecture. Developing the business architecture requires application architects join them engaging with stakeholders.

With the stakeholder and the business architect, the application architect explores how software choices enable and constrain the organization's objectives. We consider potential improvements to understand the immediate and mid-term impact. Together, potential changes that deliver too little, require too much work, or have too much uncertainty, are dropped from the architecture roadmap.

When we are developing enterprise architecture teams, we tell the enterprise architects two central facts about TOGAF Phase C - Application Architecture. First, until you have an Application Development Model, you cannot proceed. Until you know how your application choices enable and constrain your business architecture the details of your applications are pointless. Second, if they believe they need to jump into application functionality and integration, they will always develop a low-quality application architecture.

In a modern digitally transformed enterprise, all architecture domains interact. Choices in one domain enable, deliver, or block outcomes in  another domain. Most business objectives depend upon right IT Architecture. Ironically, we can only develop the right Application Architecture if we have a solid Business Architecture.

What is the Objective of TOGAF ADM Phase C?

In Phase A, you identified a simplified target architecture - the Architecture Vision. The Architecture Vision included all domains. Activity in Phase C, develops the Application and Data architecture domains further. Success requires:

  • You address the problem of how the current Enterprise cannot meet the preferences of the stakeholders
  • You learn what must change to enable the Enterprise to meet the preferences of the stakeholders? (Gaps)
  • You have a sufficient understanding of the work is necessary to deliver changes (Work Package)
  • You understand the interaction between changes and constraints in other architecture domains to protect the value expected (Architecture Requirements Specifications)

The central outcome of Phase C is the candidate application architecture. Application architects work with other domain architects to understand constraints being placed on the application architecture, and what constraints are being placed on other domains.

Remember, the TOGAF ADM explores potential changes. Until you are developing the Implementation Plan in  Phase F, look for the most inexpensive off-ramp. Stopping bad ideas sooner saves money and enables successful changes. The moment an idea turns bad, stop dead in your tracks. Kill the idea. Celebrate your victory! Celebrate that you are enabling successful change!

Interaction with TOGAF Phase B, Phase D, and Phase E

Waterfall approaches do not deliver. Best practice enterprise architecture is not a waterfall activity. The only successful approach requires developing the business architecture, application architecture, data architecture, technology architecture and security architecture simultaneously. Simultaneous development requires an agile approach of just enough to test the cascading constraints.

The classic sequence implied in many TOGAF ADM diagrams is the order we can close architecture development, not start it.

Do not fall into the illusion that 'the business' is in any way separated from its applications, data, and infrastructure. That wasn't true in the past, and in a modern digital enterprise is laughable. That illusion is the fastest way to eliminate enterprise agility or the chance of digital transformation success.

Application architects have a critical role in an enterprise architecture team. Nothing happens in a modern digital enterprise without software. Poor application choices will cripple 'the business.' Application architects are specialists in one architecture domain. They cannot architect their domain without regular engagement with business architects, data, technology, and security architects.

TOGAF ADM Phase C Application Architecture

TOGAF ADM Phase C Application Architecture Deliverables

One central outcome of Phase C is an application architecture. This is one part of the complete enterprise architecture.

The Application Architecture will help answer the following questions:

Always keep in mind that you are seeking to improve the organization. Improvement requires change and delivers value. Value and cost of change can be measured. Uncertainty always decreases potential value. Uncertainty always increases cost. We treat uncertainty as a geometric impact. A little uncertainty decreases the potential value a lot.

When reading, keep in mind there are many uses of the same terms. Look for the purpose of the model, and don't get trapped when the label differs from what you would call it. For example, what you call a functional model someone else will call a service. In our enterprise architecture consulting, we always focus on what we are trying to understand, not what the model is called.

Different models will explain different aspects of the enterprise. Together the models and the needed changes form the application architecture.

Completion of Phase C Application Architecture

All TOGAF ADM Phases lead you to developing the knowledge you need. The outcome of Phase C is the candidate application architecture included within the candidate information systems architecture.

Output & Outcome Essential Knowledge
The application architecture domain architecture approved by the stakeholders for the problem being addressed, with a set of gaps, and work to clear the gaps understood by the stakeholders. How the current software portfolio fails to meet the preferences of the stakeholders?

What must change to enable the software portfolio to meet the preferences of the stakeholders? (Gaps)

What work is necessary to realize the changes that are consistent with the additional value being created? (Work Package)

How stakeholder priority and preference adjust in response to value, effort, and risk of change. (Stakeholder Requirements)

Table from TOGAF 10 TOGAF Series Guide: Enterprise Architect's Guide to Developing Architecture

Phase C Bare Bones

In Phase C, we can simplify the work of a application architect to determining how an enterprise should be better. That requires understanding what it is trying to be good at, where it is falling short of the best, and what must change to enable being the best.

The bare bones of Phase C are:

  • Knowing how the application portfolio enables capturing value

Every organization has a value chain. Activity that changes an input into something more valuable to its customers. Applications either perform value creation, or they deliver record keeping. Traditionally almost all software delivered record keeping.

You must optimize your software for role - value creation or record keeping. Assume record keeping. Do not confuse the important role of record keeping with value creation.

  • Application Architecture Knowing the source of cost and complexity

Every application portfolio creates cost and complexity. We think of software as a complex watch-works that was assembled over time. We connected everything to everything.

You must optimize your core portfolio to drive out sustained cost and complexity. You must enable enterprise agility. Modern digital organizations can only improve at the pace of software.

  • Knowing how to select software

There are four software models: SaaS, enterprise suites, specialist commercial packages, and custom development. Each has a different cost and optimization model. You need to apply the right software model in the right places.

  • Knowing when the software is part of 'the product'

Our organizations deliver a product or service. Software that is 'the product' differs greatly from software that supports the business.

  • Knowing the flow of information

People are infinitely flexible. We can decide to share information. We can proactively see a situation and react. Software does exactly what it is told. Software only does what it is told.

Information flow happens around software to get the right thing done. This type of information flow breaks enterprise agility. They cripple efficiency. These flows drive cost.

  • Knowing the expectations of software

Sometimes we need a casual record keeper. Sometimes we need an autonomous system. Most of the time we need something that helps without too much overhead. We leverage the concepts and attributes in capability models to guide choices about our application architecture. See the Business Architecture Capability Assessment Guide.

  • Know what the organization must do

Every enterprise has a set of processes it must perform: primary value creation, supporting, and administrative. Everyone of them needs software. Everyone of them creates and produces information. You need to know what they are, the information they consume, and who does them.

  • What must change to deliver the best application portfolio?

We develop application architecture to improve an organization. Most changes do not make a material difference. Most changes tinker around the edges. Focus your time on material changes that drive meaningful enterprise agility, cost, or value creation.

The three completion essentials of Phase C:

  • First, what must change? Change in focus, organizational design, upskilling, outsourcing, in-sourcing, automating. These are all changes. We do them to improve an organization.
  • Second, when must it change? Are there dependancies? How about pre-conditions? Are you changing set-the-stage for a later change?
  • Third, how will you know if the change succeeded? What is your governance test for success? How will you guard value?

The enterprise architecture stakeholders own all decisions for what must change and when. The businessapplication architect owns describing the governance tests to enable the stakeholders to direct the change project.the second and third outcomes.

TOGAF Phase C Application Architecture Deliverables and Enterprise Architecture Purposes

There are four core purposes for developing enterprise architecture. Different TOGAF Phase C deliverables have different importance in each purpose.

Architecture to Support Strategy Architecture to Support Portfolio Architecture to Support Project Architecture to Support Solution Delivery
Phase C Work Product: Candidate Application Architecture Key deliverable

Primary use is stakeholder understanding of target and work.

Secondary use is the creation of Architecture Requirements Specification for Architects

Key deliverable

Primary use is stakeholder understanding of target and work.

Secondary use is the creation of Architecture Requirements Specification for Architects

Before project initiation and finalization of business case

Primary use is the creation of Architecture Requirements Specification for Implementers

Before engagement of execution partners (including internal providers)

Primary use is the creation of Architecture Requirements Specification for Implementers

Phase C Work Product: Candidate Roadmap Items Key deliverable

Primary use is stakeholder understanding of work.

Secondary use is the creation of constraints for Architects

Key deliverable

Primary use is stakeholder understanding of work and dependancy.

Secondary use is the creation of constraints for Architects

Limited use
Can be used as an input to projects with multiple interactive changes
Before engagement of execution partners (including internal providers).

Primary use is identification of required change, and preferences of how to execute change, to manage solution delivery partner selection and engagement

Phase C Work Product: Architecture Requirements Specification Limited use

Usually Architects can infer constraints from superior architecture.

Limited use

Usually Architects can infer constraints from superior architecture.

Key deliverable

Before completion of project initiation

Key deliverable

Before engagement and contracting

Table from TOGAF 10 TOGAF Series Guide: Enterprise Architect's Guide to Developing Architecture

Candidate Application Architecture

There are four core purposes for developing enterprise architecture. Different models have different importance in each purpose.

>>> Jump to the common Application Architecture Models

Candidate Application Architecture Roadmap Components

What must change? If you are changing the Application Development Model, then the difference between current and target is the Roadmap Candidate. So is everything needed to enable that change.

We often use a System Model to summarize the change. The System Model allows just enough abstraction from real software to have a planning and execution conversation. We usually use scores and work packages to articulate a change. For more information on using scores, see the Business Architecture Capability Assessment Guide.

We use all Architecture Roadmap components in TOGAF Phase E - Architecture Roadmap.

Candidate Application Architecture Requirements Specification

Define how you will assess the change. How will improvement be assessed?

We often use scores in our models to describe requirements. Each requirement being a measure of efficiency, automation, agility, or performer. Then when we are working in TOGAF Phase G performing architecture governance with a change project we use these scores to assess designs and implementations.

What is the role of the Application Architect in Phase C?

In TOGAF Phase C, we expect the Application Architect to deliver the domain architecture. That requires developing the models that show the source of the deficiency and how to overcome it. They will lead trade-off analysis with stakeholders to determine the target architecture.

The application architect will need to collaborate with the other domain architects.

Key off the business architecture. Know and understand the Operating Model and the Competency and Automation attributes of the Capability Model.

>>> Jump to the common Business Architecture Models

Keep in mind that deficiencies in one domain are often solved in another, and changes in one domain often impose costs and changes in another.

What is the role of the Enterprise Architect in Phase C?

In TOGAF Phase C, the enterprise architect's role is to guard the entire value. Depending upon the skills of the domain architects, the enterprise architect needs to fill-in. For example, an Application Architect may not see the impact of changes in the business architecture. Or they may not articulate a requirement in terms the security architect can act on.

The most important role of the enterprise architect is crossing boundaries. Whether they are domain, skill, or authority boundaries, the enterprise architect needs to cross them.

Application Architecture

Application Architecture Models, Tools, and Techniques

The TOGAF ADM Phase C is delivers the Information Systems Architecture. This Phase exists to develop the application architecture and data architecture that comprise the information systems. In TOGAF, the first step is to determine the views required, and the models required.

Stakeholder Concerns will identify the views. There are seven central application architecture models.

  • Application Development Model that describes the acceptable method a system will be developed
  • System Model that captures the large systems your application portfolio is designed around
  • Functional Model that describes all the things you need your software portfolio to perform
  • Product Model that identifies the functionality used in your organization's products and services, as well as those that administer them
  • Integration Model describes how information flows through your application portfolio
  • Service Model breaks your application portfolio down to black boxes and allows you to ensure each Service has the agility, automation, and other attributes required
  • Physical Model identifies the real applications, commercial, SaaS, or custom, in your application portfolio

Application Architecture Models

Developing an application architecture will require developing several enterprise architecture models. Each explains the enterprise's software portfolio differently. TOGAF Phase C Application Architecture is all about developing the Target Architecture through these models. Ensuring the target application architect works with the other domains to enable the best improvement for your enterprise.

Taken together, the models describe the application architecture. In the complete enterprise architecture, these models will link to other models that describe the other enterprise architecture domains.

Application Development Model

The Application Development Model describes how software will be developed. The model requires a Functional or Physical Model. The Functional Model is far better because it is a logical identification software.

There are four application development types: SaaS, enterprise suites, specialist commercial packages, and custom development. Each type has unique characteristics and implications.

  • SaaS characteristics include packaged software with well defined interfaces. A third party controls the lifecycle. Customization is not available.

Best used for business activities that are administrative and indirectly support value producing activity. The tight software restrictions drive restrictions in business activity and help force adoption of standard industry practices.

  • Enterprise suites characteristics include multiple overlapping functional models, with defined data model. Interfaces and functionality can be configured or customized. Customizations invariably create addition cost during the lifecycle. Lifecycle is influenced by a third party.
  • Specialist commercial packages characteristics include point focus and functional optimization for the specialist activity. Typically designed around one way of approaching the business activity. Usually has a unique, well-defined data model. Interfaces and functionality can be configured. Customization might be possible. Customizations invariably create significant cost during the lifecycle. Lifecycle is heavily influenced by a third party.
  • Custom development characteristics include direct alignment between your organization’s legacy organizational boundaries and activities. Invariably designed to support the existing communication model of your organization. Point focus and functional optimization for the specialist activity. Expect a poorly defined data model. Interfaces and functionality must be customized. Lifecycle management is usually ignored and carries a high ongoing cost.

Best used for business activities in the primary value chain. The flexibility allows optimization of how value is generated. Effective use requires understanding value generation today and in the future.

System Model

The system model is an abstraction of software around an activity. Think about the ‘supply chain system’ and everything that is involved in the supply chain. The design of your system model will align with how your enterprise runs.

Like the business architect’s capability model, a system model allows you to direct thinking to a system. You can look at improving a complete system, then focus the required changes on everything that comprises the system and interacts with it.

Functional Model

The Functional model breaks your software portfolio down to functionality. It identifies all the things your software needs to do. Good functional models provide broad coverage.

Like the business architect’s process model, a functional model is often a reference architecture. It is powerful when you are looking for duplication and integration. Often forms the basis of an Application Development Model, where different Functional blocks are assigned a target application development type.

Critical in application portfolio planning. Duplication and Integration drive complexity and cost into the IT Portfolio.

BIAN, FEAF, TMForum's ODF, and IndEA all provide Functional Models.

Product Model

A Product Model is a specialized version of a Functional Model that highlights the functions required for your Products or services. A good Product Model will classify what is performed in comparable terms.

A good Product Model will form the basis of a reference architecture for your products. You need to specify functions that are central to the product's value, use, and administration. A Product model will inform the Application Development Model choices. You need Custom Development, duplication, and a significantly higher ability to change when the functions are associated with your Products and Services.

Integration Model

An Integration Model identifies boundaries in your software and the method the boundary is crossed. Don’t be afraid to specify that the boundary cannot be crossed or must be crossed manually. A lot of weak application integration only delivers rigidity. Developing a useful Integration Model requires iteration with a Business Architect’s work developing an Organizational Map and Information Model. The Integration Model, Organizational Map, and Information Model inform and constrain each other.

The Integration model is critical in enabling enterprise agility, managing the application portfolio, and lowering IT cost.

Service Model

A Service Model is a specialized version of a Functional Model that collapses Functionality into a black box with known interfaces. A good Service Model is invaluable in developing the Application Development Model and validating the Target in a System Model. The interfaces in your Service Model should all be well identified in your Integration Model.

A good Service Model will enable enterprise agility. Not from the development if application services, but by freeing change in one part of your enterprise from another.

Physical Model

A Physical Model is the real software portfolio. We will describe it in terms used by commercial software vendors and your application development program. You will need to associate this to the other Application Architecture Models to transition the Target into the real-world.

You use the Physical Model as a constraint on the abstract application architecture models. It also forms the basis of the Implementation and Migration Plan developed through Phase F.

Application Architecture Techniques

We use a broad set of techniques to develop and communicate our application architecture.

  • UML is ubiquitous in good model-driven-development. When you are working in Architecture to support Solution Development, a Functional Model and Integration model should be developed following UML practices.
  • 4+1 Views are very useful in identifying the implication of the Target for different communities. Developing 4+1 models helps ensure you are considering all relevant changes.
  • DODAF's Information Needlines pull out all required information flows. It doesn't matter if the node is a person, an organization, or a system. Information will flow in and out. The fastest way to eliminate automation is to put manual steps in the middle of an information flow.

Application Architecture Models Aligned to Enterprise Architecture Purpose

The level of question you are answering with your business architecture will drive use of different business architecture models. For example, Architecture to support Portfolio often won't develop a Value Chain model. Instead, a Value Chain will usually be superior architecture and constrain your freedom.

Architecture to Support Strategy Architecture to Support Portfolio Architecture to Support Project Architecture to Support Solution Delivery
Application Development Model Key Deliverable Key Deliverable Superior Architecture Superior Architecture
System Model Regular Deliverable Key Deliverable Superior Architecture Superior Architecture
Functional Model Regular Deliverable Key Deliverable Key Deliverable & Superior Architecture Key Deliverable & Superior Architecture
Product Model Occasional Deliverable

Appropriate level of detail often diminishes value

Regular Deliverable

Appropriate level of detail often diminishes value

Key Deliverable Key Deliverable
Integration Model Occasional Deliverable

Appropriate level of detail often diminishes value

Regular Deliverable

Appropriate level of detail often diminishes value

Key Deliverable Key Deliverable & Superior Architecture
Service Model Occasional Deliverable

Appropriate level of detail often diminishes value

Regular Deliverable Key Deliverable & Superior Architecture Key Deliverable & Superior Architecture

Business Architecture Models Influence on Application Architecture Models

Business Model Operating Model Value Chain Capability Model Process Model Functional Model Information Model Organization Model
Application Development Model Major input

Requires a System or Functional Model

Major input

Requires a System or Functional Model

Major input

Requires a System or Functional Model

Major input

Requires a System or Functional Model

Major input

Requires a System or Functional Model

Major input

Requires a System or Functional Model

Limited Input Limited Input
System Model Limited Input Limited Input Limited Input Limited Input Limited Input Major Input Limited Input Major Input
Product Model Major Input Major Input Major Input Limited Input Limited Input Limited Input Limited Input
Integration Model Very Limited Input Major Input on core design

Requires a System or Functional Model

Major Input on core design

Requires a System or Functional Model

Best Input

A direct link is very difficult to see. It is worth doing the work.

Major Input on core design

Requires a System or Functional Model

Limited Input

Use only if other models are not available

Major Input on core design

Requires a System or Functional Model

Major Input on core design

Requires a System or Functional Model

Service Model Limited Input

The linkages are important, but a direct link is very difficult to see

Limited Input

The linkages are important, but a direct link is very difficult to see

Limited Input

The linkages are important, but a direct link is very difficult to see

Best Input

A direct link is very difficult to see. It is worth doing the work.

Used as a completeness test Major Input

A direct link is very difficult to see. It is worth doing the work.

Major Input

Application Architecture Models for Enterprise Architecture Use Cases

All enterprise architecture use cases are about change. They all look at types of change, and how an enterprise architect helps decision makers chart a path forward.

I consider the enterprise architecture use cases as the type of change, purpose of the enterprise architecture team, or questions commonly asked.

In every enterprise architecture use case, we are performing the same function. We assist stakeholder make better decisions and lead successful change initiatives. All that changes is the question.

Strategic Change Incremental Change Improve Cost Improve Quality Improve Enterprise Agility Mitigating Technology Risk IT Modernization Digital Transformation Application Portfolio Rationalization Acquisition Integration
Application Development Model Key constraints Key guidelines Critical constraints Critical constraints Critical gaps and constraints Critical gaps and constraints Critical gaps and constraints Critical gaps and constraints
System Model Very useful

Critical gaps and constraints

Critical gaps and constraints Critical gaps and constraints Critical gaps and constraints Critical gaps and constraints
Product Model Critical gaps and constraints Critical gaps and constraints Critical gaps and constraints Critical gaps and constraints Critical gaps and constraints
Integration Model Informing constraints Critical gaps and constraints Critical gaps and constraints Critical gaps and constraints Critical gaps and constraints Critical gaps and constraints Critical gaps and constraints Critical gaps and constraints Critical gaps and constraints
Service Model Very useful for gaps and constraints Very useful for gaps and constraints Very useful for gaps and constraints Very useful for gaps and constraints Very useful for gaps and constraints Very useful for gaps and constraints Very useful for gaps and constraints

Applying Enterprise Architecture Principles to Application Architecture

We have identified 7 Architecture Principles every enterprise architect should know. The following table identified the implications of these Architecture Principles to the Application Architecture. When performing enterprise architecture governance, you need to test your Application Architecture to ensure that it is conforming to superior architecture. Here, is it conforming to the enterprise architecture principles?

Application Architecture Implication
Don’t Mess With Success If the program is not differentiation or transformation, look to eliminate change. Look to avoid all change to process or system that is not explicitly cost & outcome justified.
Focus On Excellence Align with the Operating Model the Capability Model.

Leverage Application Development Model to focus spend on differentiation.

Leverage Product Model to focus on the delivery of Product & Service.

Why Not One? Leverage Application Development Model & Product Model to identify areas where duplication is prohibited.
Data is an Asset Ensure control of the data model is not surrendered in ways that diminish the value of data asset.
Systems Work Where We Work Work location and work style drive interface and application model.
Painless User Experience Efficiency programs focus on existing business process.

Differentiation & transformation programs require change to user interface & engagement as experience with new process is developed.

Self Service Application administrative activities & deployment are high cost when they are not self-service

Weak UX is high cost..

How does TOGAF Phase C align with Agile Development?

The Application Architecture will provide multiple constraints and guidance to agile development. The fundamental guidance comes from the Application Development Model. It identifies where you do not want agile development.

Enterprise Architecture and Agile Development will interest on four areas. The enterprise architecture will:

  1. define the agile approach
  2. guide the backlog in sprint
  3. constrain choices inside the sprints
  4. solve for cross product dependency

We always focus agile development on novel differentiating activity and ruthlessly follow established best practice elsewhere. Best practice comes from established commercial software. Make sure you align your application architecture to your business architecture and focus on how you acquire systems.

How does TOGAF Phase C enable with Enterprise Agility?

Enterprise agility has nothing to do with how you write software. Enterprise agility is about your enterprise's ability to react to unexpected threats and opportunities. If you need to write code, your ability to respond to a threat or opportunity is at risk.

An application architect will focus on the fifth aspect of the enterprise agility model - Flexibility. We use the same Agility attribute and scores in the Capability Assessment Guide to identify the information systems that must be capable of rapid change. Then we architect to enable change.

Enterprise Agility Model

  1. Alertness – Can you detect opportunities and threats?
  2. Accessibility – Can you access relevant information in time to respond?
  3. Decisiveness – Can you decide using the available information?
  4. Swiftness – Can you implement your decisions in the time available?
  5. Flexibility – What are you doing to reduce the barriers to action?
TOGAF ADM Phase C Application Architecture Models

Final Thoughts on TOGAF ADM Phase C

Application Architects working with an Enterprise Architecture Team have a set of responsibilities more important than designing an application. They need to develop the guidelines and guardrails for the people to architect, design, implement, and develop the enterprise's application portfolio. In short, the enterprise application architect is distinct from a solution architect, or an application architect who doesn't work with an EA Team.

Application Architects working in TOGAF ADM Phase C have a complex role.

  • work with stakeholder and SME to select changes in the application portfolio that enable the best future organization
  • work with their peer domain architects to explore how improvements required in the business domain are enabled or prevented in the application domain
  • work with stakeholders to eliminate changes in the application portfolio that deliver too little or cost too much. Also, eliminate changes in other domains that drive unacceptable cost and change into the application portfolio

In TOGAF ADM Phase C, one of the four foundational enterprise architecture domains is developed. TOGAF is very clear you develop this architecture during the development of the other domains. Changes in one domain will enable, force, or block changes in another domain.

High functioning EA Teams do not use their application architects as designers of a single application. That role is necessary, but without an application architecture that covers significant parts of the enterprise you cannot optimize the enterprise.

TOGAF ADM Phase C develops the application architecture. Application architecture is the foundation of all modern digital enterprises. Use TOGAF Phase C to focus scarce change resources on gaining the most enterprise value.

Scroll to Top