TOGAF10 Enterprise Architecture Combined (Foundation & Practitioner)

TOGAF10 Enterprise Architecture Combined (Foundation & Practitioner)

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.