The Open Group Architecture Framework (TOGAF) is the most popular framework for developing an enterprise architecture (EA). It is an open standard and may be used freely by any organization wishing to develop an enterprise architecture for use within that organization. BiZZdesign believes in an EA approach that is based on open standards and frameworks. We combine and pre-package frameworks and standards like TOGAF and ArchiMate as an accelerated approach to jump-start customers’ EA programs. In this blog we will explain how we use TOGAF as framework, apply it in practice, with the goal of doing business-outcome-driven EA.
Business Strategy as Starting Point
Before you start using a framework like TOGAF, you need to look at your business strategy: the starting point of a business outcome-driven EA practice is understanding your strategy and direction. Your business strategy should of course drive the choices you make in developing your enterprise architecture. Furthermore, this strategy should also have an impact on the methods and techniques you use to create this architecture, and hence on the use and adaption of a framework like TOGAF. For example, a strategy that consists of innovation and early adoption of new technologies requires a more agile and flexible EA framework. On the other hand, a strategy that focuses on consolidation and risk avoidance requires an EA framework with clear governance structures and policies. These kinds of considerations need to be taken into account.
Adapting the Framework
With the business strategy and direction as basis, you can think about how TOGAF can be applied in your organization and which results you want to achieve with it. TOGAF is a very extensive and generic framework, and it is important to specify which elements of TOGAF are useful in the context of your organization and which are not that relevant.
TOGAF Architecture Development Method. Source: The Open Group, TOGAF 9.1
TOGAF itself recognizes this: the first step in TOGAF’s Architecture Development Method (ADM) is the Preliminary Phase. This phase is about defining “where, what, why, who, and how we do architecture” in the enterprise concerned (TOGAF 9.1, Sect. 6.2). In other words: you are going to adapt the TOGAF framework and customize it to the requirements of your own organization.
However, this is not as easy as it may look. TOGAF suggests a number of steps in this Preliminary Phase which make sense, but the approach is still quite generic. Organizations may therefore find themselves struggling in this phase, resulting in lots of debates but little result. To get valuable results from this phase, we apply principles from Lean management to the architecture process: examine all activities and results for the value they add and eliminate any waste, avoid unnecessary sign-offs that cause delays, and continuously improve of your way of working. In our experience it is important to concentrate on three aspects:
Use a limited set of EA deliverables. TOGAF suggests many deliverables that can be produced. In our experience ‘less is more’: only a couple of key deliverables are enough to kick-start an EA initiative and get results.
To select and configure these key deliverables, the most important criterion is their potential business value. Who are going to use them, for which activities and to what expected benefit? Especially in the early phases of an EA initiative it is crucial to show to different stakeholders (including business stakeholders) the added value of EA deliverables.
Learn by doing. It is impossible to define a complete EA framework before you start and execute this in a waterfall approach. It is better to start small, take an iterative approach, learn, and improve your way of working on the go.
Quick Start Program as Support
To support organizations in focusing on the three aspects above when executing the Preliminary Phase of TOGAF, we use often a workshop cycle. This consists of a series of compact workshops in which the key elements of the TOGAF framework are discussed and adapted. Every workshop has a set of concrete results and decisions. The topics that are discussed can be categorized in three groups:
Getting started (Plan): is about setting goals and defining the role of EA, and defining products and deliverables. What do you want to achieve and what do you need to get there?
Implement (Design): Discusses architecture governance and modeling conventions. Who is involved in this effort and how are you going to describe your architecture?
EA at work (Build & Run): The first EA deliverables (for example architecture principles, main requirements, architecture vision) are created as a starting point for running a first ADM cycle.
This cycle can also be augmented with workshops on other topics, such as the (re)use of existing architecture material, the management of architecture requirements, or the relationship with disciplines like project portfolio management. This helps you get started with all the phases of the ADM process and quickly complete a first iteration of the ADM.
This workshop cycle can be completed in a few weeks’ time, jump-starting your EA initiative. All stakeholders are involved, and the high speed required for this accelerated program creates a dynamic atmosphere that helps you to rapidly deliver real business value.
SUBSCRIBE TO BIZZDESIGN'S BLOG
Join 10.000+ others! Get BiZZdesign's latest articles straight to your inbox. Enter your email address below: