TOGAF® ADM Phase B—Develop the Business Architecture
At a Glance
- TOGAF ADM OverView
- What is TOGAF Phase B?
- TOGAF ADM Phase B Deliverables
- What is the Role of the Enterprise Architect in Phase B?
- What is the Role of the Business Architect?
- Business Architecture Models, Tools, and Techniques
- Business Architecture Models
- How does Phase B of TOGAF align with Agile?
- Final Thoughts on TOGAF ADM Phase B
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 upon for 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 B?
In TOGAF Phase B, you are creating the business architecture. Business architects should lead the development of your business architect. The consistent description of your business that tells you how your organization, processes, staff and locations are constructed to succeed. You know the definition of success. Most importantly, you know what must change to improve your organization.
Developing a business architecture requires engagement with stakeholder. With the stakeholder, the business architect explores how an organization is deficient. They explore potential improvements. Winnow changes that deliver too little, require too much work, or have too much uncertainty.
When we are developing enterprise architecture teams, we tell the enterprise architects two central facts about TOGAF Phase B. The first thing is that if they are using their business architects to translate hopes, fears, and pre-built change plans from 'the business' they are doomed to low maturity. Second, if they believe they sequentially develop an enterprise architecture, they will always develop a low-quality architecture.
In a modern digitally transformed enterprise, all architecture domains interact. Changes in any domain can reach objectives in another. We often perform mitigations in a different domain than the risk. In fact, we can only achieve many business objectives with the right IT Architecture. Ironically, we can only develop the right IT Architecture if we have a solid business architecture.
What is the Objective of TOGAF ADM Phase B?
In Phase A, you identify a potential summary enterprise architecture, the Architecture Vision. The vision will include all domains, including business architecture. Phase B, develops the summary 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 B is the candidate business architecture. The business architect works with other domain architects to understand constraints being placed on the business architecture, and what constraints are being placed on other domains.
Remember, the TOGAF ADM is used to explore potential changes. Until you are completing an Implementation Plan in Phase F, there are inexpensive off-ramps. The further a bad idea progresses, the more expensive the off-ramp. One of the most important values from developing a business architecture is winnowing weak ideas. The moment the cost of the change exceeds the expected value, stop dead in your tracks. Kill the architecture development project. Celebrate that you have minimized the waste of scarce change resources.
Interaction with TOGAF Phase C, Phase D, Phase E, and Phase F
Developing an enterprise architecture is not a waterfall activity. Always assume that developing the business architecture, application architecture, data architecture, technology architecture and security architecture occurs simultaneously. The classic sequence implied in many 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 it 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.
Business architects work on an enterprise architecture team. They are not the communicators with 'the business.' They are specialists in one architecture domain. They cannot architect their domain without regular engagement with application, data, technology, and security architects.
TOGAF ADM Phase B Deliverables
The central outcome of Phase B is a business architecture. One part of the complete enterprise architecture. Within the business architecture domain it will describe:
- How the enterprise is captures value -Â Business Model
- How the enterprise runs - Operating Model
- Activities required to create the product or service - Value Chain
- The things an organization must be able to do - Capability Model
- The flow of information to perform an enterprise' activities - Information Model
- The complete activities an enterprise performs, typically grouped to show how they relate to each other - Process Model
- How an enterprise is organized - Organizational Model
- How an enterprise's activities are grouped in organizational terms - Functional Model
Keep in mind what you are trying to describe, and accept the reality that we did not well define these terms in the industry. For example, what you call a functional model someone else will call a process. 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 business architecture.
Completion of Phase B
All TOGAF ADM Phases lead you to developing the knowledge you need. The outcome of Phase B is the candidate business architecture.
| Output & Outcome | Essential Knowledge |
| The business 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 Enterprise fails to meet the preferences of the stakeholders?
What must change to enable the Enterprise 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 B Bare Bones
In Phase B, we can simplify the work of a business 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 B are:
- Knowing how the enterprise is captures value
Different organizations in the same industry capture value differently. Consider a discount airline and an airline focused on business travellers. Both do the same thing, fly people and goods from one location to another. Both capture value and compete on different criteria.
- Knowing how the enterprise is structured to succeed
How do you assemble the core activity of the enterprise? Core activity comes directly from the business model.
- Knowing the activities that generate value and those that support value generation
Michael Porter invented the value chain - primary activities that generate value and supporting activities that enable the primary. We optimize primary activities for value generation. We optimized supporting for efficiency.
- What activities that must be improved or protected from degrading
Capabilities are key activities. We use a capability model as a management concept to focus attention on the things we must improve. See the Business Architecture Capability Assessment Guide.
- What the organization must perform
Every enterprise has a set of processes it must perform: primary, secondary, administrative. You need to know what they are, the information they consume, and who does them.
- How the organization should be organized
We design successful enterprises. We design their organization. Their organization supports their business model, their operating model, and fits within their ecosystem.
- Which organizations perform which activities
When you know the business model and operating model and the set of processes, you can make sure the right organization performs an activity. Often you need to define how they will perform the activity.
- What must change to deliver the best organization?
We develop enterprise architecture to improve an organization. We deliver business architecture for the same reason.
The three completion essentials of Phase B:
- 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 business architect owns describing the governance tests to enable the stakeholders to direct the change project.the second and third outcomes.
TOGAF Phase B Deliverables and Enterprise Architecture Purposes
There are four core purposes for developing enterprise architecture. Different 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 B Work Product: Candidate Business 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 B 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 B 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 Business Architecture
There are four core purposes for developing enterprise architecture. Different models have different importance in each purpose.
>>> Jump to the common Business Architecture Models
Candidate Business Architecture Roadmap Components
What must change? If you are changing the Business Model, then the difference between current and target business model is the Roadmap Candidate. If it is changing a processes performer from in-house to an out-sourcer, that is the change.
We often use the Capability Model to summarize the change. We use capabilities as a management concept. The ability to do something a certain way combines the process, organization and IT system changes. We usually use scores to articulate a change. For more information on using scores, see the Business Architecture Capability Assessment Guide.
We will combine Business Architecture Roadmap components all the other domain architectures in TOGAF Phase E - Architecture Roadmap.
Candidate Business Architecture Requirements Specification
Define how you will assess the change.
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
For an excellent guide to different attributes and scores, grab a free copy of our Business Architecture Capability Assessment Guide. We use this set of attributes for Capability, Process and Functional Models.
We use all Architecture Roadmap components in TOGAF Phase E - Architecture Roadmap.
What is the role of the Business Architect in Phase B?
In TOGAF Phase B, we expect the Business 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 business architect will need to collaborate with the other domain architects. 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 B?
In TOGAF Phase B, 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 a business architect 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.
Business Architecture Models, Tools, and Techniques
The TOGAF ADM Phase B is called Business Architecture. This Phase exists to develop the business architecture. In TOGAF, the first step is to determine the views required, and the models required.
There are eight central business architecture models.
- Business Model that describes how value is captured
- Operating model that captures how the enterprise runs to capture value
- Value Chain that describes the sequence of primary activities that create value and the required supporting activities to enable the value generating work
- Capability model - a planning construct that focuses attention on what must change
- Process model - what activities a business must perform
- Functional model - how an enterprise's activities are grouped between different organizations
- Information Model - the information that needs to flow to perform primary, supporting and other necessary activities
- Organizational model - how authority, accountability, and resources are divided and managed
Within Navigate we use also use
- OMG's Business Motivation Model
- Strategyzer's Business Model Canvas
- DODAF's Information Needlines
- Mintzeberg's Organigraph
- CISR's Operating Model
Business 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 | |
| Business Model | Key Deliverable | Occasional Deliverable | Superior Architecture | Superior Architecture |
| Operating Model | Key Deliverable | Key Deliverable | Superior Architecture | Superior Architecture |
| Value Chain Model | Key Deliverable | Occasional Deliverable | Superior Architecture | Superior Architecture |
| Capability Model | Regular Deliverable
Usually able to summarize the change for planning |
Key Deliverable
Usually able to summarize the change for planning |
Key Deliverable
Usually able to plan the change |
Superior Architecture
Usually able to govern the change |
| Information Model | Occasional Deliverable - will be summarized | Key Deliverable | Key Deliverable & Superior Architecture | Key Deliverable & Superior Architecture |
| Organizational Model | Regular Deliverable - top level tied to Operating Model | Regular Deliverable - top level tied to Operating and Functional Model | Regular Deliverable - tied to Functional Model | Superior Architecture |
| Functional Model | Regular Deliverable - top level tied to Operating Model | Regular Deliverable - top level tied to Operating Model | Regular Deliverable - tied to scope of change | Superior Architecture |
Business Architecture Models
Developing a business architecture will require developing several enterprise architecture models. Each enterprise architecture model describes a fundamental structure or group of structures. Different models explain the enterprise in a different way.
Taken together, the models describe the business architecture. In the complete enterprise architecture, these models will link to other models that describe the other enterprise architecture domains.
Business Model
The Business Model describes how value is captured. We will often use Strategyzer's Business Model Canvas to develop and document a business model.
The Business Model Canvas works well for one product or service. As a modelling technique, it struggles with complex business models. In fact, one of the strengths of the Business model canvas is identifying where the business model is becoming muddy.
Application Architects working in TOGAF Phase C will expect to know every time a Product or Service is based on software. As well they cannot construct a solid Application Architecture without knowing the software basis of Key Activities and Key Resources.
Operating Model
Operating models describe how a business structures its core activities. Typically, an operating model shows the unique capabilities aligned with the enterprise's strategy, skilled leadership teams, or unique investment profiles.
The Operating model is an anchor for the enterprise. It is critical for the strategy's effectiveness and longevity.
CISR's Operating Model provides a powerful reference. The simple characterization of an enterprise as either Unified, Replicated, Diversified, or Coordinated is powerful. Right there you know the basic structure of the enterprise and it informs the Application Architect working in TOGAF Phase C.
We will often use a Kaplan Strategy Map to identify the changes or focus required in an operating model.
Value Chain
A value chain diagram is a high-level representation of an organization's activities to generate value. A classic Porter Value Chain diagram separates supporting activity from primary activity. Primary activity is sequences to show the hand-off of activity in a value chain. In a Porter diagram, we always put the supporting activity on the top - all supporting activity is a burden on the primary activity. The primary activity must produce enough customer value to pay for the supporting activities.
We can further break a Value Chain down into pillars or value streams.
Capability Model
Capability models are used to focus attention. A good process model is comprehensive. A good functional model is both comprehensive and organizationally aware. A good capability model is a subset of the activities and organization. We should focus the subset on the activities that must be improved or sustained to reach the desired outcome.
When we use a Business Model Canvas the capabilities in Key Resources, Key Activities and the Customer Channel leap off the page. When we use a Kaplan Strategy Map, everything placed on the map is a capability.
We use scores to explain improvements and changes in capability planning. See the Business Architecture Capability Assessment Guide. Business Architects should expect the Application Architect working in TOGAF Phase C to ask for Competency and Automation attributes.
Process Model
Process models identify all the activities in scope. We often use the APQC Process Classification Framework as a reference architecture. APQC's framework is consistent and comprehensive.
It is a common mistake to link the OMG's BPMN to good business architecture. If you are using BPMN, you have probably slipped from architecture into design.
We use scores to explain improvements and changes in the processes. The same attributes and scores in theCapability Assessment Guide work on developing a strong process model.
Functional Model
Functional models identify all the activities with an organizational overlay. We link required activity to authority, resources and location in a Functional Model.
We use scores to explain improvements and changes. The same attributes and scores in the Capability Assessment Guide work on developing a strong process model.
Information Model
Under TOGAF, the business information model reflects the semantics of an organization's data, not a database design. It outlines the items that are important to an organization and about which it is likely to gather data (as entities), as well as linkages between pairs of those important things (as relationships). Because it avoids many of the system-level components, it is an easier model to interpret than a Logical Data Model. It encompasses all company information, not only digital information.
In most cases, each firm has only one Business Information Model, which describes all relevant data throughout the entire organization. We may use one or more diagrams to graphically represent all or part of the information model.
Organization Model
All enterprises have unique structures for authority, resource, and work location. Many organizational structures are haphazard. Often based on prior organizational design and personality.
Organizations seeking to excel need to be very deliberate about organizational design. For example, if you use CISR's Operating Model as a reference, the design of a unified, diversified, and replicated organization will be very different.
Business Architecture Techniques
We use a broad set of techniques to develop and communicate our business architecture.
- OMG's Business Motivation Model helps clarify what we are trying to accomplish and how we normally go about accomplishing an aim
- Strategyzer's Business Model Canvas pulls out the core product or service value proposition and what we need to excel.
- DODAF's Information Needlines pull out all required information flows. It doesn't matter if the activity is a primary value producer, a supporting activity, or purely administrative information will flow in and out. The fastest way to degrade an activity is to inject substandard information.
- Mintzeberg's Organigraph helps you understand how the business operates for success. Few enterprises work in their organizational design.
- CISR's Operating Model is a foundation for design. The four classic choices of Unified, Diversified, Replicated, or Coordinated.
How does Phase B of TOGAF align with Agile?
Agile development is often confused with an agile enterprise. Nothing can be further from the truth. The business architecture will normally identify where your business needs novel systems to excel and where it needs to chase established best-practice.
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.
Enterprise Architecture and Agile Development will interest 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
How does Phase B of TOGAF align 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.
A business architect will focus on the fifth aspect of the enterprise agility model - Flexibility. We use the Agility attribute and scores in the Capability Assessment Guide to identify the business capability, information systems, and processes that must be capable of rapid change. Then 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?
Final Thoughts on TOGAF ADM Phase B
Business architects are not translators from 'the business' to the IT department. Instead, good business architects use TOGAF ADM Phase B as a framework to develop the business architecture. They have a complex role.
- work with stakeholders to explore improvements
- work with their peer domain architects to explore how those improvements result in a change in different architecture domains
- winnow out the changes that deliver too little, are too much work, or are at the wrong time
In TOGAF ADM Phase B the business architecture is one of the four foundational enterprise architecture domains. TOGAF is very clear - your application and data architecture exist to enable the business architecture.
Remember, high functioning EA Teams do not use their business architects as translators or the communication channel with 'the business.' Good EA teams work as a team, and use their business architects as specialists in the business architecture domain.
TOGAF ADM Phase B develops the business architecture. Business architecture is the foundation of all good enterprise architecture. Use TOGAF Phase B to focus scarce change resources on gaining the most enterprise value.