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.
