TOGAF ADM Phase C—Develop the Application Architecture
At a Glance
- TOGAF Phase C in Action
- What is Application Architecture
- What is the Role of the Enterprise Architect in Phase C?
- What is the Role of the Application Architect?
- What is the Role of the Security Architect in Application Architecture?
- What is the Role of the EA Team in Application Architecture?
Final Thoughts on TOGAF ADM Phase C - Application Architecture
TOGAF ADM Overview
The TOGAF ADM is a logical approach to creating knowledge. Knowledge used to develop an enterprise architecture that guides effective change. Then knowledge to ensure expected value is achieved.
The TOGAF ADM is broken into Phases, each Phase is focused on creating knowledge that is used to:
- select the path forward and the target
- perform implementation governance
- assess the journey forward and course correct
What is TOGAF Phase C?
Phase C drives further on concept of architecture domains. This phase develops the application architecture and data architecture. Formally Phase C splits treats the Data Architecture Domain and the Application Architecture Domain are individually.
Like Phase B, Phase C builds on the Architecture Vison. There is a twist, Phase C has a further obligation to enable the business architecture. This is not treating the business architecture as requirements, rather to confirm the developing summary targets hold together.
Changes in one domain drive constraints and requirements into other domains. The objective is to find the best set of changes across all domains.
Using the steps of Phase C, architects develop the following knowledge:
- what reference architecture will speed architecture development
- what viewpoints will drive relevant analysis for stakeholder to select between architecture alternatives
- what application architecture models and data models will help find the source of the deficiency and the changes that will address it
- where changes in the application architecture drive change in other domains
- where changes in other domains drive changes in the application architecture
It creates the following central works products:
- views that analyze the candidate information systems architecture in terms of the stakeholder's concerns
- that a current and candidate target application architecture
- application architecture gaps
- candidate work products that change the business
Phase C centers on things like application design, data flow, integration, development approach, build vs buy, and change planning. Proper assessment and understanding of this phase are critical.
What is TOGAF Phase C?
In TOGAF Phase C, you are creating the application architecture. Application architects lead the development of your application architecture. The architectural decisions made in Phase C for application architecture interact with decisions made in every enterprise architecture domain.
Phase C in Action
The Application Architecture will help answer the following questions:
- How the application portfolio enables value capture – Application Development Model
- Where cost is injected into the IT Portfolio - Functional Model
- Where rigidity is injected into the IT Portfolio - Integration Model
- How the enterprise runs – System Model
- Systems required to deliver the product or service – Product Model
- The things an organization must be able to do - Functional Model
- The flow of information to required to perform an enterprise' activities - Integration Model
- The complete activities an enterprise performs, typically grouped to show how they relate to each other – Service Model
- What the software portfolio is – Physical Model
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.
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 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.
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.
What is the role of the Security 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.
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 EA Team in Application Architecture
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.
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.
Download Business Leader’s Guide to AI
Download Business Leader’s Guide to Artificial Intelligence Organizations that successfully apply innovative technology have had a competitive advantage. Innovative technology does not come with established success patterns and best practices. Innovative technology is novel and […]
Download the Introduction to the TOGAF Standard, 10th Edition
Download Introduction to the TOGAF® Standard, 10th Edition The TOGAF Standard, 10th Edition makes adoption of enterprise architecture best practices easier. It separates the universal concepts from proven best practice. The standard underscore where to […]
Download Capability-based Planning Guide
Download Capability-based Planning Guide Always drive to realize value. Half an improvement is 100% waste! No one teaches an Eagle to crawl, walk, or run. Eagles Fly! Download Teach your Eagles to Fly: Capability-based Planning […]
Download Business Architecture Capability Assessment Guide
Download Business Architecture Capability Assessment Guide Download a Business Architecture Capability Assessment Guide. Capability-based planning is one of the most powerful business architecture improvement techniques. Best practice of capability-based planning uses capability as a management […]
Download Sample Enterprise Architecture Principles
Download Sample Architecture Principles Download a sample enterprise architecture principles. Enterprise Architecture principles identify how to approach a problem or decision. The approach always drives you towards your enduring priorities. Download Sample Enterprise Architecture Principles […]
Download Enterprise Architecture Governance Guide
Download Enterprise Architecture Governance Guide Download the Enterprise Architecture Governance Guide to understand best practice to direct and control the development of architecture, and change to obtain the expected outcomes. Download Enterprise Architecture Governance Guide […]
Download TOGAF and SABSA Integration
Download TOGAF and SABSA Integration Bring SABSA, the world’s best security architecture framework, and TOGAF, the industry standard enterprise architecture framework together. Download TOGAF and SABSA Integration TOGAF and SABSA Integration Includes SABSA uses a […]
Download Enterprise Architecture Capability Reference Architecture
Download Enterprise Architecture Capability Reference Architecture The Enterprise Architecture Capability Reference Architecture will speed up establishing and enhancing your EA Team. Design your Enterprise Architecture Team for success. Identify and enhance the your enterprise architecture […]
Download Agile Enterprise Architecture Report
Download the Agile Enterprise Architecture Report The Agile Enterprise Architecture Report covers our experience – Agile Enterprise Architecture is real, practical and valuable. We do it every day. Field reports bridge the theoretical concepts and […]
Download Agile Enterprise Architecture Case Study
Download the Agile Enterprise Architecture Case Study Download the Agile Enterprise Architecture Case Study to see an example developing an EA Capability and useful architecture at the same time. We cover all six use cases […]
Phase C Essential Knowledge
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 4 from 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.
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. With digital products an ubiquitous IT Services understanding ITFM is a foundational skill.
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 dependencies? 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 application architect owns describing the governance tests to enable the stakeholders to direct the change project, the second and third outcomes.
Enterprise Architecture Training and TOGAF Training
Avolution ABACUS Training Course
Avolution ABACUS Training Effective enterprise architecture relies on formal modeling and analysis. We provide Avolution ABACUS training from hand-on enterprise architects. Students gain skills and knowledge to create integrated enterprise and domain architectures in this […]
Effective Online Education
Effective Online Education Effective online education works. Students to access the best available instructor. Students control the pace of their learning. Instructors can share rich supplemental material without distracting from the primary topic. Effective distance […]
Enterprise Architect’s Kickstart
Enterprise Architect’s Kickstart We need to keep our skills current. More now than ever. Use the Enterprise Architecture Kickstart to improve your ability to deliver transformative enterprise architecture. This 90-day kick-start is how Conexiam Consulting […]
TOGAF Enterprise Architecture Training Course
Do you want training for TOGAF Certification? Demonstrate your knowledge of enterprise architecture with TOGAF Certification TOGAF® Enterprise Architecture Training Course Take a major step to be a better enterprise architect with TOGAF Standard, 10th […]
Business Architecture Training Course
Business Architecture Training Effective enterprise architecture relies on business architecture. The course gives students the skills and knowledge to develop business architecture in an enterprise architecture setting. Business architecture involves describing the structure of the […]
Custom Enterprise Architecture Training
Custom Enterprise Architecture Training Custom enterprise architecture training addresses the professional development your EA Team needs. Good enterprise architects use a broad set of skills, method, in addition to specialized domain knowledge to develop enterprise […]
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.
TOGAF Phase C Application Architecture Deliverables and Enterprise Architecture Use Cases
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 3 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.
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.
Go Further with Best Practice Enterprise Architecture Process and Method
Best practice enterprise architecture from Conexiam Navigate
Developing Enterprise Architecture Strategy
Developing Enterprise Architecture Strategy: Strategic Plan for Change Enterprise Architecture Strategy is action. Action your organization will take and the changes you will make to reach your strategic goals. Strategy development is all about choice. […]
Making Smarter Choices: Why Your Business Needs Architectural Decisions
Making Smarter Choices: Why Your Business Needs Architectural Decisions Enterprises are constantly confronted with the challenge of making crucial decisions. Every day, decisions, including operational practices and technology selections, have a significant impact on a […]
Unlocking the Power of Capability-Based Planning: A Quick Guide
Unlocking the Power of Capability-Based Planning: A Quick Guide Are you looking for a more effective way to plan and execute your business strategy? Look no further than capability-based planning. Identifying and using your organization’s […]
Ensuring Alignment and Accountability: The Crucial Role of Enterprise Architecture Governance Checklists
Ensuring Alignment and Accountability: The Crucial Role of Enterprise Architecture Governance Checklists Enterprise Architecture Governance Checklists simplify enterprise architecture governance processes. The governance process needs to approve target architecture and provide implementation governance. A robust enterprise […]
How to Define Enterprise Architecture Principles
How to Define Enterprise Architecture Principles To Define Enterprise Architecture Principles start with understanding what a principle is and how to apply them. Then we can develop strong architecture principles that help improve our organization. […]
Best Practices to Implement Enterprise Architecture Management Tools
Best Practices to Implement Enterprise Architecture Management Tools Enterprise Architecture Management Tools are designed to support the planning, design, analysis, and execution of enterprise architecture. They enable enterprise architects to examine the need for change […]
Understanding Enterprise Architecture and Agile
Understanding Enterprise Architecture and Agile Both agile and enterprise architecture are designed to reduce risk. Agile software development excels at building something that we have never had before and do not know how to build. […]
Enterprise Architecture Framework Comparison: Which Is Right for You?
Enterprise Architecture Framework Comparison: Which Is Right for You? There’s no one-size-fits-all in business. Nor in enterprise architecture frameworks. Compare the merits of popular frameworks to deletermine what optimized framework is right for you. While […]
Enterprise Architecture Work Management
Enterprise Architecture Work Management Enterprise Architecture Work Management is crucial to the day-to-day success of an Enterprise Architecture Team. Architects must deliver useful guidance before stakeholders make informed decisions. Enterprise architects need to translate the […]
Developing an Architecture View
Developing an Architecture View Enterprise architecture is an essential compass. It helps organizations navigate the complexities of technology, strategy, and operations. The core of enterprise architecture is a systematic approach. The objective is to ensure […]
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
The Application Architecture will help answer the following questions:
- How the application portfolio enables value capture – Application Development Model
- Where cost is injected into the IT Portfolio - Functional Model
- Where rigidity is injected into the IT Portfolio - Integration Model
- How the enterprise runs – System Model
- Systems required to deliver the product or service – Product Model
- The things an organization must be able to do - Functional Model
- The flow of information to required to perform an enterprise' activities - Integration Model
- The complete activities an enterprise performs, typically grouped to show how they relate to each other – Service Model
- What the software portfolio is – Physical Model
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.
Application Architecture Patterns
We use architecture Patterns to dramatically increase the productivity and quality of our architecture development. The Architecture Pattern Template drives us to understanding the predictable problem, pattern approach, and the Hard Bits. Success with the pattern requires addressing the Hard Bits (required work, constraints and limitations).
Sample Application Architecture Patterns
Sample Application architecture patterns cover the problem of applications structure, migration, and how to application design.
- Application Structure
- MVC (Model-View-Controller) Pattern
Predictable problem—code organization, maintainability, and testability
Approach—separates an application into three interconnected components—Model (data and business logic), View (user interface), and Controller (handles user input and updates the Model and View accordingly)
- MVC (Model-View-Controller) Pattern
- Application migration
- Strangler Pattern
Predictable problem—replacing legacy systems
Approach—gradually replace or “strangle” an existing legacy system by building new components around it to incrementally replace the system
- Strangler Pattern
- Application Design (Gang of Four Application Patterns)
As enterprise architects we use design patterns as constraints on the freedom of application development teams. (See Enterprise Architecture and Agile - Constrain Sprints)- Singleton Pattern- ensures a class has only one instance and provides a global point of access to that instance
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.
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.
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.
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.
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 Use Case
The level of question you are answering with your application architecture will drive use of different application 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 for 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 intersect on four areas. The enterprise architecture will:
- define the agile approach
- guide the backlog in sprint
- constrain choices inside the sprints
- 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
- Alertness – Can you detect opportunities and threats?
- Accessibility – Can you access relevant information in time to respond?
- Decisiveness – Can you decide using the available information?
- Swiftness – Can you implement your decisions in the time available?
- Flexibility – What are you doing to reduce the barriers to action?
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. Bad ideas don't mean you are not solving the problem. You should discard weak architecture alternatives. 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!
Application Architecture Patterns
We use architecture Patterns to dramatically increase the productivity and quality of our architecture development. We use a simplified Architecture Pattern Template that drives us to understanding the predictable problem, pattern approach, and the Hard Bits. Applicability of the pattern is usually driven by the required work, constraints and limitations.
Sample Application Architecture Patterns
Sample Application architecture patterns cover the problem of applications structure, migration, and how to application design.
- Application Structure
- MVC (Model-View-Controller) Pattern
Predictable problem—code organization, maintainability, and testability
Approach—separates an application into three interconnected components—Model (data and business logic), View (user interface), and Controller (handles user input and updates the Model and View accordingly)
- MVC (Model-View-Controller) Pattern
- Application migration
- Strangler Pattern
Predictable problem—replacing legacy systems
Approach—gradually replace or “strangle” an existing legacy system by building new components around it to incrementally replace the system
- Strangler Pattern
- Application Design (Gang of Four Application Patterns)
As enterprise architects we use design patterns as constraints on the freedom of application development teams. (See Enterprise Architecture and Agile - Constrain Sprints)- Singleton Pattern- ensures a class has only one instance and provides a global point of access to that instance
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.
