Once upon a time there was a brave consultant who traveled to many companies
across many distant lands. Even though the companies she visited were diverse
in their pursuits, she encountered many a common theme. She would ask the same
question to different business units within the same company and get terrifyingly
different answers. She noted that meeting new strategic initiatives was a guaranteed
scary proposition and that IT was viewed as that multi-headed monster better
known as a bottleneck. Amazingly, information was almost never available at
the right place to the right people at the right time, and if it was it really
could not be trusted! To add insult to injury, no matter how hard the employees
seemed to work they always seemed to be one step behind from where they needed
Then one day this brave consultant came upon a company where IT was a strategic
partner with the business supporting such amazing capabilities as portability,
interoperability, and extensibility. IT value was completely justified; there
was a sense of reduced risk and an unprecedented amount of flexibility in make,
buy, and sourcing decisions. Employees in this company worked less, were more
relaxed, and yet they managed to stay ahead of their peers in their market.
How could this be? And it was that fateful day that she discovered the wonders
of enterprise architecture!
Hmm...is this déjà vu?
Alas, if only the above narration were just a story! Unfortunately, this "story"
is my experience and more than likely the experience of each and every one of
you reading this article. Yes, it is true that a deliberate enterprise architecture
can really transform the way a company does business. It can provide a strategic
foundation that realizes the company's operating model, and can incorporate
the necessary governance processes to ensure the continued alignment of the
enterprise architecture with the operating model as it evolves.
Such claims of positive transformation are supported by numerous surveys conducted
by reputed institutions such as Gartner, Infosys, Harvard Business School, etc.,
which show that companies with a well-articulated, deliberate enterprise architecture
consistently outperform their peers who lack such an enterprise architecture
by achieving higher profitability, better productivity, and lowered IT costs.
All this sounds great, but unfortunately, have you ever heard of a free lunch?
Veteran architects will undoubtedly attest to the fact that enterprise architecture
is a complex undertaking that takes hard work and commitment from all levels
of an organization, especially from the higher levels. The good news is that
there is a broad base of knowledge to leverage in the field of enterprise architecture,
most of which is encapsulated in well-known enterprise architecture frameworks
such as TOGAF, Zachman, and others.
So, with this context in mind, let us now embark on the journey that our brave
consultant might have taken as she discovered the promise of enterprise architecture.
First things first - it's really hard to talk about enterprise architecture
without leveling what we mean by the term "architecture". Honestly,
sometimes I feel that we architects spend more time defining and re-defining
concepts than professionals in any other field. Just look at the many diverse
and interesting definitions of architecture you can find at the following web
page maintained by the Software Engineering Institute: http://www.sei.cmu.edu/architecture/definitions.html.
For our discussion, let's take a look at how architecture is defined by four
authoritative sources: the Software Engineering Institute (SEI), IEEE, the Rational
Unified Process (Grady Booch et. al.), and The Open Group (TOGAF).
The Software Engineering Institute (SEI): The software architecture
of a program or computing system is the structure or structures of the system,
which comprise software elements, the externally visible properties of those
elements, and the relationships among them.
ANSI/IEEE Std 1471-2000: The fundamental organization of a system, embodied
in its components, their relationships to each other and the environment, and
the principles governing its design and evolution.
Grady Booch et. al. in the Rational Unified Process (RUP): An architecture
is the set of significant decisions about the organization of a software system,
the selection of the structural elements and their interfaces by which the system
is composed, together with their behavior as specified in the collaborations
among those elements, the composition of these structural and behavioral elements
into progressively larger subsystems, and the architectural style that guides
this organization -- these elements and their interfaces, their collaborations,
and their composition.
The Open Group (TOGAF): The structure of components, their inter-relationships,
and the principles and guidelines governing their design and evolution over
time. A detailed plan of the system at component level that can guide its implementation.
Each of these definitions attributes architecture with three common themes:
It is the structure of a system
It includes the relationship between these structures
It includes the principles and guidelines that govern the design and evolution
of the system
Putting enterprise architecture in context requires one to understand two distinct
concepts: architecture, which we already looked at, and an enterprise. Simply
put, an enterprise is any collection of organizations that has a common set
of goals and/or a single bottom line. Based on this definition, an enterprise
could be a government agency, a whole corporation, a division of a corporation,
a single department, or a chain of geographically distant organizations linked
together by common ownership. Nowadays people often refer to the concept of
an extended enterprise, which not only includes the organization itself but
also includes the organization's partners, suppliers, and customers.
Moving on to enterprise architecture
The MIT Center for Information Systems Research defines enterprise architecture
as "the organizing logic for business processes and IT infrastructure reflecting
the integration and standardization requirements of the firm's operating model."
As you might notice, this eloquent definition brings together the key concepts
from both the "architecture" and "enterprise" descriptions.
Stated differently, enterprise architecture is the blueprint that translates
an enterprise's strategic goals and operating model into an executable architecture
of processes and infrastructure. If this reads like a mouthful, just imagine
the complexity of actually defining and then implementing the enterprise architecture.
As luck would have it that is exactly where enterprise architecture frameworks
such as TOGAF help save the day. Enterprise architecture frameworks such as
TOGAF encapsulate a broad body of knowledge in the form of standard methods,
defined processes, common vocabulary, guidelines, best practices, case studies,
tools, and technologies that enable the architect in designing and implementing
the right enterprise architecture.
So without further ado, let's examine TOGAF, one of the leading enterprise
architecture frameworks available today.
The Open Group Architecture Framework, TOGAF, is developed and maintained by
The Open Group Architecture Forum and its 350 members. TOGAF may be reproduced
freely by any enterprise wishing to use it to develop a broad range of enterprise
architectures. The first version of TOGAF, developed in 1995, was based on the
U.S. Department of Defense Technical Architecture Framework for Information
Management (TAFIM). Since then TOGAF has continuously evolved such that it has
become the de facto global standard for assisting in the acceptance, production,
use, and maintenance of architectures.
As shown in Figure 1, TOGAF identifies four types of architecture as subsets
of the overall enterprise architecture discipline:
A business (or business process) architecture that defines the business
strategy, governance, organization, and key business processes
A data architecture that describes the structure of an organization's logical
and physical data assets and data management resources. Data architecture
does not include the design of the actual physical data stores (or database)
An applications architecture that provides the blueprint for the individual
application systems to be deployed, their interactions, and their relationships
to the core business processes of the organization. The application architecture
in TOGAF is not concerned with the actual software applications but rather
limits the term application to a logical grouping of functionality
A technology architecture that describes the logical software and hardware
capabilities that are required to support the deployment of business, data,
and application services. This includes IT infrastructure, middleware, networks,
communications, processing, standards, etc.
Figure 1: The TOGAF Enterprise Architecture Puzzle
The TOGAF 8.1.1 enterprise architecture framework consists of
three core components as shown in Figure 2.
Figure 2: TOGAF 8.1.1 Core Components
Let's look at each of the three components starting with the
The Architecture Development Method (ADM)
The key to TOGAF is the TOGAF Architecture Development Method
(ADM) that explains how to create an organization-specific enterprise architecture
that addresses business requirements. The ADM provides:
A reliable, proven way of developing the architecture
Architecture views which enable the architect to ensure
that a complex set of requirements are adequately addressed
Linkages to practical case studies
Guidelines on tools for architecture development
The ADM is structured as a series of nine phases plus a requirements
management phase that interacts with each of the nine phases throughout the
ADM lifecycle. The ADM is shown in Figure 3.
Although, based on Figure 3, the ADM might appear sequential
or "waterfall" in nature, in reality the ADM is iterative, over
the whole process, between phases, and even within phases.
The Enterprise Continuum
The Enterprise Continuum, which is another core component of
TOGAF, is a "virtual repository" of all architecture assets -- models,
patterns, architecture descriptions, and other artifacts -- that exist not
only within the enterprise itself but also in the IT industry at large. Artifacts
in the Enterprise Continuum provide a valuable foundation to build upon and
leverage as the enterprise charges forward in its enterprise architecture
endeavor. The TOGAF ADM works synergistically with the Enterprise Continuum
by providing constant reminders as to which assets from the Enterprise Continuum
the architect should use as they progress through the ADM.
The Enterprise Continuum comprises of two "sub continuums,"
the Architecture Continuum and the Solutions Continuum. The Architecture Continuum
offers a consistent way to define and understand the generic rules, representations,
and relationships in an information system. It:
Represents a structuring of re-usable architecture assets
Shows the relationships among foundational architectures
(such as the TOGAF Reference Model, TRM), common systems architectures (such
as the III-RM), industry architectures, and enterprise architectures
Serves as a useful tool to discover commonality and eliminate
The Solutions Continuum provides a consistent way to describe
and understand the implementation of the Architecture Continuum. It:
Defines what is available in the organizational environment
as re-usable Solutions Building Blocks (SBB)
Addresses the commonalities and differences among the products,
systems, and services of implemented systems
As shown in Figure 4, the Architecture Continuum guides the
Solutions Continuum in the types of products and solutions that are needed
by the enterprise. Conversely, the Solutions Continuum supports the Architecture
Continuum with specific capabilities needed to translate the architecture
vision into an executable reality.
Figure 4: Synergistic relationship between the Architecture
and Solutions Continuum
The Resource Base
The final core component of TOGAF, the Resource Base, is a set
of resources -- guidelines, templates, background information, etc. -- to
help the architect in the use of the ADM. Excellent information is included
on a broad spectrum on relevant topics such as:
Architecture Boards, Architecture Compliance, and Architecture
Architecture Governance and Architecture Maturity Models
Architecture Patterns and Principles
Architecture Skills Framework
Developing Architecture Views
Case Studies and Business Scenarios
Other Architectures and Frameworks
Tools for Architecture Development
Detailed information on using the ADM with the Zachman Framework
TOGAF -- Integration with Other Frameworks
Although TOGAF is quite comprehensive in what it offers, it is not designed
to be an island by itself. Rather, a well thought out integration of TOGAF
with another framework can lead to a very potent combination. Let's take a
quick look at two such examples where TOGAF is integrated with another well-known
TOGAF and the Zachman Framework
The Zachman Framework was created by John Zachman in 1987 with the goal of
standardizing the structuring and organization of the massive amounts of data
collected in an enterprise architecture effort. It is used extensively in
both the commercial and federal civilian worlds and has rapidly become the
de facto standard for classifying the artifacts developed in enterprise architecture.
As shown in Figure 5, it is organized as a six-by-six matrix structure with
the columns representing various aspects of the enterprise that can be described
or modeled and the rows representing the various viewpoints.
As one peruses the Zachman Framework, it becomes quite obvious
that the scope of the four architecture domains of TOGAF align very well with
the first four rows of the Zachman Framework. It also becomes evident that the
Zachman Framework could serve as an excellent gap analysis tool in a TOGAF initiative
for analyzing the current state (baseline) of an enterprise, identifying risk
areas, and prioritizing effort.
Conversely, the Zachman Framework says nothing about the processes
for developing viewpoints or conformant views, or the order in which they should
be developed as one starts filling out the matrix structure. If you've been
following the article so far, you should be thinking to yourself at this point
that the TOGAF ADM can very easily fulfill this void. If you would like to learn
more about the integration between these two exciting frameworks, please refer
to chapter 39 in the TOGAF documentation in the References section.
TOGAF and RUP
The Rational Unified Process (RUP) is a mainstream software development
process framework well known within the software engineering community. A mapping
between TOGAF and RUP has several benefits:
TOGAF, and for that matter enterprise architecture in general, is still
not as mainstream of a discipline like software development. Therefore, it
might be much easier to convince an organization of a TOGAF-based enterprise
architecture effort when it is mapped to a better-known process such as RUP.
Although well-documented, TOGAF, by design, lacks specificity in several
areas, such as tools and artifacts. As an example, TOGAF does not have a comprehensive
artifact library available. Mapping TOGAF to RUP can help fill in such blanks.
Many of the architects involved in (and oftentimes leading) an enterprise
architecture effort have a software engineering background. Of these, most
are familiar with RUP (or some variation of it). In these cases, mapping TOGAF
to RUP can help alleviate some of the initial apprehension of embarking on
the enterprise architecture journey.
The integration between TOGAF and RUP can be either "black
box" or "white box." Discussing the specifics of either method
is well beyond the scope of this article.
So, it was a fateful day indeed when our brave consultant discovered
enterprise architecture in a company where business and IT walked side-by side,
hand-in-hand creating an environment in which day-to-day operations were performed
more efficiently, employees were under less stress, and market leadership was
part of "just how things were done." She also discovered that although
establishing the "right" enterprise architecture could be a daunting
task, an enterprise architecture framework such as TOGAF would greatly help
in her new found mission of enlightening others as to the limitless possibilities
with the "right" enterprise architecture. Thus, it was from that day
on that she spent the remainder of her consulting years going from company to
company helping each company realize the promise of enterprise architecture.
The world was finally at peace and everyone lived happily ever after.
About the Author
Tarak Modi, currently Vice President and Chief Technology Officer at CALIBRE systems - an employee owned management and technology services company, is an industry thought leader in IT transformation and modernization technology such as enterprise architecture, SOA and cloud computing. In this podcast, we pick up on our cloud computing discussion from our very first pocast with Tarak to see how the Federal government has continued along its journey towards the adoption of Cloud Computing.