1 Introduction
1.1 Overview
This Guide provides guidance on using the TOGAF framework to develop, maintain, and use an Enterprise Architecture (EA). This Guide is a companion to the TOGAF framework and is intended to bring the concepts and generic constructs in the TOGAF framework to life. This Guide puts forward an approach to develop, maintain, and use an EA that aligns to a set of requirements and expectations of the stakeholders and enables predictable value creation.
It is intended to take the TOGAF concepts and show how each Practitioner can use the same concept to (a) deliver useful EA for their Enterprise and (b) deliver improvements to EA Capability. This point is important: use the same concept. Not the same technique, not the same template, not the same process. The same concept. For example, evidence from prevalent practice shows that there is not a single EA team that didn’t use a repository, whether the repository is a file folder or a fully-fledged installation of modeling and analytic software. If you are struggling with this point, stop and think about any preconceptions you are carrying into the conversation. For example, while reading, if you have a reaction similar to “but a real repository includes …”, ask yourself if this is universally true. The concept of a repository is universal; the implementation varies.
The essential scaffolding of the TOGAF framework is the concepts. Everything else in the TOGAF framework is either an example or a starter set to get you moving. If you do not like the example, then you can take advantage of the modular structure of the TOGAF framework and substitute it. Leading Practitioners and users often take this approach. This Guide is about advising the Practitioner in making the universal structure of the TOGAF framework work.
This Guide is written for the Practitioner, the person who is tasked to develop, maintain, and use an EA. 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 Guide is structured to provide the context, content, and rationale behind choices and steps that an EA Practitioner can consult at any point. When effectively used, a thoughtfully developed EA optimizes Boundaryless Information Flow™ within and between Enterprises based on open standards and global interoperability.
This Guide is explicitly about developing, maintaining, and, most importantly, using an EA. The range of potential Enterprises and purposes require a guide of this length to define the direction.[1] Following the approach suggested in the World-Class Enterprise Architecture White Paper (see Referenced Documents), the TOGAF Standard is routinely applied to develop architectures supporting strategy development, portfolio management, project planning and execution, and solution development. Collective experiences reflect that there is no one right EA deliverable, model, view, work product, or technique. Rather, the correct approach is specific to the purpose of the architecture development initiative. Anyone who suggests there is a single correct approach, model, view, work product, or technique is not providing the right advice for you to succeed. This Guide will help you, the Practitioner, to identify the approach that is appropriate to any particular purpose.
Developing, maintaining, and using an EA requires deep interaction with several specialized functions such as strategy development, budgeting, benefits realization, portfolio management, program & project management, and operational units. This Guide will:
- Introduce key topics of concern
- Describe the TOGAF Standard concepts related to the topic
- Show how it is related to developing, maintaining, and using an EA
- Discuss what the Practitioner needs to know
- Describe what the Practitioner should do with this knowledge
Even though this Guide has a logical structure, it is not simple task list. The depth and detail of the steps needed to be taken by the Practitioner are specific to the purpose and are iterative. The only variable is time spent for every step. As with all change work, listing what you need to know is not the same as defining the level of detail in the documentation.
Key decisions are made in an Enterprise following a business cycle. An architecture should inform and enable decision-making. Just align the delivery of architecture to the Enterprise’s business cycle and the purpose of the architecture development initiative. The value is delivered when the architecture is used. It is plain and simple.
This Guide is divided into six parts, as follows:
Part 1: Introduction
This part contains this introductory part and a set of definitions.
Part 2: Guidance on Enterprise Architecture
This part addresses:
- What an Enterprise Architecture is and what it is used for
- Coordinating EA development across the EA Landscape
- Coordinating EA development with the business cycle
Part 3: Guidance on Developing an Enterprise Architecture
This part addresses:
- Using the ADM
- Developing an Enterprise Architecture to Support Strategy
- Developing an Enterprise Architecture to Support Portfolio
- Developing an Enterprise Architecture to Support Project
- Developing an Enterprise Architecture to Support Solution Delivery
- Special Cases
Part 4: Guidance on Using an Enterprise Architecture
This part addresses:
- What to do when you are hip-deep in solution delivery
- Architecture in action (agile Enterprise, response to incident, etc.)
Part 5: Guidance on Maintaining an Enterprise Architecture
This part addresses:
- Managing multiple simultaneous roadmaps
- What to do when you are hip-deep in solution delivery
Part 6: Appendices
This part presents:
- A list of useful tables related to frameworks, reference models, etc.
1.2 How to Use this Guide with the TOGAF Framework
The TOGAF framework provides essential universal scaffolding useful in a range of organizations, industries, and architectural styles. This Guide is designed to fill in what is not explicitly addressed by the TOGAF framework and provides an approach to interpret the standard. This does not suggest that the TOGAF framework is flawed. The TOGAF framework is designed to require interpretation or customization. It has to provide universal scaffolding. What is common and universal between all of the different examples provided in the definition of Enterprise? Essential scaffolding expressed as concepts.
One way to look at the TOGAF framework is that it is written for the expert theoretician – the person who thinks about the structure and practice of EA. The TOGAF® Leader’s Guide to Establishing and Evolving an EA Capability (see Referenced Documents) is for the person tasked with establishing or evolving an EA Capability.
This Guide is written directly for the person who does the work: develops, maintains, and uses an EA. The person who is not worried about the theory, and who is not worried about how to structure or maintain an EA Capability. The person who develops, uses, and maintains a good EA.
While this Guide assumes no detailed knowledge of the TOGAF framework, it explores the core concepts of the TOGAF Standard. It places these concepts together in the context of using them to develop, maintain, and use an EA. This includes guidance on iteration, an EA Repository, executing the ADM for the purpose of supporting Strategy, Portfolio, Project, and Solution Delivery, and performing effective governance of the development and use of the EA practice.
This Guide follows the approach of exploring the conceptual structures in the context of making use of them. This Guide assumes that you have established an EA Capability and have customized the TOGAF framework for your Enterprise.[2]
This Guide is part of the TOGAF Library.[3] Other documents in the TOGAF Library include the TOGAF® Leader’s Guide to Establishing and Evolving an EA Capability. The TOGAF Library provides a complete interpretation of the TOGAF Standard to establish an EA Capability, develop the EA Capability team, and deliver a useful architecture to guide change and govern the Enterprise change initiatives.
1.3 Referenced Techniques
References to key literature and their techniques within this Guide are intended only to be representative. This Guide does not suggest that the referenced tools, techniques, and literature are definitive. Other tools, techniques, and literature can readily be substituted.
TOGAF® is a registered trademark of The Open Group