EA history from a US government perspective

Over many years, US federal government and US DoD have separately developed EA methods and deliverables along parallel paths, driven by somewhat different needs.

US federal government efforts were initially driven by the desire to reduce costs by aligning IT work with measurable business process improvement.
DoD efforts were initially driven by the desire for interoperability (and so was a natural platform for the Open Group to develop TOGAF).

This table presents a rough chronology; the columns are not perfectly aligned.

Consultants	DoD	Open Group	all dates are approximate
Zachman Framework			1987
Stephen Spewak’s EAP	IDEF		1992
Federal Government	TAFIM		1994
Clinger Cohen Act	C4ISR	TOGAF	1996
FEAF & Common Classification Schema	DODAF 1 & CCCDM, CADM	TOGAF 7	2002
FEA: five reference models		TOGAF 8	2006
	DODAF 2	TOGAF 9	2009

The table mentions the Zachman Framework and has a column for TOGAF, but these are mentioned only briefly below, because they are explored in detail in other papers at http://avancier.co.uk.

Stephen Spewak’s “EA Planning”

EA Planning is “the process of defining architectures for the use of information in support of the business and the plan for implementing those architectures”.

· The business mission is the primary driver.

· Then the data required to satisfy the mission,

· Then the applications built to store and provide that data

· Finally the technology to implement the applications.

EAP is a data-centric approach to architecture planning.

An aim is to improve data quality, access to data, adaptability to changing requirements, data interoperability and sharing, and cost containment.

EAP is beneficial to understanding the further definition of the Federal Enterprise Architecture (FEA)." After Wikipedia entry on Stephen Spewak.

DoD: Systems Engineering, TAFIM and C4ISR

In the 1970s, systems engineering gurus in US military services (especially the Navy) developed “technical manuals” to standardize ways to develop applications, systems and systems-of-systems, both shipboard and ashore.

Separately, in the 1980s, the Air Force, as part of a project involving CASE tools created IDEF, later standardized as Federal Information Processing Standards in 1994.

The Office of the Assistant Secretary of Defense (OASD) for Command, Control, Communication & Intelligence (C3I), created The Architecture Framework for Information Management (TAFIM).

This was the first of several documents to begin describing and prescribing interoperability standards in development and fielding of command and control systems.

It became the basis for TOGAF.

In the early 1990s, a staff element of C3I, called the Command Information Superiority Architectures (CISA) was tasked to reduce chaos in the development of next generation Command and Control information systems.

CISA aimed to provide a resource to develop information architectures supporting command & control.

So CISA began development of a next-generation TAFIM, which was called the Command, Control, Communications, Computing, Intelligence, Security & Reconnaisance (C4ISR) Framework.

The C4ISR Framework drew from the earlier technical manuals and included the IDEF notation.

Open standards and the Open Group

The early 1990s saw an explosion of diverse technologies, and duplications between systems offering the same services.

Systems integration was necessary, but increasingly difficult.

And there were concerns about vendor/technology lock-in.

All these concerns led towards the definition and adoption of open standards.

An open standard has two basic characteristics:

· it is published for all to read in the public domain

· it is maintained by a vendor-neutral organization (or consortium of organizations) rather than a specific product vendor.

For many years there were competing versions of the Unix operating system, promoted by different interest groups.

The Open Group was created to put an end to the Unix wars – to certify versions of the Unix operating system against a single open standard.

The Open Group adopted the POSIX philosophy of defining a system by the external services it offers rather than the internal components it is made of.

The Open Group has since expanded to certify many other products.

It derives its income comes from certification to standards of a wide range of products and services, and from membership fees.

So it encourages its member groups to maintain standards and develop new standards.

The mission statement of the Open Group is:

· “The Open Group is a vendor-neutral and technology-neutral consortium,

· whose vision of Boundaryless Information Flow™ [wider access to better integrated information]

· will enable access to integrated information, within and among enterprises,

· based on open standards and global interoperability.”

In 1994, the Open Group selected TAFIM from the US DoD as a basis for development of an open standard.

TOGAF was first published in 1996; the motivations were those of the US DoD, The Open Group, and IT architecture in general:

· Business-IT alignment

· Rationalisation and integration of overlapping IS/IT systems.

· Vendor-neutral specifications for procurement of products and services.

See the companion paper for how TOGAF grew from an IT architecture framework into an EA framework.

Federal government: the Clinger Cohen Act

In the USA, the Clinger Cohen Act (1996) is often quoted as the stimulus for work on EA, yet the act does not mention EA at all.

In the early 1990s, business people grew concerned that the IT department was a financial black hole.

They wanted to see a better Return on Investment (RoI) from IT, or at least, a demonstrable return.

Some looked to apply the principles of the ‘manufacturing revolution’ to software engineering.

They latched on to the idea of measurable business process improvement as addressing the concern.

At the same time, the US Congress complained about the vast expenditures on IT in the federal government.

This pressure (along with the general ideas above) underpinned a series of laws intended to improve business-IT alignment in US federal government.

Government Performance Results act (GPRA) of 1993, P.L. 103-162.
This requires the development of performance measures for IT systems.
Federal Acquisition Streamlining act (FASA) of 1994, P.L. 103-355.
This requires the development and evaluation of cost, schedule and performance goals of IT systems.
Information Technology Management Reform act (ITMRA) of 1996, Division E, P.L. 104-106.
This emphasises the need to align IT with business mission and improvement.

These laws caused increasingly greater levels of supervision and oversight of IT expenditure and use.

The last is popularly known as the Clinger Cohen Act (the act).

This was passed after hearings to determine two things:

How to make government more efficient.
How to more effectively control IT spending.

The act was passed during the time that the so-called 'peace dividend' was reducing budgets, and the Clinton administration was looking for ways to reengineer everything.

Among others, John Zachman testified on the need to better manage IT spending through organization of the IT planning process, on performance management and balanced scorecard initiatives.

The main idea of the act was simple: IT costs should be tied to improvements in business operations, and legacy systems turned off in conjunction with development of new systems.

Thus costs could be better contained.

The act defined the role IT directors and CIOs should play.

The table below distils the main messages of the act.

Section of Clinger Cohen Act	Distillation of the message
SEC. 5112. CAPITAL PLANNING AND INVESTMENT CONTROL	Improve business processes through using data better and reducing data entry effort; make a business case for work to be done; study best practices for information resources management and train people in them
(2) DIRECTION FOR EXECUTIVE AGENCY ACTION	Map IT work to the business mission, and keep data secure
(3) GUIDANCE FOR MULTIAGENCY INVESTMENTS	Share data processing projects and resources to accomplish shared missions
(4) PERIODIC REVIEWS	Map IT work to the business mission and business process improvement
(a) DESIGN OF PROCESS	Identify and manage IT risks
(b) The CIO … shall be responsible for—	Map IT work to the business mission and business process improvement
(c) DUTIES AND QUALIFICATIONS	Maintain the skills and capabilities to manage information resources
SEC. 35. MODULAR CONTRACTING FOR IT.	Plan for incremental development, and assure interoperability through following standards
(c) PROCESS REQUIREMENTS	IT work must start with requirements and end with measurable improvement
SEC. 5126. ACCOUNTABILITY.	Ensure money is spent wisely, and we can justify money spent.
SEC. 5402. IDENTIFICATION OF EXCESS AND SURPLUS COMPUTER EQUIPMENT.	Maintain a comprehensive IT architecture repository

The act places a big emphasis on connecting IT to measurable business improvement.

It forced selected agencies to have a CIO, and an "IT Architecture".

The CIO would be held accountable for IT in an organization.

Control and governance focused on IT expenditures as "investments" in Capital Planning Investment Management (CPIC).

People often refer to the act as promoting EA.

Actually, the act does not mention of EA, nor does it direct CIOs to approach architecture description in the manner proposed by TOGAF or Zachman.

The reference to IT Architecture is readable as a register of computer equipment.

It suggests a configuration management database (as in ITIL) or perhaps application portfolio management.

After the act, the US Government passed rules and instructions which required CIOs document an EA to satisfy the ACT requirements, and required government agencies to develop architecture frameworks to define further how they create those architectures.

That left little room to determine next steps, except to adopt a framework (such as Zachman) or create one.

The US DoD already had the C4ISR Architecture Framework, and adapted it for that purpose.

Interestingly, Clinger-Cohen did not require CIOs be assigned to the IT department.

They were required to be direct reports to the agency head.

However, many government CIOs were also the IT chiefs.

That became common as the numbers and costs of information systems were increasing dramatically, and Clinger-Cohen expected those costs to be contained.

Of course the act applied only to US federal government.

But EU directives have followed a similar line.

And many private sector organisations have adopted a similar approach.

Federal government: FEAF and FEA

After the Clinger Cohen act, the federal government executive created the CIO Council under the Director of OMB (Office of Management and Budget).

The CIO council wanted a framework for execution of EA to support investment/financial decisions.

They created FEAF, drawing on both the Zachman Framework and Stephen Spewak’s Enterprise Architecture Planning process.

FEAF did not require visual artifacts.

It captured the simple inventories of a few kinds of things.

It included various notions of how to characterize things, and which relationships are useful.

The OMB created FEAPMO (Federal EA Program Management Office).

FEAPMO wanted to define common Government processes - to enable sharing of reengineering experiences among federal agencies, and to facilitate reuse.

So, in consultation with the CIO council, they created the Federal Enterprise Architecture (FEA) featuring the Common Classification Schema, drawing inspiration from enterprise models defined by the DoD.

DoD: enterprise models

Meanwhile, people had been modelling the DoD in the form of business process and data models.

These models were designed to discover and organize the major business areas of the DoD.

They were not called architectures.

They were static representations of facts about the business of the DoD.

They included the Command and Control Core Data Model (CCCDM), covering data used in Command and Control Systems, which was incorporated into DoD Dictionary Systems (DDDS).

The DoD employed a toolset called Automated Design & Planning Tool (ADAPT ) to define technical and network architectures, using IDEF models.

Since ADAPT could also be used to create and manage process and data models, it was registered in DDDS.

More architecture data was added.

ADAPT was used to document CADM – a highly abstract data model of generic entities and relationships - loosely associated with DoDAF.

(Since virtually anything could eventually be put in CADM, it became useless for architecture work.)

DoD: DODAF1

OASD wanted to extended from Command and Control operations into business operations.

So they created DoDAF from their earlier C4ISR framework.

C4ISR and DoDAF were later used in the creation of MoDAF (UK), NAF (Nato) and the US Treasury EA Framework (TEAF)).

The DoD now have comprehensive systems engineering models for the technical parts of the Defense Acquisition System, including workflow models that describe how systems are procured, or developed using standards processes.

DoDAF, MODAF and NAF are decidedly systems-development-oriented.

Federal government: FEA reference models

FEAPMO wanted to help a government agency link their local EA model to the overarching set of processes, data, services, and technical standards that comprise the US president's e-gov initiatives.

Starting from the Common Classification Schema, they created reference models for business and data, along with guidance documents on how to make them work.

The FEA is now being constructed through a collection of five interrelated reference models.

The table below arranges the reference models in layers.

FEA Reference Model	About
PRM: Performance Reference Model	Aims, required performance improvements
BRM: Business Reference Model	Business areas and processes
SRM: Service Reference Model	Functions of ‘service components’
DRM: Data Reference Model	Data used in interfaces
TRM: Technology Reference Model	Technical services needed for deployment of components

You can view the table from the top-down as a business driven approach and from the bottom up as a component-based approach.

A 2004 GSA paper distinguished models for service components from models for the processes that use them.

A service component is a coarse-grained implementation of a business service via many software services, described using the three lower models (SRM, DRM and TRM).

The uses and goals of services components are described in the two higher models (BRM and PRM).

Every similar business activity (in the BRM) ought to achieve similar outcomes (in PRM) when reusing a service component.

A document called Combined Reference Models (CRM) documents the organization of these models (bar the DRM).

CRM is not a methodology, a metamodel, a tool, or a standard.

It is not yet possible to compare or merge EAs across federal bureaus or departments.

(You may be able to find more information at whitehouse.gov/omb.)

See also the table mapping the five FEA references models to TOGAF architecture domains in the concluding remarks on convergence and divergence.

Today, the aims of the FEA are expressed as:

facilitate cross-agency analysis
identify duplicative investments, gaps,
identify opportunities for collaboration within and across Federal Agencies.

DoD: DODAF2

To eliminate past mistakes and make architecture development useful for managers and architects alike, DoDAF version 2 contains a meta model, along with a "Fit for Purpose" concept of creating architectures at any level useful for management decision-making.

Layering and segmentation

The FEA practice guidance of Burke (in 2006) was that EA should be practiced iteratively and in layers.

Top layer - thin and sparse but broad and comprehensive - to support executive financial decisions about IT.
Lower layers are deeper and narrower.

(Avancier Methods feature different techniques at the levels of enterprise and solution architecture.)

The developers of DoDAF (also MODAF and NAF) recognized that their organizations are simply too large to develop and utilize an enterprise model at the top level.

So they focus more on lower level/tier architectures – some of them being program, system or solution architectures.

The DoD may never get beyond a 'virtual' top tier EA, which is designed to relate and validate architecture development in lower tiers.

The virtual EA has the breadth.

The program, solution, segment architectures provide the depth.

Convergence or divergence?

Telling the story above has involved some effort to remove discrepancies between different recollections of what happened.

Some say the different strands of EA development influenced each other very little; others believe there was a significant amount of copying and tailoring of ideas.

Some frameworks have converged, some have diverged.

As an example of convergence, the FEAF and TOGAF processes and deliverables look remarkably similar.

Who can reliably say now how much of the similarity is down to coincidental invention?

The table below shows a facile mapping between the reference models in FEA and the architecture domains in TOGAF.

FEA Reference Model	TOGAF architecture domain - building blocks and reference models
PRM: Performance Reference Model	Business Architecture – goals and objectives.
BRM: Business Reference Model	Business Architecture – functions and processes.
SRM: Service Reference Model	Applications Architecture – application building blocks.
DRM: Data Reference Model	Applications and Data Architecture - III-RM.
TRM: Technology Reference Model	Technology Architecture – TRM.

While DODAF and TOGAF share a common ancestor in TAFIM, they have diverged.

Since the DoD’s mainspring has always been interoperability, it wants to specify contractors’ deliverables but not their process.

By way of contrast, the Open Group’s Architecture Forum members have focused on process, with relatively slight descriptions of recommended artefacts and deliverables.

Published under the Creative Commons Attribution-No Derivative Works Licence 2.0 03/12/2014 11:36

Attribution: You may copy, distribute and display this copyrighted work only if you clearly credit “Avancier Limited: http://avancier.co.uk” at the start and include this footnote on each page .

No Derivative Works: You may copy, distribute, display only complete and verbatim copies of this paper, not derivative works based upon it..

For more information about the licence, see http://creativecommons.org.