InfoSec Musings: Should We Embrace an Enterprise Architecture Framework?

With Great thanks to Roger Sessions - ObjectWatch, Inc.

Through the mid 1980s and 90s, businesses realized that IT systems were becoming more and more complex, and more and more expensive. Vendors used differing standards, integration was difficult at best, and impossible most of the time.

To add gas to the fire, by the time these IT systems were built, they no longer aligned with Business Requirements.

Out of this requirement for aligning Business Needs to IT Architecture and implementation, while keeping costs in line, came the field of Enterprise Architecture.

As Defined succinctly by S R Balasubramanian in Enterprise architecture demystified:

"Issues that we are faced with

Management and users often express their dissatisfaction with the IT systems and we feel the need of addressing their concern. The common refrain that we hear is as follows:

i) IT systems have become unmanageably complex and increasingly costly to maintain.

ii) IT systems are hindering the organization’s ability to respond to current, and future, market conditions in a timely and cost-effective manner.

iii) Mission-critical information (provided by IT) is consistently out-of-date and/ or just plain wrong.

iv) A culture of distrust is developing between the business and technology sides of the organization."

As in most diciplines, they needed standards and guidelines to work to, and one of the first Enterprise Architecture Frameworks developed was the Zachman Framework.

The Zachman Framework in it's original form was quite straight forward, and assigned roles, criteria, and decisions to the questions:

"Why, How, What, Who, Where, When"

for each phase of an architecture, through "Contextual, Conceptual, Logical, Physical, and Detailed".

This is commonly referred to as a "taxonomy" rather than a Framework but has laid the ground for all methodologies to come.

V3.0 of the Zachman Framework was introduced in 2011.

Over the past 30 some years, a number of Archtectural Frameworks have come and gone. Many were split and morphed into newer frameworks. Federal Governments have developed their own, and large consulting organizations have done likewise. Today, there are three frameworks that stand out among Enterprise adopters.

Department of Defense Architecture Framework (DODAF)

"The Department of Defense Architecture Framework (DoDAF), Version 2.0 is the overarching, comprehensive framework and conceptual model enabling the development of architectures to facilitate the ability of Department of Defense (DoD) managers at all levels to make key decisions more effectively through organized information sharing across the Department, Joint Capability Areas (JCAs), Mission, Component, and Program boundaries."

The Gartner Enterprise Architecture Framework and Practice

Gartner's Enterprise Architecture Framework (Formerly Meta) is more appropriately described as a "Practice" that encompases the Zachman Taxonomy with the TOGAF process and provides it as a service to large Enterprises.

The Open Group Architecture Framework (TOGAF)

Based closely on a previous framework, The US Department of Defence's TAFIM, TOGAF is a proven enterprise architecture methodology and framework used by the world's leading organizations to improve business efficiency.

It is often referred to as "a process more than a framework", however has garnered wide adoption.

According to many who have assessed and evaluated these various "Frameworks" there is no single clear "winner". They are complimentary pieces of the overall puzzle.

So, in conclusion...

The concept of adopting An Enterprise Architecture Framework is quite logical. As in adopting ANY Standards based process (Incident Management, Security Management, Application Development, Financial and Resource Management, etc...) one must understand the accepted frameworks, and analyse against your corporate culture and processes to 1) Chose a framework that best integrates with your existing environment, and 2) Define a roadmap to adoption.

As described above, although there are many Enterprise Architectural Frameworks established, none of them completely provides for an end to end process.

Enterprise Architecture as a practice, should embrace the Taxonomy of Zachman, and adopt the Processes described in either TOGAF or DODAF depending on your particular Line of Business.

Definition of terms as per IEEE 1471-2000 Recommended Practice for Architectural Description of Software-Intensive Systems

architect—One whose responsibility is the design of an architecture and the creation of an architectural description
architectural artifact—A specific document, report, analysis, model, or other tangible that contributes to an architectural description
architectural description—A collection of products (artifacts) to document an architecture
architectural framework—A skeletal structure that defines suggested architectural artifacts, describes how those artifacts are related to each other, and provides generic definitions for what those artifacts might look like
architectural methodology—A generic term that can describe any structured approach to solving some or all of the problems related to architecture
architectural process—A defined series of actions directed to the goal of producing either an architecture or an architectural description
architectural taxonomy—A methodology for organizing and categorizing architectural artifacts
architecture—The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution
enterprise architecture—An architecture in which the system in question is the whole enterprise, especially the business processes, technologies, and information systems of the enterprise