In this series of blogs, I will try to summarize TOGAF, The Open Group Architecture Framework. I have done my TOGAF9.1 certification in year 2012. I have been part of two teams which were in transitioning phase from a baseline architecture to the next generation architecture.
TOGAF is an Enterprise Architecture Framework which has evolved from best practices in EA development. The two teams I worked with were not following TOGAF, but several practices they followed overlaps with TOGAF. Based on that experience and the knowledge I have gathered via TOGAF certification I will be writing this blog. Your comments will help me refine it further. I will mainly refer TOGAF documentation while writing this blog.
You can adopt TOGAF as your enterprise architecture framework or you may wish to adopt parts of the TOGAF framework and use them with your existing EA framework. TOGAF works well in both these scenarios.
Before diving into TOGAF, let’s see what an Enterprise Architecture work involves. An Enterprise Architecture encompasses the entire enterprise which starts from the business. When you have Enterprise in your perspective, the entire thought on architecture changes. You do not begin from thinking about 2-3-n tiers, High Availability, Messaging, etc… but your perspective now is what are the business processes and how IT can help evolve or support these business processes. You begin with understanding the Business Architecture, what Architecture Principles will your applications be based on, what will be your Architecture Roadmap to support these Business processes, who your stakeholders will be and how will they be managed, what is the current architecture (if any) and are there any Gaps to support the business processes, how to store reusable Architecture Building Blocks, how to Migrate from existing architecture to the target state architecture, what all applications will be required and how will they be governed, how will a change in architecture be implemented… and the list goes on.
Implementing Enterprise Architecture is not a one person job and neither is it a single project within Organization. It’s a practice which must be setup within the organization and recognized and funded from the CXO level. Enterprise Architecture Practice is not a standalone ivory tower effort. It works in parallel with the PMO and the Operations.
So, will you then not be thinking of 2-3-n tiers, High Availability, Messaging, etc. That depends on what sort of Architect you are. If you are an Enterprise architect, you will think of these when you define architecture principles. If you are a Data Architect, you will define Data Aspects. As an application / solution architect you will identify tiers, messaging in accordance with Architecture Principles laid out and if you are a Technical architect, you will define high availability platforms. Roles and responsibilities of architects will vary in different organization.
I hope this gives a glimpse of what is involved in an Enterprise Level Architecture. TOGAF provides an architecture framework which defines a process following which you will be able to develop an Enterprise Architecture.
TOGAF is developed by The Open Group and consists of seven parts:
1. Introduction – TOGAF Introduction and common Terminologies and definitions
2. ADM – Architecture Development Method – An iterative methodology of how to develop an Enterprise Architecture. It has 9 Phases and each phase has Objectives, Steps, Inputs and Outputs. Eg. In Preliminary Phase, one of the objective is “Identify and scope the elements of the enterprise organizations affected by the Architecture Capability” and one of the input is “Board strategies, business plans, business strategy, IT Strategy, business principles, business goals, and business drivers” and an output is “Request for Architecture Work”.
3. ADM Guidelines and Techniques – This describes several guidelines and techniques which can be applied when performing ADM. Eg. How to do a Gap Analysis?
4. Architecture Content Framework – When developing Architecture via ADM, several outputs will be produced (Eg. Project Plans, Architecture Definition Document…). The Content framework provides a way to structure and present these outputs. All outputs of ADM is categorized as a Deliverable, Artifact or a reusable Building Block and the content framework provides definition of each of these. The content framework also provides a meta-model for to structure outputs from all phases. This provides consistency among different architectures.
5. Enterprise Continuum and Tools – Within an organization, there will be a continuum of architectures from foundational to specific architectures. This part of TOGAF classifies the entire spectrum and also provides guidance on how to partition the architecture and how to maintain Architecture Repository.
6. TOGAF Reference Models – TOGAF provides two reference architecture models. Technical Reference Model (TRM) and Integrated Information Infrastructure Reference Model (III-RM). TRM provides a foundation which includes services and functions required to build more specific architectures. It essentially is a taxonomy of components and structure which is generic to all architectures. III-RM is also a taxonomy and is applicable to organization which have silos and would need information to flow out and aggregated.
7. Architecture Capability Framework – Provides guidance on how to setup Architecture capability in the organization in a Phased manner.
This blog provides an overview of what TOGAF has to offer. This introduces you to several terms without going into detail. I hope the blog still offers enough information to inspire you to give a look to TOGAF.In the next blog, we will look into the different Architectures supported by TOGAF i.e. the Business, Data, Information and Technical Architectures.