General How-To Information
This chapter describes the general how-to information provided in the TOGAF Standard.
Documentation
| Document | Summary |
|---|---|
TOGAF Series Guide: A Practitioners’ Approach to Developing Enterprise Architecture Following the TOGAF ADM |
This document is written for the Practitioner, the person who is tasked to develop, maintain, and use an Enterprise Architecture. Choice of the term Practitioner is deliberate, reflecting the role, rather than one of the myriad job titles in an enterprise the Practitioner may have. This document provides guidance on using the TOGAF framework to develop, maintain, and use an Enterprise Architecture. It is a companion to the TOGAF framework and is intended to bring the concepts and generic constructs in the TOGAF framework to life. It puts forward an approach to develop, maintain, and use an Enterprise Architecture that aligns to a set of requirements and expectations of the stakeholders and enables predictable value creation. |
TOGAF Series Guide: Using the TOGAF Standard in the Digital Enterprise |
This document is written for Enterprise Architects and Digital Practitioners. It describes what architecture practices would help grow a digital enterprise, and how the Enterprise Architect role can support a digital enterprise. It provides guidance on using the TOGAF Standard in alignment with the Digital Practitioner Body of Knowledge™ Standard, also known as the DPBoK™ Standard. |
TOGAF Series Guide: Digital Technology Adoption: A Guide to Readiness Assessment and Roadmap Development |
This document provides a technique that can be used by Enterprise Architects in leading and guiding the process of assessment for a Digital Transformation. This document covers the critical tenets of digital technology adoption for any organization. The application of this document is technology-neutral by design. The readers of this document will get a defined roadmap that could be leveraged for adopting digital technology. The intent of the document is to facilitate readers with a readiness assessment which is to be used as a toolkit. |
What is Enterprise Architecture?
In its simplest terms, Enterprise Architecture is used to describe the future state of an enterprise to guide the changes needed to reach that future state. The description of the future state enables key people to understand what must be in their enterprise to meet the enterprise’s goals, objective, mission, and vision in the context within which the enterprise operates. The gap between the enterprise’s current state and future state guides what must change within the enterprise.
Why Develop an Enterprise Architecture?
An Enterprise Architecture is developed for one very simple reason: to guide effective change.
All enterprises are seeking to improve. Regardless of whether it is a public, private, or social enterprise, there is a need for deliberate, effective change to improve. Improvement can be shareholder value or agility for a private enterprise, mandate-based value proposition or efficiency for a public enterprise, or simply an improvement of mission for a social enterprise.
Guidance on effective change will take place during the activity to realize the approved Enterprise Architecture. During implementation, Enterprise Architecture is used by the stakeholders to govern change. The first part of governance is to direct change activity – align the change with the optimal path to realizing the expected value. The second part of governance is to control the change activity – ensuring the change stays on the optimal path.
The scope of the improvement drives everything that is done. A methodology that serves to validate both the objective and the change, ensuring that both are feasible, delivers the desired value, and in a cost-effective manner. An architected approach provides a rigorous planning and change governance methodology.
Purposes of Enterprise Architecture
The four broad purposes of Enterprise Architecture can be considered as follows:
-
Enterprise Architecture to Support Strategy: deliver Enterprise Architecture to provide an end-to-end Target Architecture, and develop roadmaps of change over an extended period; for example, three years or more
An architecture for this purpose will typically span many change programs or portfolios. In this context, architecture is used to identify change initiatives and supporting portfolio and programs, set terms of reference, identify synergies, and govern the execution of strategy via portfolio and programs.
-
Enterprise Architecture to Support Portfolio: deliver Enterprise Architecture to support cross-functional, multi-phase, and multi-project change initiatives
An architecture for this purpose will typically span a single portfolio. In this context, architecture is used to identify projects, set their terms of reference, align their approaches, identify synergies, and govern their execution of projects.
-
Enterprise Architecture to Support Project: deliver Enterprise Architecture to support the enterprise’s project delivery method
An architecture for this purpose will typically span a single project. In this context, the architecture is used to clarify the purpose and value of the project, identify requirements to address synergy and future dependency, assure compliance with architectural governance, and to support integration and alignment between projects.
-
Enterprise Architecture to Support Solution Delivery: deliver Enterprise Architecture that is used to support the solution deployment
An architecture for this purpose will typically be a single project or a significant part of it. In this context, the architecture is used to define how the change will be designed and delivered, identify constraints, controls, and architecture requirements to the design, and, finally, act as a governance framework for change.
Developing an Enterprise Architecture
Developing an Enterprise Architecture is an iterative process. Different parts of the Enterprise Architecture are developed separately, in separate Architecture Projects[1]. Each Architecture Project extends, or refreshes, the Enterprise Architecture with the objective of enabling effective change. As a result, the ADM is all about creating useful information – architecture descriptions, constraints, or guidance that can be used. Best practice limits information gathering and analysis to the minimum necessary to address the question at hand. Following an incremental approach, effort spent returns the highest value when the resulting part of a comprehensive Enterprise Architecture is used to guide change that improves the organization.
The ADM is designed to identify the information required to develop part of an Enterprise Architecture, the steps to create consistent information inputs, and information outputs. Each phase of the ADM is described in isolation to provide clarity of the inputs, steps, and outputs, not to describe a sequence of work.
Phase A: The Starting Point
All architecture development as per the ADM needs to start with TOGAF ADM Phase A. Without the set-up inherent in Phase A, practitioners can expect to slide off course and fail to deliver useful architecture.
The set-up essentials of Phase A are as follows:
-
Define the scope of the Architecture Project
What problem are you solving? Define this in terms of the Enterprise Architecture Landscape (breadth and planning-horizon) and also in terms of purpose, which will tend to confirm the necessary level of detail. Be completely clear where in the business cycle this architecture will be used.
-
Identify stakeholders, concerns, and associated requirements
Explore the Enterprise Architecture Repository for superior architecture constraints and guidance. Develop a Stakeholder Map to understand which stakeholders must be served and what their concerns are.
-
Assess the capability of the Enterprise Architecture team
Take a hard look at the Enterprise Architecture team and confirm the ability of the team to deliver on this architecture development project. A good Enterprise Architecture team covers gaps in experience, skill, and bias to deliver the architecture that is useful, overcoming weaknesses of few members of the team.
The completion essentials of Phase A are:
-
Key stakeholder agreement on a summary of the target and the work to reach the target
Perform sufficient architecture development in all domains to enable you to communicate to the key stakeholders how the problem you have been assigned can be addressed and the scope of change to reach their articulated preferences. Be clear on the target, the value of the target, and the work needed to facilitate the change.
Essential ADM Outputs
A summary of the essential outcome and output is provided in Table 2. These are derived from the objectives of the ADM phase (see the ADM in Detail).
| Phase | Output & Outcome | Essential Knowledge |
|---|---|---|
Sufficient documentation to get permission to proceed. Permission to proceed to develop a Target Architecture to prove out a summary target. |
The scope of the problem being addressed. Those who have interests that are fundamental to the problem being addressed. (Stakeholders & Concerns) What summary answer to the problem is acceptable to the stakeholders? (Architecture Vision) Stakeholder priority and preference. What value does the summary answer provide? |
|
Phase B: Business Architecture,Phase C: Information Systems Architectures, & Phase D: Technology Architecture |
A set of domain architectures 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 does the current enterprise fail 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 is 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) |
A set of work packages that address the set of gaps, with an indication of value produced and effort required, and dependencies between the work packages to reach the adjusted target. |
Dependency between the set of changes. (Work Package & Gap dependency) Value, effort, and risk associated with each change and work package. How stakeholder priority and preference adjust in response to value, effort, and risk of change. |
|
An approved set of projects, containing the objective and any necessary constraints, resources required, and start and finish dates. |
Resources available to undertake the change. How stakeholder priority and preference adjust in response to value, effort, and risk of change. (Stakeholder Requirements) |
|
Completion of the projects to implement the changes necessary to reach the target state. |
Purpose and constraints on the implementation team. (Gap, Architecture Requirements Specification, Control) How stakeholder priority and preference adjust in response to success, value, effort, and risk of change. (Stakeholder Requirements) |
|
Direction to proceed with developing a Target Architecture that addresses perceived, real, or anticipated shortfalls in the enterprise relative to stakeholder preferences. |
Gaps between approved target, or preference, and realization from prior work. (Value Realization) Changes in preference or priority. (Stakeholder Requirements) |
Strategies for the Digital Enterprise
Two strategies can be defined that will improve the probability of success for the digital enterprise in any organization.
The Peek-Ahead Strategy
This first strategy is a “do it with the architecture enablement” approach. Enablement comes in the form of using just enough guidance on risks, standards, and best practices to deliver the minimum viable digital product per context, while looking ahead to ensure that a smooth transition to the next context is enabled. This is not meant to stop progress, but rather to ensure that decisions are taken today with an appropriate understanding of potential problems and difficulties. This strategy can be followed by someone undertaking the role of an architect. Even in the Individual/Founder context of the DPBoK Standard, the individual or founder provides the business analysis delivered by an Enterprise Architect, even if it is done in an ad hoc fashion.
Enterprise Architecture as Services Strategy
The second strategy further supports enablement by developing just enough architecture on demand to support the operations tempo of the digital effort. This is accomplished through an Enterprise Architecture services delivery model provided by those undertaking the Enterprise Architect role. This is done in an enabling-consulting fashion. This is especially significant:
-
At the Team of Teams level where the architect can serve to improve cross-team communication and reduce the cognitive load of teams working together
-
In a larger organization that offers consultative services to founders/teams as part of an innovation/incubation strategy
Supporting the Digital Enterprise
This section provides insight on using the TOGAF Standard to support the digital enterprise. It is based on the TOGAF Series Guide: Using the TOGAF Standard in the Digital Enterprise, and aligns with the DPBoK Standard.
The DPBoK Standard
The DPBoK Standard identifies four contexts of organizational evolution of a digital enterprise:
-
Context I: Individual/Founder
-
Context II: Team
-
Context III: Team of Teams
-
Context IV: Enduring Enterprise
These are presented as levels, where the enterprise moves from an earlier context to the next level of success. This is described by the DPBoK Standard as an emergence model. Enterprise Architecture can support this emergence model through the peek-ahead strategy (defined in Strategies for the Digital Enterprise). The Enterprise Architect supports the specific context, and also considers the next level and informs the Digital Practitioners of ways to position themselves to best evolve. At the higher levels of the emergence model, the Enterprise Architect plays an essential primary role in enabling cross-team communication without adding to the cognitive load of the individual teams. In addition, the Enterprise Architects can ensure that the risks are clearly identified and communicated so that decisions can be made with an appropriate understanding of potential problems and difficulties.
Context I: Individual/Founder
The Individual/Founder context addresses the “minimum essential concerns they must address to develop and sustain a basic digital product”. This context represents the bare minimum requirements of delivering digital value.
Key topics for this context are:
-
Conception of digital value
Architecture is often used as a communication medium. Architecture models communicate very well. Also, the Enterprise Architect is a communicator and considered a key enterprise networker.
-
Digital infrastructure and related practices (the essential infrastructure and process choices to quickly deliver value to the market)
The Enterprise Architecture provides the necessary descriptions to communicate the infrastructure available and its appropriate use for both development and delivery. The Enterprise Architect can also help to identify existing infrastructure approaches for individuals/founders that may be embedded in larger organizations, and to communicate vetted technical requirements to the infrastructure organization to ensure preparation for new workloads.
-
Agile development and continuous delivery practices
Enterprise Architecture is often used to support and provide answers to questions about Agile development and continuous delivery. Enterprise Architects, if available to individuals/founders, are often approached to provide guidance in these areas on demand, based on their practical experience.
In this context, it is expected that Enterprise Architecture efforts must support the project to deliver digital products/solutions effectively and efficiently. To support this context, the person acting as the Enterprise Architect has a role to assure that risk is understood and that decisions are made with an understanding of risk.
More details about how the TOGAF Standard supports enterprise agility can be found in the TOGAF Series Guide: Enabling Enterprise Agility and in the TOGAF Series Guide: Applying the TOGAF® ADM using Agile Sprints. See also Agile Methods.
Context II: Team
The team has a single mission and a cohesive identity, but does not need a lot of overhead to get the job done. The Team context covers the basic elements necessary for a collaborative Product team to achieve success while remaining at a manageable human scale.
Key topics of interest within the Team context are:
-
Product management
Product architecture has been a staple for assisting product management decisions.
Enterprise Architecture can provide architecture models that map to a given digital product profile. Additionally, Enterprise Architecture makes interdependencies explicit, assuring an holistic view of the digital product.
-
Work execution management
Enterprise Architecture is often used to depict processes and workflows in very simple to very complex levels of detail.
In the Team context very simple models can be constructed to help communicate workflows and processes; while not the best form of work management, this can be a good way to communicate within a small team.
-
Operations management
Enterprise Architects have been significant contributors to those managing operations.
In the Team context the Enterprise Architecture efforts must support the project to deliver digital products/solutions effectively and efficiently in an environment where there are more people involved – communication is essential. In the Team context the Enterprise Architect has an even greater role to assure that risk is understood and that decisions are made with an understanding of risk. And, given the greater number of people involved in the Team context, the Enterprise Architect has an additional role to ensure the efficacy of communication and collaboration. So, a common shared understanding of modeling and documenting becomes more important to support product management, work execution, and operations understanding.
Context III: Team of Teams
Coordinating across a team of teams is the main concern that people in an Enterprise Architect role need to address using Enterprise Architecture and the TOGAF Standard. Too often, coordination mechanisms (such as overly process-centric operating models) degrade team cohesion and performance. It is important to balance over-complex coordination with the need to ensure the success of a family of digital products.
Key topics for this context are:
-
Organization and cultural factors
Organizational, and especially cultural, issues are often significant drivers in shaping process design, especially in international or multi-jurisdictional enterprises. In certain cases, it might be necessary to respect cultural differences through different means. The means might include altering basic processes, different approaches to stakeholder interaction and management, or altering designs. When an organization is described in terms of value generation, many cultural issues can be managed simply by respecting the constituent parts of the organization. Enterprise Architecture helps to resolve all of these concerns.
-
Coordination and process mechanisms
Enterprise Architecture is used to depict processes and control mechanisms. It is used to identify and eliminate choke points and for continuous process improvement.
-
Investment and portfolio consequences of a multi-team structure
Enterprise Architectures that depict portfolios of products are critical resources in portfolio management. The holistic depiction of interdependencies, value generation, and cost, etc. support portfolio management decision-making.
In the Team of Teams context, Enterprise Architecture and the person in the Enterprise Architect role continues to ensure that risk is understood and communication is effective.
Context IV: Enduring Enterprise
The Enduring Enterprise context is about how to manage an enterprise that has been successful and is now faced with the realities of operating a sustainable business over periods of time longer than the next product cycle.
Key topics areas of interest in this context are:
-
Governance, risk, security, and compliance
Managing risk, including security risk, is often accomplished through governance and compliance.
Compliance criteria can be derived from internal (to the company) sources, and external sources (such as laws and regulation). Good Enterprise Architectures provide compliance criteria that must be used to assess the compliance of business processes, information technology, and human resources.
-
Information management
A critical domain in any Enterprise Architecture is the Information Systems domain, which covers Data and Application Architecture; this domain is here to guide information management issues.
-
Architecture and portfolio management
Enterprise Architectures that depict portfolios of products are critical resources in portfolio management.
The holistic depiction of interdependencies – value generation, cost, etc. – supports portfolio management decision-making. Given the costs of Enterprise Architecture, this activity itself represents something within a portfolio that should be managed in the Enduring Enterprise context.
To support enduring enterprises, the Enterprise Architecture expands its role into overall strategy and governance. It must support what was presented immediately above, as well as support other enterprise issues, such as handling third parties, impact analysis on mergers and acquisitions, etc.
Applying TOGAF Principles per Context
Figure 1 identifies which of the TOGAF principles are most applicable to each of the contexts of the DPBoK Standard.
Applying Enterprise Architecture Services in a Digital Enterprise
Enterprise Architecture services are the delivery mechanism for Enterprise Architecture capabilities. In this section, we summarize the Enterprise Architecture capabilities supported by the TOGAF Standard that could be of use in each of the contexts of the DPBoK Standard.
Figure 2 summarizes Enterprise Architecture Services that should be considered per context to deliver Enterprise Architecture capabilities.
Figure 3 summarizes the Enterprise Architecture services per context, and constitutes the Enterprise Architecture Service Emergence Model.
Factors Impacting Digital Technology Adoption
The TOGAF Series Guide: Digital Technology Adoption: A Guide to Readiness Assessment and Roadmap Development provides a technique, known as Digital Transformation Readiness Assessment (DTRA), that can be used by Enterprise Architects in leading and guiding the process of assessment for a Digital Transformation. It provides a view of how ready the enterprise is for the changes related to digital technology adoption. This provides a quantifiable measurement for the preparedness of organizations to undergo a large transformation and identifies gaps to be addressed. Organizations may not want to start a big transformation initiative without knowing if they have the right resources and conditions to accomplish the evolution effectively and derive the full benefits sustainably.
The factors defined in the DTRA that can be used to assess the readiness of enterprises for digital technologies are categorized as follows:
-
Foundational factors: factors that organizations must have to establish the minimum acceptable readiness to adopt digital technologies
-
Impact factors: factors that enhance or amplify the effectiveness of primary factors by providing supporting conditions
-
Sustaining factors: factors that enable the institutionalization of the adoption of digital technologies for sustained long-term benefits
| Foundational Factors | Impact Factors | Sustaining Factors |
|---|---|---|
Vision |
Business Model Adaptability |
Value Realization |
Sponsorship and Direction |
Skills and Competence |
Policy and Regulations |
IT Capability |
Technology Maturity |
Funding and Resources |
Culture |
Ecosystem |
|
Scope and Scale |
Governance and Compliance |
|
Business Rationale |
||
Implementation Approach |
In Table 3, factors are arranged in each category. Figure 4 highlights the relationships and inter-dependencies between these factors.
Roadmap for Digital Technology Adoption
Step 1: Select the Adoption Approach
The organization must select the adoption approach for the digital technology it desires to take on. The “ABCD framework” comprises the fitment of all types of organization with respect to their digital technology adoption strategy.
Step 2: Perform the DTRA
The DTRA, comprising all the identified factors, is considered a toolkit for inspecting the readiness of the organization against the various critical factors defined in the assessment. A questionnaire is provided in Appendix A of the TOGAF Series Guide: Digital Technology Adoption: A Guide to Readiness Assessment and Roadmap Development.
Step 3: Identify Factors Needing Management Attention
The next step in the process is to analyze the output of the readiness assessment. There might be certain factors that are not as per expectations and the organization is falling short in parameters. It is important to understand the implications of missing factors. For instance, if the result of a readiness assessment shows that an organization is lagging in “Implementation Approach”, it means that the consequence could lead to a likelihood of missed opportunities due to a trial and error-based approach. Organizations may have more than one missing factor and, therefore, the primary consequence of all the factors needs to be understood collectively without any prejudice and bias.
Step 4: Address Shortcomings and Initiate Digital Technology Adoption
This step in the journey is to prepare and address shortcomings (plug the gaps) based on the primary consequences identified in the previous step.
There are three categories of organizations based on the assessment:
Type 1: Enterprises that fulfill foundational factors only
Type 2: Those that fulfill foundational and impact factors
Type 3: Those that fulfill foundational, impact, and sustaining factors
If the organization does not meet the requirements of the foundational factors, it is futile to evaluate for impact and sustaining factors. Hence, it is paramount that enterprises adopt a progressive (step-wise) and Agile approach to mitigate the shortcomings.
If the enterprise is evaluated to be at Type 3; i.e., there is sufficient readiness across all three levels of factors, the readiness of the enterprise is more conducive to start the digital technology adoption than an enterprise evaluated to be at Type 2 or Type 1. Organizations that are Type 1 or Type 2 are recommended to follow the progressive and Agile path; i.e., to address foundational factors, followed by impact factors, followed by sustaining factors.