Why Doesn’t the Federal Enterprise Architecture...

© 2010 Stanley B. Gaver

Why Doesn’t the Federal Enterprise Architecture Work?

An Examination Why the Federal Enterprise Architecture Program

Has Not Delivered the Expected Results and What Can be Done About It

Part I: The Problem

Stanley B. Gaver

Technology Matters, Inc.

Version 1.5

―It is ironic that … in a field where precision would be expected … it has become common for

software professionals to bandy about words such as ‗architect‘,‘ designer‘, ‗architectures‘, ‗styles‘,

and ‗models‘ without using their commonly held meanings. We only mystify what we say when we use

commonly understood words to mean wholly different things.‖

– Marc & Laura Sewell, The Software Architect‘s Profession

―Somehow it seems to fill my head with ideas -- only I don't know exactly what they are.‖

– Alice, Through the Looking Glass



Part I: The Problem

The findings, interpretations, and conclusions expressed herein are those of the author and do not

necessarily reflect the views of any employers or clients, past or present. Permission is granted

for free usage of all or portions of this document, including derived works, provided proper

acknowledgement is given.

Reader comments are welcome and can be sent to [email protected]. In particular, I welcome

information from EA practitioners about their own EA experiences in the federal government, or

in commercial practice if this paper happens to finds its way that far from the federal sector.

mailto:[email protected]

Why Doesn‘t the Federal Enterprise Architecture Work?


Table of Contents

PREFACE ................................................................................................................................................................ 6

INTRODUCTION ..................................................................................................................................................... 9

THE EVIDENCE ...................................................................................................................................................... 10

EXHIBIT 1: A GROWING REALIZATION ACROSS THE INDUSTRY ............................................................................................... 11 EXHIBIT 2: THE FEA REFERENCE “MODELS”: TRAGICALLY MISNAMED ................................................................................... 13 EXHIBIT 3: PROBLEMS WITH EA AT THE AGENCY LEVEL ........................................................................................................ 16

A Typical EA Program at Most Federal Agencies ................................................................................................ 16 Activities and Characteristics of a Typical Federal EA Program .......................................................................... 18 Failures or Restarts of EA at Multiple Federal Agencies ..................................................................................... 21

EXHIBIT 4: PROBLEMS WITH THE FEDERAL EA PROGRAM ..................................................................................................... 24 Brief History of EA in the Federal Government ................................................................................................... 24 Creation of Federal EA Repositories: Multiple Attempts Fall Short ..................................................................... 25 OMB Compliance / Assessment Reporting: Burdensome, Confused, Ineffective ................................................ 27

EXHIBIT 5: GAO REPORTS ON FEDERAL EA SHOW A LONG HISTORY OF PROBLEMS .................................................................. 29 EXHIBIT 6: A CONFUSED UNDERSTANDING ........................................................................................................................ 36

The Confused Understanding is Easily Observable ............................................................................................. 36 Confusion Even About the Definition “Federal Enterprise Architecture” ............................................................ 38 The GAO Raised the Issue But Didn’t Follow Through ......................................................................................... 39 The Government Recognized the Problem but Didn’t Dig Deep Enough to Fix It ................................................ 40

EXHIBIT 7: CONFUSING / MISLEADING / INCORRECT FEA DIAGRAMS ..................................................................................... 42 The Main “Federal EA” Diagram: Incorrect in Many Ways ................................................................................. 42 Diagram Reveals Confusion Over Roles of Reference Models, FEAMS, and Agency EAs .................................... 44 The Reference Models Are Often Mischaracterized in Diagrams ........................................................................ 45 The FEAC Graphical Guide: The Confused Understanding, Visually Depicted? ................................................... 47

THE RESULTS ........................................................................................................................................................ 48

NO FEDERAL ENTERPRISE ARCHITECTURE .......................................................................................................................... 48 NO COMMON AND SHARED UNDERSTANDING ................................................................................................................... 48 FEA DIDN’T FOLLOW ITS OWN ADVICE AND DIRECTION ....................................................................................................... 48 COMPLIANCE ACTIVITIES WERE FUTILE TIME WASTERS ....................................................................................................... 49 FSAM: A BLOATED METHODOLOGY THAT PRODUCES LITTLE BUT CONFUSION ........................................................................ 49 EA DOESN’T FACILITATE, IT IMPEDES NORMAL IT ACTIVITIES ................................................................................................ 51 WASTED TAXPAYER DOLLARS ......................................................................................................................................... 52 THE PROBLEMS PROPAGATE BEYOND THE FEDERAL EA PROGRAM ......................................................................................... 52

THE CAUSES ......................................................................................................................................................... 55

THREE KEY DEFICIENCIES ............................................................................................................................................... 55 THE PROBLEMS STARTED HERE: POOR USE OF TERMINOLOGY .............................................................................................. 55

Most of Enterprise Architecture … ISN’T “Architecture”! .................................................................................... 57 Other Mystifying EA Terms ................................................................................................................................. 59

POOR USE OF TERMINOLOGY PREVENTED A COMMON AND SHARED UNDERSTANDING.............................................................. 61 FAILURE TO DISTINGUISH BETWEEN WHAT IS AND WHAT ISN’T “ARCHITECTURE” ................................................................... 61

Zachman’s “Information Systems Architecture” Wasn’t the Same as Today’s “Enterprise Architecture” .......... 62 GAO’s FAA Study Identified “Logical” and “Technical” Architectures ................................................................. 64 The Results of Failing to Distinguish Between What is and Isn’t “Architecture” ................................................ 65

CONCLUSION ....................................................................................................................................................... 67


“BEFORE ENTERPRISE ARCHITECTURE”: AN IMAGINED SCENARIO .......................................................................................... 67 WE CREATED A NEW TECHNOLOGY DISCIPLINE THAT WASN’T NEEDED .................................................................................. 71

FINAL VIEW: WHAT IF ENTERPRISE ARCHITECTURE WAS AS VISIBLE AS BUILDINGS? .......................................... 72

INTRODUCTION TO PART II, THE PROPOSED SOLUTION ....................................................................................... 73

APPENDICES......................................................................................................................................................... 74

APPENDIX A: THE FEA REFERENCE “MODELS” AREN’T MODELS ........................................................................................... 74 APPENDIX B: IT’S NOT METADATA .................................................................................................................................. 84 APPENDIX C: EA MODELING USED THE WRONG PARADIGM ................................................................................................ 86 APPENDIX D: WHY FEAMS FAILED ................................................................................................................................. 91 APPENDIX E: RELATED ATTEMPTS TO CREATE FEDERAL EA REPOSITORIES – ADDITIONAL INFORMATION ....................................... 94 APPENDIX F: THE DATA REFERENCE MODEL, BIRTHED IN CONFUSION .................................................................................... 99 APPENDIX G: “DIAGRAM CONFUSION” .......................................................................................................................... 101 APPENDIX H: SUMMARY OF OCTOBER 2010 FEDERAL EA COMMUNITY SEMINAR .................................................................. 105

REFERENCES ....................................................................................................................................................... 107

ENDNOTES ......................................................................................................................................................... 112


List of Figures

FIGURE 1: REFERENCE MODELS SHOWN AS THE FEDERAL ENTERPRISE ARCHITECTURE ................................................................... 14 FIGURE 2: MANY FEDERAL EA PROGRAMS REGRESSED FROM 2001 TO 2006 ............................................................................. 22 FIGURE 3: NORMAL VS. GAO EA MATURITY ASSESSMENTS ..................................................................................................... 31 FIGURE 4: FEA PMO EQUATED THE FEA TO THE REFERENCE MODELS ....................................................................................... 38 FIGURE 5: THE MAIN “FEDERAL EA” DIAGRAM: INCORRECT IN MANY WAYS .............................................................................. 42 FIGURE 6: CORRECTED REFERENCE MODELS HIERARCHY .......................................................................................................... 43 FIGURE 7: DIAGRAM REVEALS CONFUSION OVER REFERENCE MODELS, FEAMS, AGENCY EAS ....................................................... 44 FIGURE 8: MISCHARACTERIZATION OF REFERENCE MODELS ...................................................................................................... 45 FIGURE 9: WHAT SHOULD HAVE BEEN DIAGRAMMED ............................................................................................................. 46 FIGURE 10: RECORDS MANAGEMENT AND FEA REFERENCE MODELS ........................................................................................ 46 FIGURE 11: FEAC’S “GRAPHICAL GUIDE” DIAGRAM .............................................................................................................. 47 FIGURE 12: “ENTERPRISE” DATA INCORRECTLY POPULATED AS “TECHNOLOGY ARCHITECTURE” METADATA ..................................... 63 FIGURE 13: COMPARISON OF BRM TO LINNAEAN TAXONOMY .................................................................................................. 76 FIGURE 14: TRM INCORRECTLY MODELED AS ENTITIES ........................................................................................................... 78 FIGURE 15: PRM / TRM / BRM / SRM INCORRECTLY MODELED AS ENTITIES IN THE FTF ........................................................... 79 FIGURE 16: INTERMINGLING OF ATTRIBUTE AND ENTITY DEFINITIONS ......................................................................................... 81 FIGURE 17: THE BRM IS NOT "THE BUSINESS ARCHITECTURE" ................................................................................................ 82 FIGURE 18: INCORRECT USE OF “DATA MODELING” TO POPULATE EA REPOSITORY ...................................................................... 89 FIGURE 19: INCORRECT REPRESENTATION OF REFERENCE MODEL DATA IN FEAMS ...................................................................... 93 FIGURE 20: “WHAT DOES THIS DIAGRAM REALLY REPRESENT?” ............................................................................................. 101

List of Tables

TABLE 1: THE “CASE SUMMARY” ........................................................................................................................................ 10 TABLE 2: AGENCY LEVEL: TYPICAL EA PROBLEMS AND UNDERLYING CAUSES ............................................................................... 17 TABLE 3: AGENCY LEVEL: EA PROGRAM MANAGEMENT – PROBLEMS & LIMITATIONS ................................................................... 19 TABLE 4: AGENCY LEVEL: PROBLEMS POPULATING THE EA REPOSITORY ...................................................................................... 19 TABLE 5: FEDERAL LEVEL: MATURITY REGRESSION OF THREE GAO STUDIES ................................................................................ 23 TABLE 6: FEDERAL LEVEL: AGENCIES WITH NO MATURITY PROGRESSION, 2001-2006 ................................................................. 23 TABLE 7: MULTIPLE ATTEMPTS TO CREATE FEDERAL EA REPOSITORIES ....................................................................................... 26 TABLE 8 SUMMARY OF GAO ENTERPRISE ARCHITECTURE REVIEWS AND REPORTS ........................................................................ 33 TABLE 9: FEA CONCEPTS ADOPTED BY THE INFORMATION SHARING ENVIRONMENT...................................................................... 53 TABLE 10: “ARCHITECTURE” TERMS MISUSED IN FEDERAL ENTERPRISE ARCHITECTURE ................................................................. 58 TABLE 11: OTHER MYSTIFYING TERMS USED IN FEDERAL ENTERPRISE ARCHITECTURE ................................................................... 59 TABLE 12: DESCRIPTIONS OF FEA "MODELS" AS TAXONOMIES ................................................................................................. 74 TABLE 13: LIKELY ENTITIES FOR THE FIVE “REFERENCE TAXONOMIES” ........................................................................................ 77 TABLE 14: MODELING FEA TAXONOMY ATTRIBUTES .............................................................................................................. 80 TABLE 15: DESCRIPTIONS OF WHAT TO LOAD INTO FEAMS ..................................................................................................... 92 TABLE 16: OBJECT TYPES DEFINED BY DIFFERENT REPOSITORY INITIATIVES .................................................................................. 97


PREFACE

Work on this paper began more than four years ago with a seemingly insignificant task. To help some

business planners fill out the EA section of their Exhibit 300 business cases, I did some simple research to

better understand and explain – in a ―non-EA way‖ – the purpose of the FEA Reference Models.

This research quickly led to an understanding that the Reference Models were completely misnamed.

They weren‘t actually ―models‖, but rather taxonomies, and calling them models was causing significant

and widespread confusion. Furthermore, this confusion was rippling throughout the federal EA program,

triggering other problems and failures.

My initial finding led to a string of additional research into different parts of the federal EA program, and

each analysis brought a new discovery that yet another part of the federal EA program was misunderstood

or poorly implemented or just plain broken.

Gradually, my findings, combined with observations from doing EA work at six federal agencies and one

large financial company, made it increasingly clear that there was widespread confusion and

misunderstanding about Enterprise Architecture itself, not only within the federal government, but within

commercial EA as well.

Finally, this research culminated in a completely unexpected and unsettling conclusion: Enterprise

Architecture within the federal government hasn‘t been working, and far more often than not hasn‘t

delivered useful results. Moreover, significant parts of the federal EA program have been complete and

utter failures.

This paper is now more than four years in the making.

It‘s not that the material has actually required four years to research, process, and write about. Rather,

many times I doubted where my findings and conclusions were taking me. More than once I abandoned

the project, thinking that I must have been missing something or that my understanding of Enterprise

Architecture must have been wrong. After all, how could Enterprise Architecture not be working?

How could so much work be performed, for so long, by so many, and yet too often produce nothing

of value?

But with the passage of time, extensive research and, finally, by the act of writing this paper, I now know

how this can be the case. I‘m now confident that my findings and conclusions are correct. And any

lingering doubts that I may have had (and there were some) have been erased by recent developments

within the federal Enterprise Architecture program. Although they have not yet identified the root causes,

the federal EA community has at long last collectively acknowledged that there are problems with the

Federal EA program.

In early October 2010, the Federal CIO Council hosted a meeting attended by approximately 80 senior

architects, CIOs, and CTOs from throughout the federal government to discuss the concerns of federal EA

practitioners and stakeholders and plan for the future of the federal EA program. 1

The concerns raised at this meeting echo many of the findings of this paper:

1. Lack of a shared and common understanding. ―Currently, there is a lack of coordination and

clarity among federal sector architecture concepts and practices. A number of community

members expressed a desire to see a ‗common approach‘ to federal architecture be developed

that could be adopted by civilian, military, and intelligence agencies to promote the ability to


better exchange architecture information and to improve work being done on multi-agency,

sector-wide, inter-government, and international efforts.‖ This paper devotes an entire

section, ―Exhibit 6: A Confused Understanding‖, discussing the ―lack of coordination and

clarity‖.

2. Confusion about what Enterprise Architecture is. One of five main themes that arose from the

meeting was expressed as a question: ―Where does Enterprise Architecture belong?‖ That the

question is being raised now, after more than a decade of federal EA, affirms one of the main

themes of this paper: ―The FEA PMO has never made clear even what Enterprise

Architecture is.‖

3. Problems associated with Federal EA compliance reporting. ―[Federal CIO Vivek Kundra]

said that the federal EA community has been often focused on compliance documentation at

the expense of supporting mission improvements.‖ This paper examines compliance

reporting, and shows that this reporting has been ―burdensome, confused, and ineffective‖.

4. Fundamental change is needed. The attendees recognized both that the EA community has to

change and that the time for a change has come. This paper also affirms the need for change,

and Part II of the paper proposes five-step plan to implement this change. (Part II is still

being developed; for a brief overview, see section ―Introduction to Part II, The Proposed

Solution, on page 73.)

The results of the CIO Council‘s October meeting should make easier the task of convincing relevant

stakeholders that my findings and conclusions are correct. Still, the degree of misunderstanding about EA

is massive, so I have little doubt that some EA practitioners, already set in their training and beliefs, will

steadfastly disagree with this paper‘s conclusions. To others I‘ll have committed heresy. And to some

with vested interests, my conclusions will be about as welcome as a skunk at a picnic.

All I can do is present the evidence and ask that each reader review it with an open mind. I believe I‘ve

made a solid case that supports my conclusions. And I‗m betting that many readers will recognize within

these pages some of their own experiences and frustrations with Enterprise Architecture.

I welcome input, both pro and con, about my findings. Please feel free to send comments, suggestions,

additional information, and even your own EA experiences to me at [email protected].

Some Personal Notes

In closing the preface, I feel it necessary to add some personal notes and specifically mention the good

work that the federal government is doing to improve management of its vast IT resources.

First, I want to make clear that despite the many problems and deficiencies that are discussed in these

pages, I‘m still a firm believer in the discipline currently known as ―Enterprise Architecture‖. More

specifically, I have a strong faith that, once fixed, EA can finally meet the expectations originally

envisioned for it and can then genuinely support the huge and complex task of transforming the federal

government.

In more than 30 years working in the federal IT community, both as a federal employee and as a

consultant, I‘ve worked in more than a dozen federal agencies. In this time, I‘ve often witnessed the

duplication, redundancy, and wasted taxpayer dollars, so I was an easy and immediate convert to this

new discipline of Enterprise Architecture. I still am.

mailto:[email protected]


Although the paper, by necessity, exposes the many, many problems with the federal EA program, I

don‘t want any reader to come away with an impression that ―all is lost‖. First, EA can be

rehabilitated. Second, I want to stress that what is broken is only one relatively small – albeit very

important – part of the federal government‘s efforts to better manage information technology: the

actual practice of Enterprise Architecture itself. It‘s important to keep in perspective that EA is only a

supporting function that helps to ―inform, guide, and constrain‖; it is not ―the main event‖.

And acknowledgement must be made about some of the wonderful work that the federal government

has done so far to improve services and lower the costs of federal IT. Two examples include:

- The e-Gov initiatives that reduce redundancy and lower costs by consolidating many business

processes at the federal level, e.g. HR Connect (human resources), budget formulation, and

federal recruitment.

- The Identity, Credential, and Access Management (ICAM) and Homeland Security Presidential

Directive-12 (HSPD-12) initiatives, which improve the security of federal buildings and IT

resources while also lowering costs by standardizing and consolidating identity and credential

management.

Next, it is not my intent to criticize or detract from any of the otherwise excellent work done by the

many people dedicated to the enormous task of improving services to citizens and the management of

federal IT resources. I‘ve often felt that it‘s unfortunate that the taxpayers don‘t know more about

some of the amazing work that‘s being done to improve government services to them, all while

reducing the costs of delivering these services!

Finally, I want to acknowledge and thank three colleagues, Fran Lovata, Raphael Malveaux, and John

Williams, for their time reviewing and critiquing this paper, offering support and suggestions, and

perhaps most importantly, providing independent sanity checks on both my evidence and conclusions.

My highest compliment to them is: ―You‘re among the very few who ‗get it‘‖.


INTRODUCTION

―Recently there's a growing realization that traditional enterprise architecture as it‘s often

practiced today might be broken in some important way. What might be wrong and how to fix it

are the questions du jour.‖2

It‘s been more than fourteen years since the passage of the Clinger-Cohen Act that began the era of

Enterprise Architecture in the federal government. By the time of this writing in the fall of 2010, the

federal government has spent more than a billion dollars in its attempt to put Enterprise Architecture into

practice across the federal government.*

Unfortunately, much or possibly even most of this taxpayer money has been wasted. Many or likely even

most federal Enterprise Architecture efforts have delivered little of value, and some agencies have

literally nothing to show for the money spent.

In short, the Federal Enterprise Architecture program hasn‘t been working.

By now, this should be self-evident. There is much credible evidence, both anecdotal and documented,

that the federal government‘s EA program has not met expectations and has not produced the desired

results.

Despite the vigorous and honest efforts of EA practitioners throughout the government and the

expenditure of huge sums of money, too many – probably most – federal EA programs have produced

minimal results and some haven‘t produced any results at all. Some are just empty shells, maintained

only to meet OMB requirements.

This is not to say that there have been no successes in the federal EA program or that all federal agencies‘

EA programs have failed. There have been some successes, and at least a few agencies have EA

programs that actually help their agencies manage and modernize their information technology resources.

And this report would be remiss not to acknowledge the progress made by the two dozen or so

eGovernment initiatives that are a by-product of a key notion of Enterprise Architecture. By a simple re-

framing of how the government is perceived and operated as an organization – as a single, integrated

enterprise, instead of scores of mostly autonomous departments and agencies – the government has

successfully started the long process of reducing the huge cost of federal IT expenses by eliminating

redundancies and duplication of effort.

But even as these successes are acknowledged, it must also be said that most of them managed to be

successful despite the many failures of the federal Enterprise Architecture program, and not as a result of

the program.

The problems with Enterprise Architecture aren‘t unique to the federal government; many of these same

problems are also found in commercial EA, so much of what is covered in this report is also applicable to

the entire practice of Enterprise Architecture. But the focus of this report is on Enterprise Architecture as

practiced in the federal government, what‘s wrong with it, what has caused it to fail, and what steps can

be taken to fix what‘s wrong.

It is long past time for us in the federal EA community to recognize and acknowledge the many failures

and shortcomings of the federal EA program. The hope is that this paper will start that process.

* See ―Wasted Taxpayer Dollars‖ on page 52 for source of billion-dollar figure.


THE EVIDENCE

The case that the Federal Enterprise Architecture isn‘t working is presented on the following pages as

seven ―exhibits‖, or sets of related facts and analyses about Enterprise Architecture as practiced within the

federal government. These exhibits will collectively prove the case that the Federal Enterprise

Architecture is, in fact, not working. These seven exhibits are summarized below.

Table 1: The “Case Summary”

Exhibit Description

Exhibit 1: A Growing Realization Across the Industry

EA often doesn’t work well anywhere because the problems with Enterprise Architecture are fundamental in nature.

Exhibit 2: The FEA Reference “Models”: Tragically Misnamed

Calling these “models” has caused massive confusion and misunderstanding, and is the biggest single factor causing the federal EA not to work.

Exhibit 3: Problems with EA at the Agency Level

Many or even most agencies experienced many of the same problems and failures while attempting to implement their EA’s. These shared experiences are examined and explained.

Exhibit 4: Problems with the Federal EA Program

Many of the initiatives of FEA program failed or produced very little value. These failures at the federal level are analyzed and underlying causes are presented.

Exhibit 5: GAO Reports on Federal EA Show a Long History of Problems

Many GAO reports on EA in the federal government reveal both fundamental and long-running problems

Exhibit 6: A Confused Understanding

Confusion and misunderstanding about Enterprise Architecture has been widespread from the start and exists to this day.

Exhibit 7: Confusing / Misleading / Incorrect FEA Diagrams

Some of the diagrams in FEA documents are both evidence of the confusion within the FEA and also propagators of some of this confusion.


EXHIBIT 1: A GROWING REALIZATION ACROSS THE INDUSTRY

―Architectures, like fondue sets and sandwich makers, are rarely used.

We occasionally dig them out and wonder why we ever spent the money on them." 3

– Chief Architect of a large telecommunications company

The first evidence presented to prove the case that the Federal Enterprise Architecture program isn‘t

working are examples from EA programs in the private sector, where there is a growing realization that

something is intrinsically wrong with the discipline. There is an increasing awareness that EA hasn‘t

been working well in many organizations, both in industry or in government:

In their 2006 book ―Enterprise Architecture as Strategy: Creating a Foundation for Business

Execution‖, authors David Robertson, Jeanne Ross, and Peter Weill describe how Enterprise

Architecture can be used to ―build a foundation for business transformation‖ that allows

organizations to maximize their investments in information technology.

But even while extolling the advantages of EA, the authors also raise some troubling

indicators that something is wrong with the practice:

- ―In presentations we have railed against traditional IT architecture efforts for their

remoteness from the reality of the business and their heavy reliance on mind-numbing

detail represented in charts that look more like circuit diagrams than business descriptions

and that are useful as little more than doorstops.‖

- ―Unfortunately the term architecture has acquired a negative connotation in some

companies. Many companies have questioned the value of their architecture initiatives.

Some of those initiatives are viewed as IT ivory towers that are isolated from business

reality.‖ *

- ―…the historic ineffectiveness of IT architecture efforts in large organizations has

troubled us for years.‖

- ―Architectures, like fondue sets and sandwich makers, are rarely used. We occasionally

dig them out and wonder why we ever spent the money on them." (Also used as epigraph

to Introduction) 4

An article in the August 2006 edition of the Journal of Enterprise Architecture suggested

strongly (and gave a clue to the underlying cause) that there is a fundamental problem with

EA when its practitioners don‘t even share a common understanding about the discipline:

―There is a lack of consensus on EA concepts, terminologies, goals, approaches, techniques,

and outcomes. Enterprise architects cannot even agree on the very basic concepts such as

„What is an enterprise architecture?‘‖5 (emphasis added)

A 2008 Gartner analysis titled ―Enterprise Architectures Provide Business Benefits Only

When They're Used‖, also raised concerns by pointing out that the expected benefits of EA

too often weren‘t being met:

* From the author‘s observations and discussions with other practitioners, this negative connotation and questioning

the value of EA is also widespread throughout the federal government


- ―We often talk to organizations that have expended considerable effort developing an

EA, yet realize little business benefit.‖

- ―What we invariably discover in the course of the discussion is that, for these

organizations, the development of the architecture has become an end unto itself.‖

Finally, in an aptly-named online article from September 2009, ―Fixing Enterprise

Architecture: Balancing the Forces of Change in the Modern Organization‖, author Dion

Hinchcliffe got right to the heart of the matter:

―…there's long been something fairly unsatisfying about the relationship that enterprise

architecture has had with the business side of most organizations. Recently there's a growing

realization that traditional enterprise architecture as it‘s often practiced today might be broken

in some important way. What might be wrong and how to fix it are the questions du jour.‖6

In very much the same way and for many of the same reasons that Enterprise Architecture is

―broken in some important way‖ in commercial practice, the federal government‘s EA program is

also broken. But the federal government‘s EA appears to be broken in more ways and the breaks

are far worse than in commercial EA practice.


EXHIBIT 2: THE FEA REFERENCE “MODELS”: TRAGICALLY MISNAMED

What‘s in a name? That which we call a rose

By any other name would smell as sweet

While the name that Juliet used for her sweet smelling flower may not have been important for her, the

same cannot be said for the names that we use in technical fields where precision is necessary.

And there is perhaps no example, literally anywhere, that illustrates more effectively the need for precise

and correct naming than the selection of the word ―model‖ to name what is really a set of taxonomies: the

FEA reference ―models‖.

More than any other single factor, the decision to use the word ―model‖ instead of the correct term

―taxonomy‖ has caused massive confusion and misunderstanding that has undermined much of the

Federal Enterprise Architecture. Furthermore, this confusion and misunderstanding has rippled

throughout the federal EA program, propagating other failures and deficiencies.

What should have been a very simple idea – five standard, federal-wide taxonomies to categorize

investments, performance measures, and IT resources uniformly across the federal government – has, by

misnaming them ―models‖, spawned massive confusion about them and their real (simple) purpose.

Here‘s why:

First, we need to understand and accept that the BRM, SRM, TRM, DRM, and PRM are indeed

taxonomies. Proof is readily available:

FEA guidance and documentation, including the Reference Models documentation itself,

specifically and repeatedly described them as taxonomies! See Table 12: Descriptions of

FEA "Models" as Taxonomies on page 74 for multiple examples.

The DRM document included multiple narratives about taxonomies and even compared itself

to the Linnaean taxonomy for biological sciences as an example of another taxonomy. See

pages 9, 36, 38-41, 43 and 79 of the DRM document (version 2.0).

The GAO, in one 2004 report, stated: ―GAO‘s reading of [the FEA reference models]

suggests that it is more akin to a classification scheme for government operations than a true

enterprise architecture.‖ [emphasis added]

Second, the term models implied that the Reference Models must be ―something big‖.

More specifically, most people thought that the Reference Models were real models of something, or real

―things‖ that autonomously existed in their own right, so these ―models‖ gained a larger presence or

significance than actually existed.

Probably the best example of this tendency to view them as ―something big‖ was the widespread

misconception that the Reference Models were the Federal Enterprise Architecture. (This confusion still

exists.) Diagrams that were produced by the FEA PMO like the one shown in Figure 1 only served to

reinforce the misconception.


Figure 1: Reference Models Shown as the Federal Enterprise Architecture7

The Reference Models were called ―foundations of architecture‖.* Large documents were published to

define and expound on them. For example, the second version of the BRM, released in June 2003, was a

63 page document. The 2.0 version of the Data Reference Model (DRM), released in 2005 came in at a

whopping 114 pages. Neither should have required more than 20 or 30 pages to describe all taxonomy

values. (The part of the BRM document that described the actual taxonomy values was 23 pages long.)

The DRM is the most glaring example of the models bloating beyond what was really needed. Because

the DRM‘s developers incorrectly believed that it was a ―model‖, the DRM metastasized far beyond what

it should have been: a simple taxonomy to classify agencies‘ data in a uniform way across the federal

government.

Instead of just defining a hierarchical taxonomy similar to those that had been defined for the other four

FEA taxonomies, the DRM developers created something that seems to be more of an (incomplete) data

administration capability that included three of its own data models. (None of the other taxonomies

defined their own data model.)

Ironically, even though its developers specifically (even emphatically) declared the DRM to be a

taxonomy, they were so focused on creating a ―model‖ that they entirely overlooked the actual definition

of the taxonomy, complete with classification values. The DRM was thus released as the only FEA

taxonomy that didn't define an actual taxonomy (with values).

Perhaps the easiest way to really understand the effect of misnaming the FEA taxonomies as ―models‖ is

to take an example from another federal agency and apply the same thinking as was used for the FEA.

The U.S. Census Bureau recently conducted the 2010 Census. To do this, the Bureau collected

demographic data about the population, including data attributes such as Name, Sex, Age,

Hispanic_Origin, Race, and Rent_or_Own_Home. (The underlined attributes all form very simple

taxonomies.)

* The FEA PMO often incorrrectly described the models as ―foundations of architecture‖ or ―the foundation of the

FEA‖, but they couldn‘t possibly be foundations of anything. See related discussion on pages 37, 43, and 80.


Let‘s take the simplest one, the data attribute ―Sex‖. This attribute has two values, ―Male‖ and ―Female‖,

and forms a very simple two-valued taxonomy which classifies the population into two groups.

Can‘t be much simpler and understandable, right?

Now let‘s name it the Gender Reference Model (GRM). Does this add clarity?

Is it correct to call the attribute ―Sex‖ a model? If we call it a model, will data modelers now (incorrectly)

try to model it as an entity instead of (correctly) as an attribute? Will managers and other non-technical

staff think it‘s something more than just a very simple taxonomy that tells us how many males and

females are in the population?

Finally, when filling out their census form, were citizens asked to ―map to the Gender Reference Model‖,

just as federal staff were asked to ―map to the FEA reference models‖ when they filled out the EA data in

their Exhibit 300‘s? Would it be more intuitive and meaningful to say ―classify‖ instead of ―map‖? (The

GAO mentioned the ambiguity of the terms ―map‖ and ―align‖. See ―The GAO Raised the Issue But

Didn‘t Follow Through‖.)

Now, let‘s define all of the census data elements as ―models‖:

Gender Reference Model (GRM)

Age Reference Model (ARM)

Hispanic Origin Reference Model (HRM)

Race Reference Model (RRM)

Homeownership Reference Model (HRM)

Finally, imagine that the Census Bureau defined a ―Federal Demographic Architecture‖, or FDA:

―The Federal Demographic Architecture (FDA) consists of a set of interrelated ‗Population

Reference Models‘ designed to facilitate demographic analysis of the American population and to

provide opportunities for collaboration with academic and government organizations that utilize

the FDA to evaluate population trends. Collectively, the reference models comprise a framework

for describing important elements of the FDA in a common and consistent way.‖

Is the Federal Demographic Architecture the same as the Population Reference Models? Is the Census

the same as the Federal Demographic Architecture? Is either the FDA or the ―models‖ a framework?

Clearly these ―models‖ and the Federal Demographic Architecture don‘t make much sense in the Census

domain. Do the similar constructs defined in the Architecture domain make any more sense?

Calling these FEA taxonomies ―models‖ has completely mischaracterized them and more than any

other single factor has most impeded the development of a true Federal Enterprise Architecture.

For a more detailed examination of this topic see Appendix A: The FEA Reference ―Models‖ Aren‘t

Models.


EXHIBIT 3: PROBLEMS WITH EA AT THE AGENCY LEVEL

Exhibit 1 presented evidence from the entire EA industry that EA isn‘t working well anywhere, either in

the private sector or in government.

This Exhibit (3) and the next Exhibit (4) will focus on EA in the federal sector, and presents the evidence

that proves that EA isn‘t working within the federal government.

Exhibit 3 (―Problems with EA at Federal Agencies‖) examines Enterprise Architecture at the department /

agency level; Exhibit 4 (―Problems with the Federal EA Program‖) examines EA at the federal level, with

specific attention paid to the activities and results of the FEA PMO.

A TYPICAL EA PROGRAM AT MOST FEDERAL AGENCIES

Many, if not most, agency EA programs have suffered from a host of problems that for years have

prevented them from producing anything of real value. Why this has been so can quickly be gleaned

from a brief history of a ―typical‖ federal EA program.

Fortunately, a 2005 internal audit performed by the Department of Justice‘s Inspector General, ―The

Status of Enterprise Architecture and Information Technology Investment Management in the Department

of Justice‖, provides an almost perfect example* of a ―typical‖ federal EA program.

The following passage is taken directly from the audit report, from the first part of a section labeled

―Department-level Enterprise Architecture Efforts‖. Typical problems that are faced by federal EA

programs have been noted directly in the text with a superscripted number within parentheses (e.g. (1)

).

The factors that cause these problems are then evaluated in Table 2, below, ―Agency Level: Typical EA

Problems and Underlying Causes‖.

Efforts to develop a Department Enterprise Architecture have been underway since 1999. (1)

However, the Department‘s efforts to develop an Enterprise Architecture have suffered from a

lack of institutional commitment(2)

and a changing perception of the composition of(3)

, and

priority for, a Department-level Enterprise Architecture.(4)

Adding to this confusion are the

additional Enterprise Architectures developed by components.(5)

In 2001, the Department began developing an Enterprise Architecture based on the Federal

Enterprise Architecture Framework (FEAF). The Department secured funding and hired System,

Data, Infrastructure, and Business Architects and an Investment Management Coordinator. This

group assembled ―as-is‖ business, data, and application architectures by December 2001.

However, a Department official told us that other priorities prevented this early Enterprise

Architecture effort from continuing (6)

. Further, the ―as-is‖ architectures were not updated and

were not useful for later efforts to develop a Department-wide Enterprise Architecture (7)

.

In 2002, the Department began using the Federal Enterprise Architecture Management System

(FEAMS), a web-based automated tool that provides agencies with access to initiatives aligned to

the FEAF and associated reference models to assist in developing an Enterprise Architecture.

The FEAMS was designed in close cooperation with the OMB, and the OMB required the

Department to use the FEAMS to develop its Enterprise Architecture. According to a Department

* That this is an ―almost perfect example‖ is based both on the resources examined for this paper as well as personal

experience of the author gained while doing EA work at six federal agencies and one large company.


official, the Department considered the FEAMS to be a cumbersome system that made inputting

and extracting data difficult. Further, while the system served as a storage place for models, it

could not perform analyses. Consequently, despite the OMB‘s direction, the Department

discontinued the FEAMS. (8)

In 2003, the Department piloted the Popkin System Architect software for use as its automated

tool. Although the DEA used the Popkin software in developing its Enterprise Architecture, a

Department official stated that Popkin would require significant modifications to serve the

Department‘s purposes. Based on the results of the pilot, the Department decided not to use

Popkin. (9)

A Department official stated that commercial off-the-shelf tools are now being

explored as aids to the development of the Enterprise Architecture. However, the Department has

no timetable for acquiring an automated tool to document the development of the Department‘s

Enterprise Architecture. In addition, Department officials were unable to provide expenditure

data for Enterprise Architecture efforts prior to FY 2004. (10)

After rejecting the FEAF (11)

along with the FEAMS automated tool, the Department began

devising its own framework intended to lead to a Department-wide Enterprise Architecture. (12)

The Department expects the framework, called the Capability Delivery Model, to be completed in

late FY 2005 and the resulting Enterprise Architecture by late FY 2009. (1)

8

Table 2 summarizes the underlying cause(s) for each problem. Note that one underlying problem is not

included in the table because it‘s endemic to EA and is underlies all of these identified problems: there is

widespread confusion and misunderstanding about Enterprise Architecture itself. See Exhibit 6: A

Confused Understanding for more information.

Table 2: Agency Level: Typical EA Problems and Underlying Causes EA Development Problem Causes / Related Analysis

1) Long development times Caused by the cumulative effect of many of the other identified problems

2) Lack of institutional commitment Many agency executives have never fully understood the “purpose, content, and value of enterprise architecture”: See GAO statement about subject.

3) Changing ideas of what should be included in an EA

What should be included has never been adequately specified

Lack of a common EA repository model.

4) Changing ideas of need for a Department-level EA

Although it should be clear that Department-level EA’s should be developed, the need for them has never been specifically articulated or required

5) EAs developed by components (usually non-integrated)

Most EA work is done “sub-enterprise”; rarely is there true enterprise-wide integration (e.g. Department-wide)

6) Interruption of EA projects due to other priorities

Once EA fails to show results and provides little value, more value-laden projects take precedence


EA Development Problem Causes / Related Analysis

7) Failure to maintain collected EA data Agencies perform “modeling” using the wrong paradigm which results in a slow, manual process to populate the repository. Long before the “modeling” is done, it’s out of date

Instead of using modern ETL methods to collect data from other sources of record (usually computerized), largely manual “data calls” are made to obtain the data needed for the repository

See Appendix B: It’s Not Metadata and Appendix C: EA Modeling Used the Wrong Paradigm

8) Early adoption, displeasure with, and ultimate rejection of FEAMS

Unclear understanding / communication of EA generally: See Exhibit 6: A Confused Understanding

Unclear understanding / communication about FEAMS: See Appendix E: Related Attempts to Create Federal EA Repositories – Additional Information; Appendix D: Why FEAMS Failed

9) Evaluation and/or use and rejection of commercial EA product(s)

Many EA products were originally modeling tools or metadata repositories adapted from systems development products; most still aren’t the right tools for EA.

and Appendix C: EA Modeling Used the Wrong Paradigm

10) Untracked EA activities, results, spending EA staff and Chief Architect, overwhelmed and confused, spend all of time hopelessly trying to develop something of value

Significant times required for OMB reporting is a contributing factor

11) Use, failure, rejection of FEAF Unclear understanding / communication of frameworks and FEAF.

12) Development of custom “framework” Ambiguous/confusing definition of framework: see The Problems Started Here: Poor Use of Terminology.

ACTIVITIES AND CHARACTERISTICS OF A TYPICAL FEDERAL EA PROGRAM

In addition to the historical perspective presented in the prior section, another way to examine the

effectiveness of EA at the department or agency level is to review the activities and characteristics and the

related problems faced by a ―typical‖ federal EA project, particularly the major activity of ―populating the

EA repository‖.

(Note that the amount of time and effort put into populating the EA repository varies widely between

agencies. While most projects spend a significant amount of time populating the repository, some

agencies don‘t even create one. The extremes of this activity, ranging from ―no time spent‖ to ―nearly all

of time spent‖ are themselves a problem, as it‘s an indicator of wide variances of understanding about

what Enterprise Architecture is supposed to be.)

This examination is summarized in two tables that begin on the next page. The first table describes some

of the main program management activities and characteristics. The second table describes activities

specifically related to population of the EA repository.


Table 3: Agency Level: EA Program Management – Problems & Limitations Activity / Characteristic Problems / Limitations

1. OMB Reporting & Compliance EA reporting to OMB is time-consuming

OMB’s Enterprise Architecture Assessment Framework (EAAF) was complex and the assessment criteria were subjective. Despite extensive documentation on the EAAF, there was always confusion and varying opinions about what constituted acceptable evidence that the EAAF criteria were met.

Due both to the confusion about it and the report’s subjectivity, the EAAF usually didn’t provide a true measure of agencies’ EA maturities.

See section OMB Compliance / Assessment Reporting: Burdensome, Confused

2. Managers’ Confusion About EA Due to the many problems described throughout this report, and despite the extensive documentation about EA (and partly even because of it), most managers and staff who have to work with or use the results of agency EA’s still don’t understand it. The GAO made specific raised this issue in their 2002 study of EA in the federal government. See The GAO Raised the Issue But Didn’t Follow Through.

Table 4: Agency Level: Problems Populating the EA Repository

Activity / Characteristic Problems / Limitations

1. EA repositories, usually commercial products, are installed

1. In most cases, because EA programs are run at the “sub-enterprise” level, EA repositories are installed only at that level. While some enterprise integration is performed where required by OMB (e.g. Investment data), most EA work is done sub-enterprise. Even though it’s supposed to be Enterprise Architecture, rarely is there Department- or enterprise-wide integration.

2. Many EA products were originally modeling tools or metadata repositories adapted from systems development products that still aren’t the right tools for EA. Often, after tools fail to meet needs, agencies change to another tool and/or finally develop a custom repository. See

and Appendix C: EA Modeling Used the Wrong Paradigm

2. “Enterprise Architecture Modeling” is performed that uses the same diagramming techniques as data and process modeling

“Enterprise Modeling” isn’t the same as traditional systems development modeling (e.g. data and process models), and shouldn’t use the same techniques as those used for developing systems. See Appendix C: EA Modeling Used the Wrong Paradigm.

3. The focus is on the collection or creation of diagrams The diagrams produced are essentially useless for reporting and analysis, particularly by people untrained in “modeling”. Once created, they are “useful as little more than doorstops” and are almost never used. See Figure 18 and related text in Appendix C: EA Modeling Used the Wrong Paradigm.

4. “Metadata” and “EA artifacts” are collected and loaded into EA repository

1. What’s being collected is data, not metadata. (See Appendix B: It’s Not Metadata.)

2. The definition of “EA artifacts” has never been clearly defined, so often includes an unmanageable hodgepodge of anything, including discrete data, diagrams, and documents.


Activity / Characteristic Problems / Limitations

5. Often, “data calls” are made to obtain the data necessary for populating the repository

Because EA repositories are maintained at the “sub-enterprise” level, data calls are usually also only at the sub-enterprise level. Again, rarely is a true enterprise-wide architecture developed. See

6. The population of the EA repository is largely a manual process, often based on “diagramming”

Populating the repository, because it incorrectly uses modeling techniques adopted from traditional system development, is labor intensive and extremely time-consuming. The repository is out of date long before it’s delivered. See Appendix A: The FEA Reference “Models” Aren’t Models

7. “The development of the architecture becomes an end unto itself.”

In most cases, no requirements analysis is performed to determine exactly what data and data relationships need to be defined. This in turn allows massive scope creep as often “anything of possible use” is incrementally determined to be needed. Finally, relationship definitions often spin out of control as “everything is related to everything else”.

Why Doesn‘t the Federal Enterprise Architecture Work? Page 21 Page 21

FAILURES OR RESTARTS OF EA AT MULTIPLE FEDERAL AGENCIES

So far in ―Exhibit 3: Problems with EA at the Agency Level‖, I‘ve presented evidence that EA isn‘t

working at the agency level by (1) reviewing the historical experience of an ―average‖ EA program and

(2) examining the activities, characteristics, and problems of agency EA programs as they work to

develop their Enterprise Architectures.

This third part of Exhibit 3 presents additional evidence that EA isn‘t working at the agency level by

providing a brief summary of the backsliding, restarts, and the many ―redirections‖, if not outright

failures, of EA programs at many agencies.

While the problems with agencies‘ EA programs discussed in the prior two sections could conceivably be

accepted as normal difficulties encountered by any complex activity involving many people, the number

of agencies that have not been able to implement effective EA programs and that have failed to produce

anything of value cannot be accepted as ―normal‖. This section might be viewed as the ―smoking gun‖

evidence that the federal EA isn‘t working at the agency level.

To begin, we briefly examine the results of three studies GAO performed between 2001 and 2006 on the

maturity of EA in the federal government. (These studies are discussed in more detail in Exhibit 5: GAO

Reports on Federal EA Show a Long History of Problems.)

These studies examined Federal Enterprise Architecture programs among a wide sample of federal

agencies, both at the department and sub-department levels. The studies measured EA program maturity

using a framework developed by GAO, the Enterprise Architecture Management Maturity Framework

(EAMMF).

Generally, the studies reported that EA at federal agencies was not progressing well, and included

summary statements like these:

2001: ―Agencies‘ use of enterprise architectures is a work in progress, with much left to be

accomplished‖

2003: ―Federal agencies‘ progress toward effective EA management is limited, with much work

remaining‖

2006: ―Enterprise architecture efforts can be viewed as a work in process with much to be

accomplished‖.

Although GAO accurately reported the ongoing problems with agency EA programs, what appears to

have gone largely unnoticed was not only that agency EA programs weren‘t advancing well, many were

actually backsliding into lower states of maturity!

Figure 2 graphically illustrates this backsliding. Instead of following a ―normal‖ maturity progression

(left-hand diagram), many federal agency programs were actually regressing, particularly into the lowest

maturity state (right-hand diagram). (The trend line shows the maturity trend for maturity stage 1.)


Figure 2: Many Federal EA Programs Regressed from 2001 to 2006

Next, Table 5 shows that agency maturity regression was frequent and sometimes larger than maturity

progression, while Table 6 shows that some agencies never progressed beyond maturity level 1 in the five

years between 2001 and 2006.

(It must also be noted, however, that the maturity levels displayed in the two tables, while useful for

illustrating the problems and lack of progress implementing EA, don‘t represent the whole story. In

particular, see pages 18-22 of the 2006 study, which explains that because each maturity level has

multiple elements that must be satisfied, the lack of a single element may prevent an agency from being

rated at a more representative level.)


Table 5: Federal Level: Maturity Regression of Three GAO Studies

Agency 2001 Study 2003 Study

(EAMMF v 1.0)

2003 Study (EAMMF

v 1.1)

2006 Study (Major Orgs.

Only)

Bureau of Alcohol, Tobacco, Firearms and Explosives (Treasury)

2 4 2

Bureau of the Census 2 3 3 –

Bureau of the Public Debt (Treasury) 3 1 1 –

Centers for Disease Control and Prevention (HHS)

3 2 1

Department of Education 2 2 – 1 1 –

Department of Energy 2 2 – 1 1 –

Department of Housing and Urban Development 1 3 3 – 3 –

Department of Justice 3 2 1 3

Department of State 3 2 2 – 1

Department of the Treasury 1 1 – 1 – 1 –

Environmental Protection Agency 3 2 1 1 –

Executive Office of the President 2 5

5 –

Federal Aviation Administration (Transportation) 3 2 1

Internal Revenue Service (Treasury) 4 5 3

Office of Personnel Management 4 5 1

2

U.S. Customs Service (Homeland Security) 5 ? ?

U.S. Patent and Trademark Office (Commerce) 4 2 2

Table 6: Federal Level: Agencies with No Maturity Progression, 2001-2006

Agency 2001 Study 2003 Study

(EAMMF v 1.0)

2003 Study (EAMMF

v 1.1)

2006 Study (Major Orgs.

Only)

Department of the Treasury 1 1 1 – Central Intelligence Agency 1 1 1 – Comptroller of the Currency (Treasury) 1 1 1 1

Economic Development Administration (Commerce)

1 1 1 –

Federal Bureau of Investigation (Justice) 1 1 1 – Federal Deposit Insurance Corporation 1 1 1 – Federal Energy Regulatory Commission 1 1 1 – Federal Highway Administration (Transportation)

1 1 1 –

Federal Reserve System 1 1 1 – Food and Drug Administration (HHS) 1 1 1 – National Credit Union Administration 1 1 1 – Risk Management Agency (Agriculture) 1 1 1 – U.S. Marshals Service (Justice) 1 1 1 –


EXHIBIT 4: PROBLEMS WITH THE FEDERAL EA PROGRAM

―Exhibit 3: Problems with EA at the Agency Level‖, examined the troubles with Enterprise Architecture

at the department / agency level. This Exhibit (4) will now examine the problems with EA at the federal

level.

BRIEF HISTORY OF EA IN THE FEDERAL GOVERNMENT

To understand where the federal EA program itself has fallen short, we first need to briefly review some

history of the federal government‘s Enterprise Architecture program and revisit the program‘s original

vision, goals, and definitions:

In October 1996, shortly after the passage of Clinger-Cohen, OMB issued a memorandum, ―Funding

Information Systems Investments‖, that for the first time established as official policy the need for

consistent architectures across the federal government:

Investments in major information systems proposed for funding in the President's budget

should … be consistent with Federal, Agency, and Bureau Information Technology

Architectures…9

In 1999 the Federal CIO Council issued the Federal Enterprise Architecture Framework (FEAF)

which introduced the concept of a common ―Federal Enterprise Architecture‖. The document‘s

vision statement included the notion of a federal-wide ―top-level enterprise architecture‖ where

federal agencies would share IT information:

The Federal CIO Council seeks to develop, maintain, and facilitate the implementation of the

top-level enterprise architecture for the Federal Enterprise. This architecture will serve as a

reference point to facilitate the efficient and effective coordination of common business

processes, information flows, systems, and investments among Federal Agencies. In time,

Government business processes and systems will operate seamlessly in an enterprise

architecture that provides models and standards that identify and define the information

services used throughout the Government.10

More important, but almost universally unnoticed, the FEAF itself was defined as an

integrated, federal-wide architecture repository which would collect and integrate EA data

from federal agencies:

A Federalwide collaboration tool is needed to collect common architecture information

and build a repository for storing this information. A Federal Enterprise Architecture

Framework is such a tool and repository. 11

[Emphasis added]

In 2001 the Federal CIO Council released the ―Practical Guide to Federal Enterprise Architecture‖ to

provide guidance on how to create, manage, and use enterprise architectures. Although it was almost

completely overlooked (or has long since been forgotten), the Practical Guide defined Enterprise

Architecture itself as “a strategic information asset base”12

, i.e. a repository. [emphasis added]


In 2003 the FEA PMO followed the precepts of the FEAF and Practical Guide by creating an

integrated repository. In a January 2003 briefing, the FEA PMO presented the Federal Enterprise

Architecture Management System (FEAMS) to federal agencies:

―The Federal Enterprise Architecture Management System (FEAMS) was created to allow

agencies to access the FEA to find opportunities for cross-agency collaboration and

government capabilities.‖13

So by 2003 the concept of a common, federal-level Enterprise Architecture had been formally established.

Additionally, the CIO Council, by the definitions it incorporated into the Federal Enterprise Architecture

Framework (itself defined as a federal-wide EA repository) and the Practical Guide (defining Enterprise

Architecture as a ―strategic information asset base‖) established both the need for, and the expectation of,

a federal Enterprise Architecture repository.

By definition, then, a populated federal EA repository that collects, integrates, and makes

available to federal agencies data about IT resources across the entire federal government was

intended to be the real foundation of the federal Enterprise Architecture. *

CREATION OF FEDERAL EA REPOSITORIES: MULTIPLE ATTEMPTS FALL SHORT

Unfortunately, although the CIO Council envisioned a federal-level EA repository and the FEA PMO

actually implemented one – FEAMS – it failed after a short time, leaving the federal EA program without

an essential component needed for its success. (Also see Appendix D: Why FEAMS Failed.)

Because it was supposed to serve as the foundation of the entire federal Enterprise Architecture, the

failure of the FEAMS system was hugely significant, but because of the confusion and misunderstandings

described in this paper, it seems that the consequences of its demise weren‘t – and still aren‘t – fully

understood.

But what also hasn‘t been understood is that FEAMS was actually just one of a series of related but

disjointed efforts to collect and integrate EA data at the federal level, and that all of these efforts focused

only on subsets of data that were originally supposed to have been (or should have been) included in the

FEAMS system. Furthermore, all of these efforts either provided little value or failed entirely, after

consuming years of effort and taxpayer dollars.

These related efforts are summarized in Table 7. Supplementary information on each effort is provided in

Appendix E: Related Attempts to Create Federal EA Repositories – Additional Information. This

appendix also includes a table that shows the EA data that was defined for each effort.

That these efforts were in fact all related is at least partially confirmed by the recent (2009) discovery by

the Object Management Group‘s Government Domain Task Force (GovDTF) that the Enterprise

Architecture Segment Report (EASR) and the Federal Transition Framework (FTF) had commonality

between them:

* Note that although the FEA PMO in more than one location declared that the BRM was the ―foundation of the

FEA‖, as discussed elsewhere in this paper the BRM is only a taxonomy that classifies investments or applications.

A federal EA repository is the only thing that can serve as the FEA‘s real foundation.


―The original intent was to produce a metamodel standard focused on the Enterprise Architecture

Segment Report (EASR) template, which had an existing data model. A team including the

original developers of the EASR, OMB representatives, and vendors was assembled to define the

metamodel, formally modeled using the UML as was done for the Federal Transition Framework.

While analyzing the supplied data model, it was determined that the scope of the metamodel

required expansion to address normalization with existing specifications, including the

OMG Metamodel for the Federal Transition Framework (FTF) and the OMB‘s FEA

Consolidated Reference Model and Exhibit 300.‖14

[Emphasis added]

Table 7: Multiple Attempts to Create Federal EA Repositories Repository Effort Start End Description Results

The Federal Enterprise Architecture Management System (FEAMS)

2004 2006

Broadest focus: “Federal EA repository” Never really used or outright rejected by agencies Right goal, terrible execution

Final status: failure

The Component Organization and Registration Environment (Core.gov)

2004 2006

2005 2010

Original purpose: Register software components 2006: Purpose changed: “Federal EA repository” 2005: System overhauled 2007: System purpose changed again 2007 – 2010: decline

Final status: failure

The Federal Transition Framework (FTF)

2007

Purpose/focus: EA data for Cross-Agency Initiatives Created under OMB’s Government Domain Task Force (GovDTF) Subset of what should have been developed

Little used Database no longer being updated

15

Final status: integration with other “EA data initiatives”?

Enterprise Architecture Segment Report (EASR)

2008

Purpose/focus: compliance reporting Subset of what should have been developed

Final status: integration with other “EA data initiatives”? Unlikely collected data was ever used

Federal Segment Architecture Methodology (FSAM)

2008

Purpose/focus: Process methodology Defined its own model, the “FSAM Data Model” Bloated, confusing, unnecessary methodology

Final status: integration with other “EA data initiatives”?

Recent modeling work under Object Management Group’s Government Domain Task Force (GovDTF)

2009

Purpose/focus: develop a model for EASR Expanded to include FTF, Exhibit 300, & FEA Taxonomies

Still under development


OMB COMPLIANCE / ASSESSMENT REPORTING: BURDENSOME, CONFUSED,

INEFFECTIVE

At least until very recently, federal agencies were required to submit two quarterly reports, the Enterprise

Architecture Assessment Framework (EAAF) report and the Enterprise Architecture Segment Report

(EASR), to OMB to report on the status of their respective Enterprise Architecture programs. (In August

2009, OMB informed agencies that they were not required to submit the EAAF for that quarter.16

Although no formal announcement has been made, it appears that the EAAF report is being

discontinued).

Although it is certainly arguable, a very strong case can be made that both reports were, despite the good

intentions of those who developed them, burdensome and ineffective. As will be discussed below, for

different reasons neither the EAAF nor the EASR provided valid or useful results.

Enterprise Architecture Assessment Framework (EAAF)

OMB rolled out the EAAF in April of 2004.17

Patterned after the Software Engineering Institute‘s

Capability Maturity Model, the EAAF was a complex, multi-dimensional report filled out by agencies

themselves as part of a quarterly self-assessment of their respective EA programs‘ maturity.

The EAAF‘s complexity made the report ambiguous and confusing, thus making it difficult for agencies

to complete and hard for OMB or others to assess the reliability of reported results.

The complexity also made it time-consuming to complete, and many agencies considered the time spent

pointless and burdensome. One agency estimated that ongoing compliance activities consumed about 5%

of all EA staff members‘ time, while each quarter required two people working two weeks to complete

and submit the report. 18

Finally, the EAAF‘s complexity, combined with the confusion and chaos described by this report, made it

easy for many agencies to game or ―short the report‖ (some consciously, most out of desperation) and to

indicate successes where there were none. In one egregious example, one department received a very

high rating based on their EAAF submission, yet had no EA repository. Despite the department‘s high

rating, GAO reported that the department ―Has yet to develop sufficient architectural context to guide and

manage modernization projects.‖19

There isn‘t much information available in the trade press or through federal sources that discusses the

usefulness or the reliability of the EAAF. However, two significant observations, if true, minimize the

need for this additional information.

First, it appears that OMB, even if it didn‘t recognize the report‘s poor reliability, at least recognized that

the report was indeed ―burdensome‖. A September 2009 OMB memo indicated that changes were being

made that would ―…reduce the reporting burden on agencies.‖ 20

Currently, agencies aren‘t required to

submit the EAAF report.

Second, and the smoking gun that should provide sufficient proof that the EAAF failed to provide valid

assessments of agency EA programs, is this paper.

If the findings in this paper are true, then the EAAF – which for years reported ―acceptable‖ results –

cannot possibly have been a valid instrument with which to measure EA maturity (or effectiveness) in

the federal government.



OMB released the EASR to federal agencies in December 2008. The report was to be submitted as part

of the quarterly OMB EA assessment process,21

along with the EAAF report.

But one significant difference between the EAAF and the EASR was that although both reports were

created for OMB compliance reporting, the EASR, unlike the EAAF, also collected EA data, specifically

―segment architecture data‖.

And it is this difference, combined with other characteristics of the EASR, which helps illuminate some

underlying confusion that was prevalent within the federal EA program at the time that the EASR was

released.

By 2008, the federal Enterprise Architecture had suffered serious setbacks. The Federal Enterprise

Architecture Management System (FEAMS) had failed, Core.gov was struggling (it would ultimately

fail). No federal-wide EA data had been collected to guide and integrate federal EA activity. In response

the Federal Transition Framework (another EA data collection/repository effort) had been launched, and

the FSAM (which also collected its own data) had been released

So by 2008, the efforts of the FEA PMO to create a federal Enterprise Architecture had fragmented and

activity had gone into different and sometimes overlapping directions. The EASR, Core.gov, the FTF,

and FSAM all collected EA data using separate data models. Some of the data overlapped. And the

EASR (along with the Exhibit 300) was also a data collection tool.

So the EASR was torn in two directions. Although it was ostensibly a compliance mechanism, it was also

a data collection tool and a ―repository‖ (of sorts), collecting some of the same data that was being

collected by the Exhibit 300, the Federal Transition Framework, and the FSAM.

Today, it appears that the inconsistencies and fragmentation of the EASR have finally been recognized by

the GovDTF, and that efforts to integrate the fragmented pieces of the FEA program may have begun.

The ultimate goal, of course, should be a fully integrated federal EA repository that integrates data in two

ways:

1. Integrates the existing fragmented pieces of the current FEA (EASR, FTF, Exhibits 53 and

300, etc)

2. Integrates Enterprise Architecture data from all federal agencies


EXHIBIT 5: GAO REPORTS ON FEDERAL EA SHOW A LONG HISTORY OF

PROBLEMS

Since 2001 the General Accountability Office (GAO) has performed many studies that examined the

status of Enterprise Architecture in the federal government.* Taken together, these studies illustrate a

long history of problems the federal government has had successfully applying EA. In particular, a set of

longitudinal studies showed long, erratic, and even regressive maturations over a 5-year period for many

federal EA programs.

Three studies, performed between 2001 and 2006, were detailed examinations of the maturity of Federal

Enterprise Architecture programs among a wide sample of federal agencies. The sample consisted of all

cabinet-level departments and agencies, major component agencies or bureaus within departments, and

other independent agencies.22

These three studies were done in 2001, 2003, and 2006, with survey

populations of 116, 93, and 28 federal agencies, respectively.

GAO also performed multiple other studies where the status of Enterprise Architecture was reviewed at

selected agencies (i.e. review of a specific agency‘s EA program), or that included discussion of EA

usage as it related to other reviews of IT investments or technology usage in general.

The results of these GAO studies are summarized in the next two sections.

A chronological listing of these studies is also provided in Table 8, ―Summary of GAO Enterprise

Architecture Reviews and Reports‖, beginning on page 33. For each report, conclusions or significant

findings are summarized.

Federalwide EA Surveys, 2001 - 2006

Four studies performed by GAO between 2001 and 2006 showed that progress at most agencies over this

five year period was limited and that most EA programs provided little benefit to the management of

agencies‘ IT resources. Following is a brief summarization highlighting some of GAO‘s major findings.

In the first study, conducted in 2001†, the GAO reported that the federal government‘s use of enterprise

architectures was ―…a work in progress, with much left to be accomplished‖. At that time, only 48

percent of studied agencies had put into place the most basic EA management practices – meaning that

more than half of the agencies had not met even this minimal expectation. But almost no agencies –

only 4 percent – had implemented the full range of EA management practices that GAO considered

necessary for an effective EA program.23

The report‘s official conclusion was that ―The current state of

the federal government‘s use of EAs is mixed, but overall it is not sufficiently mature to support well-

informed IT investment decision-making.‖24

By 2003, only about one quarter of agencies had improved their EA programs. Unfortunately, this was

offset by an almost equal number of agency programs that had regressed. The study compared the

* These studies are specific to ―Enterprise Architecture‖. They do not include several earlier studies that go back as

far as 1994, when GAO performed studies on (just) the use of ―architectures‖ at several federal agencies. (See page

7 of February 2002 GAO study Enterprise Architecture Use across the Federal Government Can Be Improved.) † It was not always easy to determine what to include under the banner ―FEA‖. Although the 2001 GAO study

predates the 2002 opening of OMB‘s EA PMO (which some consider the start of the FEA), it was included because

the concept of a Federal Enterprise Architecture goes back at least to September 1999 with the publication of the

CIO Council‘s Federal Enterprise Architecture Framework.


EA performance of 93 agencies between 2001 and 2003*; GAO found that only 20 had established at least

the foundation for effective EA management.25

GAO also reported that of the 93 agencies studied; only

22 had improved their EA performance while 47 showed no improvement during these three years.

Remarkably, the performance of 24 agencies – more than one quarter -- actually decreased. 26

The 2003 report specifically noted the lack of progress since 2001 and its conclusion echoed that of the

prior report: ―Federal agencies‘ progress toward effectively managing enterprise architectures is limited,

with much work remaining.‖27

This same theme was repeated in 2004 in a follow-up report to the 2003 study. The 2004 report restated

the findings from 2003, but with an added emphasis on, and in the context of, the nascent Federal

Enterprise Architecture program. GAO‘s findings for the FEA program were very similar to those for

enterprise architectures in general: ―OMB has made progress on the FEA, but it remains very much a

work in process and is still maturing.‖ 28

By 2006, a full ten years after the passage of Clinger-Cohen, things had hardly improved and enterprise

architecture in the federal government was still ―…a work in progress, with much left to be

accomplished‖. In the 2006 report, ―Leadership Remains Key to Establishing and Leveraging

Architectures for Organizational Transformation‖ (Aug. 2006), the GAO‘s findings were not

encouraging. Using their own five stage maturity framework for assessing and improving enterprise

architecture management, the GAO found that only 7 of 27 agencies surveyed had advanced beyond

the initial stage of maturity. Of these 7, only 4 had advanced to stage 3, and no agencies had advanced

beyond the 3rd

stage, to stages 4 or 5. 29

If we accept that GAO‘s Enterprise Architecture Management Maturity Framework (EAMMF) is a valid

measure of the status of agencies‘ EA programs†, then the maturity progression of enterprise architecture

in the federal government from 2001 to 2006 should have been alarming. Not only did the maturity of

enterprise architecture not significantly advance, in some very important ways it significantly stagnated

and even regressed.

When we examine GAO‘s results over time, it becomes clear that the EA maturity at federal agencies did

not mature as it should. The following diagrams visually show why.

* The 2003 study actually reviewed 96 agencies, but only compared the 2001 and 2003 performances for 93 agencies

that had submitted responses for both studies. † The EAMMF actually measures the management maturity of EA programs, but the underlying assumption must be

that higher levels of EA management will produce higher levels of EA results.


Figure 3: Normal vs. GAO EA Maturity Assessments

The diagram on the left shows a ―normal‖ maturity progression. First, over time we should see the counts

for maturity stages 1, 2, and 3 gradually decrease, and those for stages 4 and 5 gradually increase.

Second, the trend line shown, for maturity level 1, should have a downward slope, i.e. over time fewer

agencies in stage 1.

However, GAO‘s actual results, displayed in the right-most diagram, show nearly the opposite of what we

should see. First, while the counts for maturity stage 2 do show the expected decline, no other stages

follow the normal maturity progression. Stages 4 and 5 in particular do the opposite of what is desired:

instead of increasing, they both drop to zero (i.e. agencies that had previously been ranked as ―mature‖

regressing to lower states).

But the indicator that should have been most worrisome is the ―GAO‘s Actual‖ trend line for maturity

stage 1. After 5 years of EA work, there should have been no agencies ranked as stage 1 maturity.

Instead, we see that the number of agencies ―still in the starting gate‖ has actually increased over time.

This is particularly troubling when we recall that stage 1 maturity is ―No EA‖, as defined in the 2006

GAO report:

―At stage 1, either an organization does not have plans to develop and use architecture, or it has

plans that do not demonstrate an awareness of the value of having and using an architecture.

While stage 1 agencies may have initiated some enterprise architecture activity, these agencies‘

efforts are ad hoc and unstructured, lack institutional leadership and direction, and do not provide

the management foundation necessary for successful enterprise architecture development as

defined in stage 2.‖ 30

The regression of EA maturities should have been a red flag indicating that there were significant

underlying problems with the federal EA program. In particular, the backsliding from higher

levels of maturity to the first level – the “No EA” level – suggested that there were one or more

factors that allowed agencies to lose ground previously gained.


Agency Specific Surveys, 2001- 2010

Finally, over the past decade, GAO has reviewed EA at a number of agencies and has chastised many for

failures in their adoption or use of enterprise architecture. Detailed review of these findings is not

included in this paper, but these GAO reports are included in Table 8, ―Summary of GAO Enterprise

Architecture Reviews and Reports‖ below (Review Type = ―Agency Review‖). A brief examination of

the ―Report Title / Highlights‖ column provides some insight into the many problems and difficulties

found by GAO.


Table 8 Summary of GAO Enterprise Architecture Reviews and Reports

Year Month Review Type Report Title / Highlights

2002 Feb FEA Review Enterprise Architecture Use Across the Federal Government Can Be Improved. Report number GAO-02-6 “The state of the federal government’s use of enterprise architectures is a work in progress, with much left to be accomplished” “…the federal government as a whole has not reached a mature state of EA management.”

Mar FEA Review OMB Leadership Critical to Making Needed Enterprise Architecture and E–government Progress. (Testimony before Congress March 2002) GAO-02-389T

2003 Sep Agency Review FBI Needs an Enterprise Architecture to Guide Its Modernization Activities. GAO-03-959 FBI does not have an enterprise architecture, although it began efforts to develop one about 32 months ago The bureau has yet to advance beyond Stage 1, the beginning stage Must treat EA as an institutional management priority which the FBI has yet to do

Nov FEA Review Information Technology: Leadership Remains Key to Agencies Making Progress on Enterprise Architecture Efforts. Report number GAO-04-40 “Federal agencies’ progress toward effective EA management is limited, with much work remaining” “Agencies Are Making Limited Architecture Management Progress; Most Programs Remain Immature” “… limited executive understanding of enterprise architecture.. scarcity of skilled architecture staff” enterprise architectures are still maturing little change found in overall maturity between 2001 and 2003 Questions about definitions and meaning of the FEA still remain

Nov Agency Review Architecture Needed to Guide NASA’s Financial Management Modernization. GAO-04-43 NASA has yet to establish other key architecture management capabilities Integrated Financial Management Program Has Proceeded without an Enterprise Architecture NASA needs an effective enterprise architecture program

2004 Aug Agency Review Homeland Security: Efforts Under Way to Develop Enterprise Architecture, but Much Work Remains. GAO-04-777 DHS EA is missing key elements expected to be found in a well-defined architecture DHS does not yet have necessary [EA] to effectively guide and constrain transformation efforts OMB has yet to clearly define what it expects the relationship between agencies’ enterprise architectures and the FEA to be, including what it means by architectural alignment.



2005 Jul Agency Review DOD BUSINESS SYSTEMS MODERNIZATION - Long-standing Weaknesses in Enterprise Architecture Development Need to Be Addressed. GAO-05-702. DOD has yet to establish an effective governance structure for its architecture development, maintenance, and implementation efforts Prior Reviews of DOD’s Architecture Efforts Have Identified Many Weaknesses and Challenges In May 2004, we reported that after 3 years of effort and over $203 million in obligations, DOD had not made significant change in the content of the BEA or in its approach to investing billions of dollars annually in existing and new systems.

Sep Agency Review FBI Is Taking Steps to Develop an Enterprise Architecture, but Much Remains to Be Accomplished. GAO-05-363 The FBI is managing its EA program in accordance with many best practices, but it has yet to adopt others The bureau’s “as is” and “to be” architectures are not complete FBI top management has demonstrated commitment to the EA program [but] much remains to be accomplished before the EA program will be effective

Sep Agency Review Business Modernization: Some Progress Made Toward Implementing GAO Recommendations Related to NASA's Integrated Financial Management Program. GAO-05-799R. NASA has made limited progress in adopting other key architecture management best practices that we recommended [in prior review] NASA has not implemented other architecture management capabilities that our November 2003 report cited as essential

2006 Mar Agency Review Homeland Security: Progress Continues, but Challenges Remain on Department's Management of Information Technology. (Testimony Before Congressional Subcommittees, Randolph C. Hite, Director, Information Technology Architecture and Systems Issues.) Our analysis of version 2 of the department’s architecture indicates that DHS has made progress toward development of its architecture products

Aug FEA Review Leadership Remains Key to Establishing and Leveraging Architectures for Organizational Transformation. GAO-06-831 The state of the enterprise architecture programs is mixed, with several having very immature programs, several having more mature programs, and most being somewhere in between only 7 of 27 agencies surveyed had advanced beyond the initial stage of maturity no agencies had advanced beyond the 3

rd stage, to stages 4 or 5

2007 Apr Agency Review Strategy for Evolving DOD’s Business Enterprise Architecture Offers a Conceptual Approach, but Execution Details Are Needed. GAO-07-451 DOD is in the early, formative stage of federating its BEA, with much remaining to be decided and accomplished before it achieves its goals. … goals, concepts, and related activities; capabilities; products; and services …. have merit and hold promise, *but+ the strategy lacks sufficient specificity for it to be executed

May Agency Review Homeland Security: DHS Enterprise Architecture Continues to Evolve but Improvements Needed. GAO-07-564



2009 HUD Needs to Strengthen Its Capacity to Manage and Modernize Its Environment (GAO-09-675) HUD Has Yet to Develop Sufficient Architectural Context to Guide and Manage Modernization Projects *HUD’s+ EA Management Program Largely Satisfies Relevant Guidance


EXHIBIT 6: A CONFUSED UNDERSTANDING

―…I believe that failure is less frequently attributable to either insufficiency of means or

impatience of labor, than to a confused understanding of the thing actually to be done...‖

John Ruskin, The Seven Lamps of Architecture (1849)31

From the earliest days of the Federal Enterprise Architecture program there has been, to borrow the words

of 19th century art and architecture critic John Ruskin, ―a confused understanding of the thing actually to

be done‖.

There has been confusion about the program itself and about how different parts of the program relate and

work together. Even today, many practitioners don‘t understand the difference or fail to make a

distinction between the ―FEA reference models‖, ―FEAF‖, and ―FEA‖, and they often misuse and

interchange the terms.32

Few practitioners know exactly how the FEA reference models fit into and relate to the entire Federal

Enterprise Architecture. Some don‘t know that the reference models are not the same as the FEA.33

And

only a very few really understand what these reference ―models‖ actually are. (Hint: they‘re not

―models‖! See Appendix A: The FEA Reference ―Models‖ Aren‘t Models for an explanation why.)

Many practitioners don‘t know what the ―FEA Framework‖ is (or was), how it‘s supposed to be used, or

even whether its use is required or not. And there is confusion in the industry whether FEAF is still

operational. One reputable source, MITRE, stated in its 2004 ―Guide to the (Evolving) Enterprise

Architecture Body of Knowledge‖ document, that FEAF was no longer actively supported.34

By now

(2010) this is certainly the case, but no FEA documentation or guidance has ever made it clear and many

still think that OMB requires the use of the FEAF.

There is even confusion about the difference between Enterprise Architectures and ―frameworks‖ – many

think that they‘re the same thing. 35

No two agencies, or it seems any two practitioners, have the same understanding of even the most basic

EA concepts and terminology. It‘s so bad, as one writer quipped, that, ―If … one were to ask a dozen

different IT architects to define ‗architecture‘, they‘d probably wind up with at least two dozen different

definitions. …‖. 36

There is not a shared vision or even a common understanding about the Federal Enterprise

Architecture.

Even worse, the original intent of Enterprise Architecture, ―the thing actually to be done‖, has

become so garbled and confused that it is no longer understood!

THE CONFUSED UNDERSTANDING IS EASILY OBSERVABLE

Some may continue to deny that there‘s a problem, but the results of this confused understanding are

easily observable and are prevalent throughout the federal government. A few examples illustrate how

significant and widespread the confusion is:


A Chief Architect states that Enterprise Architecture is ―only about IT stewardship‖, even though

nothing in the literature supports the notion, and insists that the FEA isn‘t about ―collaboration‖

or ―integration‖ between federal agencies, even though source legislation and FEA guidance

documents repeatedly list both as key goals. * 37

; † 38

A discussion at an Enterprise Architecture user group meeting ponders whether a Current

Architecture is really needed, and some insist that a good strategy would skip the definition of a

Current Architecture altogether and define only a Target Architecture, ignoring OMB and FEA

definitions and guidance that has always included the Current Architecture as a necessary part of

EA.39

(How can one develop a transition plan to proceed from a current state to a future state

without knowing the current state starting point?)

A federal department develops its own ―Business Reference Model‖ based on its agency-specific

activities and functions, and then declares that this custom version, and not OMB‘s BRM, will be

the ―real‖ one. The agency also plans to make their custom BRM ―the foundation of the agency‘s

Enterprise Architecture‖, not realizing that the BRM is only a taxonomy that classifies things by

business activity, and can no better serve as an EA foundation than the data element ―Race‖ can

serve as ―the foundation for the 2010 Census‖.‡

§

An agency develops a complete set of home-grown reference models and plans to have OMB add

the custom, agency-specific classifications from their reference models to the OMB FEA

reference models. (Not realizing that the OMB Reference Models must only define

classifications that are meaningful across the entire federal government, and not just to a single

agency.)

An agency spends years developing its enterprise architecture and populating its EA repository,

abandons it all and starts an entirely new EA repository effort from scratch. A few agencies have

done similar restarts, often at the whim of new chief architects, some of whom have little

experience in EA or even in the field of information technology.

Discussions between FEA practitioners or explanations to managers about the purpose and use of

the FEA reference models are imprecise, confusing, meandering and full of meaningless jargon

that leave practitioners groping and managers glassy-eyed.

A question about an FEA diagram posted on an association forum results in three completely

different ideas about what the diagram represents. (See Appendix G: ―Diagram Confusion‖.)

Many trade articles, white papers and even formal EA documents produced by federal agencies –

Target Architectures, Transition Plans, etc. – do nothing more than parrot both the text and

diagrams found in the FEA documentation, revealing not a true understanding of ―the thing

actually to be done‖, but only propagating the same confusion to new audiences.

The DRM has metastasized far beyond what it should have been – a simple taxonomy to classify

agencies‘ data – into a confused, bloated, useless monster. Its creation was so confused that its

* OMB‘s FEA web site and other documentation identify ―Cross-Agency Collaboration‖ as a key area for

improvement and states that the Reference Models ―facilitate cross-agency analysis … and [provides] opportunities

for collaboration. See related endnote for URL reference. † ―Integration‖ is specifically included as one of the key goals of the President‘s E-Government strategy, and is one

of the key stated objectives for the FEA itself. See related endnote for specific example references. ‡ Both taxonomies may serve as a foundation for understanding an EA or understanding the gender distributions of

the American population, respectively, but they cannot be the foundation of either. § In fairness, it must be mentioned that OMB also said that the business reference model was ―the foundation of the

FEA‖.


―DRM Implementation Framework‖ was essentially nothing more than the document‘s table of

contents re-expressed as a two-dimensional matrix (i.e., a table)*. And even as the DRM was

repeatedly described as a taxonomy, no taxonomy was actually defined for it (unlike all four of

the other ―models‖).

Finally, the most significant and readily observable result (although it‘s often downplayed) is the number

of CIOs or other senior managers who, out of confusion and frustration that they haven‘t gotten results

from their EA programs for nearly a decade, are severely cutting back these programs or even

abandoning them, retaining only enough to satisfy OMB requirements.†

CONFUSION EVEN ABOUT THE DEFINITION “FEDERAL ENTERPRISE ARCHITECTURE”

―The definition of the term ‗federal enterprise architecture‘ will likely be controversial.‖

– Chairman of the Chief Architects Forum, 2005 40

This confused understanding was so pervasive and widespread that the Chairman of the Chief Architects

Forum knew that just getting the most basic term – ―Federal Enterprise Architecture‖ – defined would be

difficult!

The source of the problem was that many terms were never made completely clear and were often

inconsistent. Across the government, and even within the FEA PMO, definitions were inaccurate and

sometimes simply wrong. For example, Figure 4, below, shows that the FEA PMO incorrectly equated

the Federal Enterprise Architecture to the FEA Reference models.

As discussed in detail in ―Exhibit 2: The FEA Reference ―Models‖: Tragically Misnamed‖ and

―Appendix A: The FEA Reference ―Models‖ Aren‘t Models‖, the two are not the same.

Figure 4: FEA PMO Equated the FEA to the Reference Models

* See page 7 of the DRM document.

† From the conversations with other practitioners and the author‘s personal observations doing EA work at six

federal agencies, where 5 had drastically reduced or abandoned their EA programs and the 6th

had no EA repository


Following are some additional examples of inconsistent and even incorrect definitions found in FEA or

other federal sources:

FEA PMO: ―The FEA consists of a set of interrelated ―reference models…‖41

(The FEA is much

more than the reference ―models‖.)

GAO: ―The FEA is composed of five ‗reference models‘ …‖42

(The FEA is composed of many

other parts beyond the five reference ―models‘.)

FEA PMO: ―The Federal Enterprise Architecture (FEA) is a function-driven framework for

describing the business operations of the Federal Government independent of the Agencies that

perform them.‖ 43

(The FEA does much more than describe the federal government‘s business

operations. Plus, what exactly is a ―function-driven framework‖?)

GAO: ―According to OMB, the purpose of the FEA, among other things, is to provide a common

frame of reference or taxonomy for agencies‘ individual enterprise architecture efforts and their

planned and ongoing investment activities.‖44

(While this statement may strictly be true, it‘s so

vague as to be almost meaningless.)

THE GAO RAISED THE ISSUE BUT DIDN’T FOLLOW THROUGH

The problem of unclear definitions within the federal EA program was specifically raised by the GAO in

a 2004 GAO report to Congress, ―The Federal Enterprise Architecture and Agencies' Enterprise

Architectures Are Still Maturing‖. In this report, the GAO asked a surprising question:

―Should the FEA be described as enterprise architecture?‖ 45

By asking such a basic and fundamental question the GAO provided indisputable proof that that the

Federal Enterprise Architecture really was not understood. After all, could the Federal Enterprise

Architecture be anything but enterprise architecture?!!?

In this same report, GAO asked more questions that showed widespread confusion existed about many of

the FEA concepts and definitions:

―…OMB requires agencies to ―map‖ and ―align‖ their architectures with the FEA.

However, since these terms are not well-defined, GAO asks if the expected relationship

between the FEA and agencies‘ architectures is clear enough.‖ 46

[emphasis added]

―Is the expected relationship between agencies‘ enterprise architectures and the FEA clearly

articulated?‖47

―Such descriptions of the agency enterprise architecture/FEA relationship, in our view, are

not clear, in part because definitions of such key terms as alignment, mapping, and

consistency were not apparent in the FEA.

As with any endeavor, the more ambiguity and uncertainty there is with requirements and

expectations, the greater the use of assumptions and thus deviation from the intended course

of action. This is particularly true in the area of enterprise architecture.‖ 48

If the GAO had to ask questions like these, did the federal agencies who were trying to implement EA

know what the answers were? Enough to implement EA? Enough to make it produce results? Enough to


clearly explain it to executives and others stakeholders who were supposed to use and depend on the

finished result?

From the evidence presented throughout this report, the answer to the first three questions should be

certain and inarguable. The answer clearly is ‗no‘. There simply wasn‘t enough understanding about the

FEA to implement it or to make it produce sufficient results. The number of historical failures in the

federal EA program supports this answer.

The answer to the fourth question must also be ‗no‘. A 2002 GAO report concluded that the very

executives who were needed to champion agencies‘ EA programs often didn‘t understand EA enough to

provide support:

―Historically, agency executives have not fully understood the value of enterprise architectures;

… [they have] not understood the purpose, content, and value of these architectures, a

misunderstanding that in turn has not allowed these management tools to receive the executive

sponsorship they need to be treated as a funding priority and to overcome the embedded cultural

resistance to the non-parochial, entity wide approach that enterprise architectures promote. 49

In the 2003 report, the GAO said something that is as true today as it was some six years ago when it was

first asked:

―GAO supports the FEA as a framework for achieving these ends, but raises questions whose

answers are important to the its future.‖50

[Emphasis added]

Unfortunately, although the GAO raised significant questions that revealed widespread misunderstanding

about many parts of the federal Enterprise Architecture program, it failed to follow up to ensure that these

questions were satisfactorily answered.

These questions must be asked again and finally answered before the Federal Enterprise Architecture

program can be fixed.

THE GOVERNMENT RECOGNIZED THE PROBLEM BUT DIDN’T DIG DEEP ENOUGH TO FIX

IT

The lack of a common understanding about the FEA was noticed by federal officials, and some steps were

taken to address the problem, but ultimately these steps didn‘t solve the problem.

In 2004, Marion A. Royal, an Agency Expert in the General Services Administration‘s Office of

Governmentwide Policy, speaking about GSA‘s new Core.gov system, noted the confusion and

misunderstandings that were hampering the initiative to register and integrate software components:

―Many officials have been using confusing and contradictory definitions of components, and they

mix up technical and business process components‖. 51

In a September 2005 interview, Randy Hite, Director of Information Technology Architecture and

Systems Issues at the Government Accountability Office, noted that the problem was widespread and not

unique to the FEA:

―That's part of the whole problem with architecture — there are all kinds of terms thrown

around. There's no commonality of understanding and definition around things.‖ 52


The Chief Architects Forum also recognized this ―understanding gap‖, and in 2005 CAF began

development of a Federal Enterprise Architecture Glossary of Terms to develop a uniform understanding

of commonly used terms among government architecture practitioners and to ―…establish a common

understanding with OMB and other agencies regarding EA information‖ .53

* [Emphasis added]

CAF‘s chairman, Ira Grossman, summarized the reason behind the effort: ―We‘ve got to be talking the

same language; by that I mean have the same vision.‖54

The FEA Program Management Office also

identified the creation of an FEA glossary as a strategic initiative in its 2005-2006 Action Plan. 55

The FEA Glossary of Terms was developed and was put on a website that is still in existence

(http://colab.cim3.net/cgi-bin/wiki.pl?Enterprise_Architecture_Glossary_Of_Terms). Unfortunately, it

failed to fix the problem.

The reason, as will be shown later, is that the government didn‘t dig deep enough to get to the root of the

problem, to examine ―the very way that we have been seeing the tree‖.

Even today, there steadfastly remains a confused understanding about ―the thing actually to be done‖.

* To the author‘s knowledge, CAF was the organization that initiated the glossary initiative, but FEAPMO, the CIO

Council‘s AIC and the Industry Advisory Council also made contributions to the effort.

http://colab.cim3.net/cgi-bin/wiki.pl?Enterprise_Architecture_Glossary_Of_Terms


EXHIBIT 7: CONFUSING / MISLEADING / INCORRECT FEA DIAGRAMS

Exhibit 6 presented evidence that there is a widespread confused understanding across the federal EA

program and that, while much of this confusion is caused by ambiguous and even incorrect terminology,

the problem goes much deeper than ―definitions‖.

The problem really is in the very way that we have understood Enterprise Architecture – or to be more

precise, in the way that we have misunderstood Enterprise Architecture.

Exhibit 6 provided examples of bad definitions and terminology to demonstrate the confused

understanding. This Exhibit (7) will provide examples of diagrams that were created to illustrate concepts

of the FEA program, but instead visually revealed many of the problems described by this paper.

Because these diagrams have been copied and used in many documents beyond the ones they first

appeared in, the original errors and misunderstandings have propagated far beyond their original sources,

even to areas outside the realm of Federal Enterprise Architecture. For example, any document that uses

FEA diagrams of the Reference Models is almost certain to be inaccurate because of the misconceptions

surrounding the Reference Models.

THE MAIN “FEDERAL EA” DIAGRAM: INCORRECT IN MANY WAYS

The diagram shown in Figure 5, first introduced in 200356

, has been reused in many different FEA

guidance documents. It is for both these reasons (early use in FEA program and reuse in multiple

documents) that this diagram is significant and is selected first for discussion.

Figure 5: The Main “Federal EA” Diagram: Incorrect in Many Ways

The diagram is labeled ―Federal Enterprise Architecture (FEA)‖, but the diagram misrepresents the FEA

in several ways:

1. By far, the biggest error is that the diagram depicts the Reference Models as equivalent to the

Federal Enterprise Architecture, but the FEA is much more than just the Reference Models.

(This main error is also discussed in other sections of this report.)

2. The direction of the arrow labeled ―Business-Driven Approach‖ and its proximity to the

Reference Models hierarchy implies that the FEA is ―driven‖ starting with the Performance


Reference Model and ending with the Technical Reference Model. While some may attempt

to rationalize this linkage (it‘s been done – see Appendix G: ―Diagram Confusion‖ for an

example), the rationalizations will conflict and will suffer from the same vagaries as the

original FEA definitions.

And while the use of a Business-Driven Approach for developing and modernizing the

government‘s information systems is certainly sensible, it has little to do with the focal point of

this diagram, the Reference Models.

3. Similarly, the box labeled ―Component-Based Architecture‖ has little to do with the main

focus of the diagram and only distracts from it. One may ask why Component-Based

Architecture was selected over other, more important parts of the FEA, for example, the

FEAF – wasn‘t the FEAF (at least when this diagram was created) a more important and

comprehensive part of the FEA?

4. The five-level hierarchy that represents the Reference Models doesn‘t accurately portray the

relationships between the five ―models‖:

a. First, the Business Reference Model is shown at the second level from the top. But in

many documents the FEA PMO described the BRM as ―the foundation of the FEA‖. If

this were the case, shouldn‘t the BRM be either at the top (depicting it as the

superordinate, ―driving‖ entry), or alternatively at the bottom (depicting it visually as a

true foundation for the other models)?

b. From a data modeling perspective, if any relationships were to be visualized between the

taxonomies, it should have looked like this:

Figure 6: Corrected Reference Models Hierarchy

The PRM‘s ―Measurement Categories‖ and ―Measurement Groupings‖ are

classified by the BRM‘s Lines of Business categories and Sub-Functions

categories, respectively, so the PRM is directly associated to the BRM.

Version 1 of the DRM was similarly associated to the BRM, but this linkage

was almost entirely removed in version 2.

The SRM isn‘t directly associated to the BRM. It used to be indirectly

associated via the SRM data entered into the 300 for investments, where each

investment had BRM values entered for it. But with the EA data being

removed from the 300, even this indirect linkage will have been eliminated.

The TRM was directly associated to the SRM, via TRM data entered for each

SRM entry in the Exhibit 300.


DIAGRAM REVEALS CONFUSION OVER ROLES OF REFERENCE MODELS, FEAMS, AND

AGENCY EAS

The beginning of Exhibit 6: A Confused Understanding discussed the widespread confusion that exists

even about the most basic parts of the federal Enterprise Architecture, including the FEA itself, the

Reference Models, FEAF, FEAMS, and the relationships between them.

Figure 7, below, graphically both illustrates this problem and compounds it.

First, the diagram represents the FEA reference models as entities, or ―things‖, that autonomously exist in

their own right, not dependent on anything else for their existence. As discussed in ―Exhibit 2: The FEA

Reference ―Models‖: Tragically Misnamed‖, and ―Appendix A: The FEA Reference ―Models‖ Aren‘t

Models‖ this representation is incorrect.

The visualization is misleading because it makes it appear (among other possibilities) that two ―data

sources‖ – the Reference Models and the Agency EAs – are ―converging‖ over time, making ―increased

data available in FEAMS‖ (bottom of diagram), and finally arriving at the main goal, a ―Federal

Enterprise Architecture‖.

But this scenario couldn‘t possibly have happened because the reference models aren‘t a separate data

source; they only exist as attributes of other data objects like Investments, Hardware/Software Products,

or Performance Measures. The values represented by the ―FEA reference models‖ box would have

automatically been included as part of the ―Agency EAs‖, simply by entering classification values for the

respective EA objects. In other words, the FEA reference models didn‘t have to be represented on this

diagram at all!

Second, the diagram fails to effectively show how the Agency EAs would have converged to populate the

top-most Federal Enterprise Architecture. And it is the convergence (or integration) of the agencies‘ EA

data into a federal-wide repository that is the real goal of the federal EA. This should have been

represented by the diagram as the real goal of the process – but the diagram fails to show this.

Figure 7: Diagram Reveals Confusion Over Reference Models, FEAMS, Agency EAs57


THE REFERENCE MODELS ARE OFTEN MISCHARACTERIZED IN DIAGRAMS

Because the FEA reference models are so thoroughly misunderstood, they are often mischaracterized in

diagrams that are found in FEA guidance documents and even in other non-FEA documents.

Figure 8 is an example of how the Reference Models are often mischaracterized in diagrams, both within

the FEA and – more importantly, as we will see in a moment – outside of the FEA.

Figure 8: Mischaracterization of Reference Models

This particular diagram was taken from the FEA Practice Guidance document.58

It was introduced with

this sentence: ―Enterprise assets including systems and IT investments are mapped to the agency-level

reference models to create a segment-oriented view of the enterprise.‖

This sentence and the associated diagram mischaracterize the Reference Models and are yet another

example of the confusion and misunderstandings that permeate the FEA. The diagram is wrong because

it represents a situation that can‘t exist. Examining the diagram from left to right, here‘s why:

1. First, the Reference Models don‘t apply to the enterprise assets ―Processes‖, ―Information‖,

―Personnel‖, ―Organizations‖, and ―Facilities‖ because the Reference Models don‘t classify

these specific assets. (See Table 13 on page 77 to see which enterprise assets the Reference

Models are applicable to.) If we are to include these five enterprise assets in a segment-

oriented view of the enterprise, another method besides the Reference Models must be used.

2. ―Mapping‖ (i.e. classifying) to the agency-level Reference Models does not create a segment-

oriented view of the enterprise because this mapping has nothing to do with Segments. The

FEA reference models only classify certain enterprise assets according to the reference

models‘ underlying taxonomies, they don‘t help define segments.

3. Any enterprise assets can be classified by segments (including those not classified by the

FEA Reference Taxonomies), but this is a separate classification from that of the Reference

Models – it‘s simply an association (a link) between the enterprise assets and segments.

4. So the main problem with the diagram is that it confuses two classification schemes – that for

the FEA reference models and the separate one for Segments/Segment Types. If the aim was

to create a segment-oriented view of the enterprise (i.e. classify enterprise assets by

segment/segment type), Figure 9 is the diagram that should have been created.


Figure 9: What Should Have Been Diagrammed

Figure 10, below, is another example showing the mischaracterization of the reference models in

diagrams. This diagram, found in the FEA‘s Records Management Profile, ostensibly shows a layer-by-

layer relationship between the reference models and ―Record Management (RM) Resources‖. But even a

cursory examination of the diagram shows that the diagram just doesn‘t make sense.

For example, although both RM‘s ―DoD 5015.2 Metadata Profile‖ and FEA‘s Data Reference Model both

have ―something to do with metadata‖, this metadata-based-relationship is (1) tenuous at best, and (2) is

based on two different kinds of ―metadata‖. (See Appendix B: It‘s Not Metadata for more information.)

As another example, the relationships at the first layer (―OMB, ISO, NARA Guidance‖ / ―Business

Reference Model‖) seem to be, if not completely bogus, then at least quite a stretch. The only ―real‖

relationship seems to be that the ―records management‖ function is classified according to the BRM as

―Support Delivery of Services Business Area / General Government Line of Business / Central Records

and Statistics Management‖ (see page 14). The rest of the relationship, covered on pages 15 to 18 seems

to be banging the square peg of RM guidance into the round hole of the BRM.

The diagram, far from showing a meaningful relationship between ―Records Management‖ and the

federal Enterprise Architecture, is instead just another visual example of the widespread

misunderstandings and misconceptions of the federal EA program.

Figure 10: Records Management and FEA Reference Models 59


THE FEAC GRAPHICAL GUIDE: THE CONFUSED UNDERSTANDING, VISUALLY

DEPICTED?

Figure 11 was found on the Federal Enterprise Architecture Certification Institute‘s web site. The

diagram is labeled ―A Graphical Guide to the U.S. Federal Enterprise Architecture and its Components

Relationships‖.

The FEAC‘s intention when it created this slide certainly must have been to provide what they thought

would be an impressive high-level view of the Federal Enterprise Architecture by using the many

diagrams created for the FEA over the years.

Instead the FEAC unwittingly created a diagram that, far from serving as a ―graphical guide‖, seems to

operate more as a visual metaphor for the confused understanding of the Federal Enterprise Architecture

program, a confusion that increased over time as more misleading and even completely erroneous

diagrams were created over time.

Can the diagram below possibly serve as a ―graphical guide‖? Is the diagram actually useful?

Figure 11: FEAC’s “Graphical Guide” Diagram 60


THE RESULTS

Note: For the reader to understand the observations and conclusions of this section, it is

strongly recommended that the first section, “The Evidence”, be read first.

―The Evidence‖ section reviewed the evidence that is (or should be) sufficient to prove beyond doubt that

the Federal Enterprise Architecture isn‘t working.

The confusion and misunderstanding about Enterprise Architecture generally, and the related missteps

and failures within the Federal Enterprise Architecture program have left in their wake a string of

shortcomings and failures that must be corrected before Enterprise Architecture can be made a useful tool

for the federal government.

This section briefly summarizes these results. Where applicable, specific references to the evidence

presented in The Evidence section are provided.

NO FEDERAL ENTERPRISE ARCHITECTURE

The most significant and all-encompassing result of the problems described in this paper is that the FEA

program never achieved the original and most important goal it set for itself: creation of a true federal-

wide Enterprise Architecture, primarily expressed as an integrated EA repository.

As discussed Exhibit 4: Problems with the Federal EA Program‖, a populated federal EA repository must

form the foundation of a federal-wide Enterprise Architecture.

NO COMMON AND SHARED UNDERSTANDING

There is no common and shared understanding that must exist among all stakeholders (OMB, federal

agencies, practitioners, and EA tools vendors) for there to be the kind of common mindset that is

necessary for any large, complex undertaking.

See ―Exhibit 6: A Confused Understanding‖ for related analysis.

FEA DIDN’T FOLLOW ITS OWN ADVICE AND DIRECTION

It‘s ironic (and should be at least a bit embarrassing) that even while the Federal Enterprise Architecture

program called for federal agencies to eliminate redundancy, share IT resources, adopt common processes

and databases, and integrate processing functions across agencies, it failed to do this for Federal

Enterprise Architecture itself.

Instead, except for compliance reporting, federal agencies‘ EA programs have generally operated

autonomously with no common or standard EA resources, processes, or databases shared among them.

There is almost no commonality in EA within the federal government, because the FEA PMO hasn‘t

specified common EA standards and resources for federal agencies to use.

The result is that the federal EA program itself suffers extensively from exactly what EA was created to

eliminate in other areas: redundancy, duplication of effort, and wasted taxpayer dollars. And nearly

everywhere, there are EA stovepipes and silos…. quite an irony, if you think about it!


Almost all EA programs have created two types of EA silos:

Vertical EA silos. Very few (if any) departments or agencies have vertically integrated EAs. EA

work is usually done at the sub-enterprise level and data isn‘t consolidated to the top-most,

enterprise level. This creates vertical EA silos within agencies, where the EA data that is

necessary to populate a true enterprise architecture repository (e.g. for an entire department)

remains locked in lower-level repositories. These vertical EA silos would also prevent a federal-

level EA repository (if one existed) from being fully populated.

Horizontal EA silos. Most lower-level agencies or bureaus run their own EA programs, usually

employing different EA tools and defining and populating dissimilar EA data into their

repositories. This creates horizontal EA silos within agencies, where EA data can‘t be exchanged

or compared even at the same organizational level because the data and tools are incompatible.

These horizontal EA silos also prevent departments or agencies at the same federal level from

comparing EA data – a key objective of the FEA.

It shouldn‘t have been this way. If OMB had correctly defined and communicated a common EA

repository data model to be shared and used by all federal agencies, data could have been consolidated

from the lowest to the highest levels of the government (thus eliminating the vertical EA silos) and could

have been shared or exchanged between any agencies at any level (thus eliminating the horizontal EA

silos).

This is why abandoning FEAMS was a hugely significant error for the federal EA program, and why the

creation of a common, federal level EA repository must be made a highest priority objective if the entire

program is to be salvaged.

See ―Creation of Federal EA Repositories: Multiple Attempts Fall Short‖ and ―Appendix D: Why

FEAMS Failed‖ for related analysis.

COMPLIANCE ACTIVITIES WERE FUTILE TIME WASTERS

For several years, agencies were required to prepare and submit two reports to OMB each quarter.

Collecting the information, preparing the reports, and submitting the EAAF and EASR to OMB were time

consuming activities and mostly a huge waste of time.

Based on the evidence already presented in this paper, neither of these compliance mechanisms was

effective because neither managed to detect the lack of maturity progression or the many failures of

agencies‘ EA programs.

See section ―OMB Compliance / Assessment Reporting: Burdensome, Confused‖ for related analysis.

FSAM: A BLOATED METHODOLOGY THAT PRODUCES LITTLE BUT

CONFUSION

Recently a major federal department hired Gartner, Inc. to create a transition strategy and develop a

comprehensive plan for a major, complex modernization initiative. Gartner met with stakeholders,

performed analysis and delivered a full transition strategy and a multi-year plan for this complex project

in about two months.


Gartner did all this without once using the term ―segment architecture‖ and without using the Federal

Segment Architecture Methodology.

Why is this significant? Because it is but one case that illustrates that the Federal Segment Architecture

Methodology isn‘t needed to analyze complex modernization requirements and to create transition

strategies and plans for these initiatives.

In fact, based both on personal observation and discussions with many other federal EA practitioners, far

from helping agencies analyze and develop modernization plans, the FSAM does the exact opposite: it

instead confuses and hinders the process. In short, the FSAM is (arguably, of course), an unneeded,

bloated methodology that usually produces little but confusion.

Why? To start, ―Segment Architecture‖ itself is a confusing and misleading term (one of many thrown

about in the field of Enterprise Architecture) that only obscures ―the thing actually to be done‖.

The only people who can possibly really understand what a Segment Architecture is are the EA

practitioners themselves – but all too often, many of these practitioners don‘t even understand it! (Which

begs the question: ―How could the business people who the enterprise architects were supposed to guide

through the Segment Architecture methodology possibly have understood it if many of the guides didn‘t

understand it themselves?‖ Usually the answer was ―They didn‘t.‖)

Is Segment Architecture a process, a ―thing‖, a strategy? Is it even ―architecture‖? It‘s never been made

uniformly clear.

In the old days (i.e. before Enterprise Architecture) a much simpler, more intuitive, and better understood

term was used: ―functional area‖. A segment is really just a functional area – that is, a part – of an

organization‘s entire business and IT environment that can be analyzed and modernized as a quasi-

independent part of the larger whole. And with one exception a ―segment‖ has nothing to do with

―architecture‖. (The exception is when actual design* work is done, i.e. ―How do we arrange the parts?‖)

But back to the methodology itself. How do we know that the FSAM is an unnecessary and ineffective

methodology? We could painstakingly deconstruct the entire methodology and describe in detail each

problem and weakness. (And there are many.)

In fact, this was the approach that was started for this paper. But it turns out that a full deconstruction

isn‘t needed (and would be argued ad infinitum, anyway). There are a few much faster ways to establish

that the FSAM is both unnecessary and ineffective:

First, the example given at the start of this chapter shows that FSAM isn‘t needed to perform

a good functional area analysis, even for large and complex areas. In fact, Gartner didn‘t use

any specific formal methodology to guide its work… only orderly thinking and common

sense.

Second, ask the EA practitioners themselves. No doubt some will sing FSAM‘s praises, but

many others regard it as a huge and thoroughly confusing methodology, with a size and

complexity that defies meaningful use. In one particular case observed by the author, a

Segment Architecture process went on for ten months and was ultimately abandoned, having

never produced anything usable.

* Architecture is mostly closely associated with design. See section ―Failure to Distinguish Between What is and

What ISN‘T ―Architecture‖.


Next, ask the business users who have participated as members of an FSAM ―core team‖.

Many participate without public complaint but in private conversation often ask ―Why are we

doing this?‖ or grumble about what a complete waste of time the whole effort is. (Doubters

should ask their FSAM team members for their honest thoughts.)

Finally, the FSAM was based and built using many of the misunderstandings and

misconceptions described by this paper; therefore it was built on an unstable foundation:

- One example – the baffling term Segment Architecture itself – has already been

given.

- Another example was the implicit assumption that ―Segment Architecture is

complicated‖, so the methodology also needed to be complicated (and therefore

large). Ironically, sometimes the methodology itself was much larger and

complicated than the functional area being examined.

- But the biggest misconception that the FSAM embraced – and used as its very

foundation – was the underlying assumption that ―Segment Architecture‖ was

―different‖ and that it required its own custom methodology. The Gartner example

proves that this isn‘t so.

When we understand that a Segment is nothing more that a ―functional area‖, we can ask ―Why is any

special methodology needed at all? After all, the industry had been performing functional area analyses

for decades. Was a new methodology really necessary? A review of the literature doesn‘t show that

specific reasons were ever given why a custom methodology was needed.

As a personal observation only, it seems clear that FSAM was itself a product of the confusion and

misunderstanding described in this paper. Where only orderly thinking and common sense was needed,

the confusion and misunderstanding of EA ruled the day.

EA DOESN’T FACILITATE, IT IMPEDES NORMAL IT ACTIVITIES

Enterprise Architecture has required much of those it intended to help.

Data calls. EA planning. Compliance. Segment Architecture development. FSAM. EA meetings. The

Exhibit 300. Confusing ―alignment‖ of EA data in the Exhibit. Performance measures. Investment data.

What have these customers of, and contributors to, EA programs received for their efforts?

Unfortunately, not much.

Far from facilitating normal IT activities, it should now be clear that Enterprise Architecture has instead

hindered these activities. EA programs have consumed the time and energy of IT managers, business

case developers, end users, and technical staff, but have returned very little benefit for this investment of

time and energy (and money).

The question must be asked: Has EA facilitated IT activities or has it ―generally just gotten in the way‖?

It would be revealing to ask this question not only to agency EA staffs, but more importantly to the

consumers of Enterprise Architecture.


But even if not actually asked, the answer can be extrapolated by counting the number of CIOs or other

senior managers who are cutting back or quietly closing their EA programs.

It‘s more than a few.

WASTED TAXPAYER DOLLARS

―Look at all the efforts that have been launched under the idea of architecture and all the money that has

been spent under the umbrella of architecture that has all resulted in unusable shelfware.‖61

– Paul Brubaker, co- author of the Clinger-Cohen Act, 2005

Literally more than a billion dollars have been spent so far on Enterprise Architecture by the

federal government, and much, if not most of it has been wasted.

That‘s not a typo in the previous sentence: that‘s a ―B‖, billion, taxpayer dollars that have been spent to

date.

If that doesn‘t seem possible, the number is based on a 2006 calculation (some four years ago) made by

the GAO. In a 2006 study of federal EA programs, the GAO reported that ―Departments and agencies …

have collectively invested a total of $836 million to date on enterprise architecture development.‖62

This

amount is only that spent by agencies, and doesn‘t include costs incurred by OMB or the FEA PMO. If

we add those costs and the additional agency costs from 2006 to 2010, it easily comes to more than a

billion dollars.

Unfortunately, for this huge expenditure, much of the EA work at federal agencies failed to produce

anything of value for the agencies. And many of the activities of the FEA PMO failed to produce value

for the federal program as a whole.

Most important, for this huge sum the federal EA program never achieved most of its goals. And it never

created what was most needed for the entire FEA program to succeed: a federal-level EA repository. It

was this goal that would have allowed agencies to identify opportunities to collaborate, consolidate, and

leverage IT investments.

See ―Exhibit 3: Problems with EA at the Agency Level‖ and ―Exhibit 4: Problems with the Federal EA

Program‖ for related analysis.

THE PROBLEMS PROPAGATE BEYOND THE FEDERAL EA PROGRAM

It is certainly bad enough that the federal Enterprise Architecture program has suffered from so many

problems and has failed to provide significant value or achieve the expected results for the federal

government.

But these problems don‘t affect only the federal EA program or the agencies that are trying to implement

EA. Unfortunately, the misunderstandings and misconceptions of the federal EA program go beyond the

realm of ―federal Enterprise Architecture‖ and have propagated to other areas.

Specifically, other federal programs and activities have adopted concepts and definitions from the federal

Enterprise Architecture, and because this paper has shown that these original FEA concepts were flawed,

it‘s reasonable to assume that these flaws have been propagated to the new programs and activities.


A very significant example is that of the Information Sharing Environment Profile and Architecture

Implementation Strategy that was first released in May of 2008 and updated in 2009.

The federal Information Sharing Environment (ISE) was required as part of the Intelligence Reform and

Terrorism Prevention Act (IRTPA) of 2004 ―… for the sharing of terrorism information in a manner

consistent with national security and with applicable legal standards relating to privacy and civil

liberties.‖ 63

Development of the ISE is a responsibility of the Director of National Intelligence, and its development is

a critical piece of the federal government‘s anti-terrorism strategy. As such, it‘s important that the ISE is

built on a stable foundation based on solid concepts, precise and understandable terminology, and a

common and shared understanding of ―the thing actually to be done‖.

Unfortunately, this is not likely the case. Although the actual results of the ISE program are outside the

scope of this report, it is reasonable to assume that if the ISE has adopted for use many of the same flawed

concepts and definitions that were defined by the FEA, then it is very likely that the ISE effort will suffer

from many of the same problems that have plagued the FEA program for nearly a decade.

The ISE is far too important for national security to be allowed to produce the same limited

results as the federal Enterprise Architecture program.

To prevent this, and based on the observations and conclusions of this report, the ISE and any other

federal program, activity, or report that has adopted or made reference to FEA concepts and definitions

should be re-evaluated with the findings of this report in mind. In particular, any reference to, or use of,

the FEA reference models – especially the Data Reference Model – is probably in error and needs to be

corrected. (But also see last row of Table 9; it appears that at least for the DRM, this recognition may

already have been made.)

Table 9, ―FEA Concepts Adopted by the Information Sharing Environment‖ lists the main concepts that

the ISE adopted from the FEA that likely should be reexamined using the recommendations of this report.

Table 9: FEA Concepts Adopted by the Information Sharing Environment FEA Concept Page Related Analyses

Federal Enterprise Architecture (FEA) Framework ISE Enterprise Architecture Framework

vii (No related analysis)

FEA reference models 1

Exhibit 2: The FEA Reference “Models”: Tragically Misnamed and Appendix A: The FEA Reference “Models” Aren’t Models

Federal Transition Framework Vii, C-1

Appendix E: Related Attempts to Create Federal EA Repositories – Additional Information

Segment Architecture Federal Segment Architecture Methodology

1 15

FSAM: A Bloated Methodology That Produces Little but Confusion

Data Reference Model N/A

Note that the Data Reference Model was part of version 1 of the ISE in May 2008, but by June 2009 it was dropped from version 2 of the ISE.

64


THE CAUSES

―The Evidence‖ section provided evidence that is (or should be) sufficient to prove beyond doubt that the

Federal Enterprise Architecture isn‘t working and discussed the widespread confusion and

misunderstandings about EA. ―The Results‖ section then summarized the results that these many

problems have had on the federal EA program.

This section proposes and discusses what are believed to be the main causes of all of these problems.

THREE KEY DEFICIENCIES

It is proposed that the underlying source of all of the federal EA program‘s shortcomings and failures can

ultimately be traced to a single key deficiency and two consequent deficiencies that were both triggered

and exacerbated by the first one. These three key deficiencies are:

1. Poor use of terminology. The FEA has repeatedly used words outside of their commonly held

meanings, resulting in confusion about some of the most fundamental concepts and ideas about

Enterprise Architecture and about the entire federal EA program.

2. Failure to develop a common and shared understanding. The inevitable result of poor

terminology and imprecise word usage is that it prevented the development of a common and

shared understanding that‘s necessary for a large and complex undertaking like Enterprise

Architecture.

3. Failure to distinguish between what is and isn‘t ―architecture‖. Even the term architecture is the

wrong term to use for most of what the FEA is actually trying to accomplish. Largely as a result

of its misuse, the FEA never made a clear distinction between enterprise and technical

―architectures‖ (the first is not really an architecture).

THE PROBLEMS STARTED HERE: POOR USE OF TERMINOLOGY

In their book ―The Software Architect‘s Profession‖, Marc and Laura Sewell pointed out that in the IT

industry, words and terminology are too often misused:

―Words should have clear meanings but, unfortunately, in the field of information technology,

words, titles, and roles are muddled and confused. Anyone can call himself or herself an

architect, ‗blueprints‘ detail processes and activities rather than a design, and other common

words have multiple meanings. It is ironic that this is the case in a field where precision would

be expected as a dominant character trait, but it has become common for software professionals

to bandy about words such as ‗architect‘,‘ designer‘, ‗architectures‘, ‗styles‘, and ‗models‘

without using their commonly held meanings.‖ 65

Although they were speaking generally, the Sewells have, in a single paragraph, identified the

single, fundamental deficiency that underlies nearly all of the failures that plague federal Enterprise

Architecture: the poor use of terminology.


And even though they weren‘t talking specifically about Enterprise Architecture, the Sewell‘s observation

unintentionally points out so many fallacies about EA that they very well could have been! For example:

―Anyone can call himself or herself an architect‖ (And too many in the IT field have done so,

without the requisite qualifications.)

―…‗blueprints‘ detail processes and activities rather than a design…‖ (A blueprint for a

building is the representation of a design, not a process, but the FEA, including the FSAM,

defines or thinks of a blueprint as a process.66

)

―… it has become common for software professionals to bandy about words such as

‗architect‘,‘ designer‘, ‗architectures‘, ‗styles‘, and ‗models‘ without using their commonly

held meanings.‖ (Except for the term ‗styles‘, all of these words have been mangled and

misrepresented in the field of Enterprise Architecture.)

Both the federal EA program and the wider EA discipline offer many other examples of poorly-chosen or

completely incorrect words that have been used to describe the concepts and components of Enterprise

Architecture, but that have instead only managed to baffle users and prevent a real understanding of EA.

Here‘s a short list of some of the worst offenders:

FEA Reference Models: The selection of the word ―model‖ to name what is really a set of

taxonomies is one of the best examples of the muddled and confused use of words raised by

the Sewells in this section‘s opening epigraph. These reference ―models‖ are discussed at

length elsewhere in this document, but this error is so egregious it bears repeating and

inclusion at the top of this list.

Performance Architecture: What, exactly, is a ―Performance Architecture‖? This is a

nonsense term that should have been recognized as a warning indicator that the word

―architecture‖ was being misused. (Some may try to rationalize the term, but once it‘s

understood what ―architecture‖ really is, it becomes clear that it really has nothing to do with

performance.)

Architectural change driver: What is an architectural change driver? Why not just ―change

driver‖? (Or maybe even ―factor‖?) Adding ―architectural‖ only serves to mystify what is

being discussed. Would a building architect talk about ―architectural change drivers‖? If so,

what would those be, exactly?

Segment Architecture: A completely baffling misnomer that only obscures what‘s really

being communicated. A far more commonsense term that has been used in IT for decades is

―functional area‖. (Also see ―FSAM: A Bloated Methodology That Produces Little but

Confusion‖ for a more detailed examination.)

But the single worst offender, the word that has caused the most problems in the federal

EA program, and one that will be both completely surprising and most likely hotly

contested is …. the word “Architecture” itself!


MOST OF ENTERPRISE ARCHITECTURE … ISN‟T “ARCHITECTURE”!

―The words architecture and architectures are widely misused in the software industry,

confounding everyone.‖67

Marc & Laura Sewell, The Software Architect‘s Profession

Let‘s get right to the point:

Most of what we now call ―Enterprise Architecture‖ has nothing to do with ―architecture‖. By

misusing the term, we have unwittingly set ourselves up, at best for painful confusion, at worst for

eventual failure. With misuse of the term architecture, we have indeed ―confounded everyone‖.

Even before the IT industry adopted the word for its own use, the concept behind the word ―architecture‖

has always been difficult to fully grasp. Architecture is an elusive concept, and this elusiveness is a

subtle, mostly hidden factor that‘s preventing the federal Enterprise Architecture practice from

succeeding. (Commercial EA practices are similarly affected.)

To again quote from the Sewells (mainly because they said it best):

―Building architecture is all around us; we cannot avoid it … and we all know what it is on a

conceptual level, yet the word ‗architecture‘ is conceptual and defies precise definition. … [It] is

a striking fact given that architecture is as old as recorded history, yet the answer to the question

never gets closer than an approximation of the truth, like Plato‘s shadows on the wall.‖68

With the Sewell‘s general observation about architecture, and given that Enterprise Architecture was

originally based on an analogy to classical architecture, we must first recognize that even if ―architecture‖

was the appropriate term for ―the thing actually to be done‖, there would still be some ambiguity simply

because the concept of ―architecture‖ itself is so broad and conceptual and elusive.

But for most of what is done under the banner of Enterprise Architecture, it becomes a non-issue, because

most has nothing to do with architecture, anyway!

A quick way to understand this is to review the following IT-related activities, and ask how each relates

to architecture. How many are ―architecture‖? (i.e. ―true‖ architecture, not ―Enterprise Architecture‖.)

How many are architecture-like? Finally, before the advent of Enterprise Architecture, how many of these

were thought of as having anything directly to do with architecture? (The answers of course should be

―none‖, ―none‖, and ―none‖.)

Strategic Planning Process Management

IT Strategic Planning Performance Management

IT Governance Implementation

Program Management Change Management

Application Portfolio Management Configuration Management

Technology Portfolio Management Standards Development / Enforcement

Although it‘s certainly the case that almost all have something to do with the activity currently known as

―Enterprise Architecture‖, none have anything to do with real architecture (at least not directly).


Another way to see how little the current practice of Enterprise Architecture actually has to do with real

architecture is to closely examine how the term ―architecture‖ is used (or more precisely misused) in the

FEA. Table 10 summarizes how the term ―architecture‖ is incorrectly used throughout the FEA program.

Table 10: “Architecture” Terms Misused in Federal Enterprise Architecture Misused

“Architecture” Terms Problems with Usage

Business Architecture

- A mostly nonsensical term; what is really being spoken of is “Business Functions” or “Business Function Classifications” - The way an organization is organized isn’t an architecture - Even though an organization chart may look like a system modeling diagram, it’s still not a blueprint or an architecture

Data Architecture

- In respect to the FEA reference “models”, a nonsensical term because the DRM should only classify an organization’s data and has nothing to do with architecture. - A data architecture is applicable only in specific contexts, usually associated with design, e.g. “relational data architecture”, “distributed data architecture”

Performance Architecture

- A completely nonsensical term; what is really being spoken of is “Performance Measures” or “Performance Measure Classifications” - This term should have been seen as a warning indicator that the word “architecture” was being misused

Technology Architecture

- In respect to the FEA reference “models”, a nonsensical term because the TRM only classifies an organization’s technology and has nothing to do with architecture. - A technology architecture is applicable only in specific contexts, usually associated with design, e.g. “Network Architecture”, “Server Architecture”

Architect (verb) (e.g. “I will architect a solution”)

- “Architect” is a noun, not a verb - The correct word is “design” - “To architect” is pretentious nonsense (would a building architect say “I architect” or “I design”?)

Architect (noun) - Few IT positions merit the title “architect”

Federal Enterprise Architecture Framework

- The FEAF would have made a whole lot more sense if it hadn’t been trying to develop a framework for architecture and instead focused on developing a federal enterprise repository

Segment - Had we not confounded ourselves with the term architecture, the commonsense term “functional area” would likely have been used

Segment Architecture - Inaccurate and not intuitive - “Segment Architecture” is pretentious nonsense

Current Architecture

- Traditional building architecture doesn’t use the term “Current Architecture” – why does EA? - Better terms might be current state, current design, or (in places) current model - If used in EA, the term should only be used as a conceptual term that represents the current state of technical architecture and designs - Architecture doesn’t apply to organizational and planning aspects of “EA”

Target Architecture

- Traditional building architecture doesn’t use the term “Target Architecture” – why does EA? - Better terms might be planned state, planned design, or (in places) planned model - If used in EA, the term should only be used as a conceptual term that represents a general and high-level vision of the future state of technical architecture (thinking of a business changes to an organization as a “target architecture” is nonsense) - Real and specific target technical architecture is related to actual design


Misused “Architecture” Terms

Problems with Usage

Blueprint - An architectural blueprint is the representation of a design, not a process - Most of what FEA calls “blueprints”, aren’t (they’re usually plans)

Architectural change drivers

- What is an architectural change driver? Why not just “change driver”? - Would a building architect talk about “architectural change drivers”?

Enterprise

- Generally, the word has nothing to do with architecture - It really refers to “the whole organization” - The real intention of using the word “enterprise” was “ to implement and manage information technology the same way across the whole enterprise” (not just “architectures”)

Enterprise Architecture

Ultimately, this term only manages to confound and confuse

So what is architecture? How does one know what is and what isn‘t architecture? In just a bit, I‘ll

provide a simple and useful guideline that can be used to help make this determination. (Hint: it‘s already

been mentioned it the preceding table.)

OTHER MYSTIFYING EA TERMS

The misuse of the term ―architecture‖ is far from the only problem with poor or even completely incorrect

terminology use in the federal EA program. Unclear and inconsistent definitions occur repeatedly within

the federal EA program. The FEA is full of ―mystifying‖ terms that only manage to confuse and impede

the formation of a common understanding.

And while one might assume that the poor use of terminology in the federal EA occurs only for very

complex or esoteric definitions, this isn‘t the case. The problem is widespread and even applies to simple

terms and information technology terminology that should already be understood, but are not, including

words like ―model‖ and ―metadata‖. The term ―metadata‖ is consistently misused and misunderstood.

Table 11 below provides a list of just some of the confusing and ―mystifying‖ terms used in federal

Enterprise Architecture. (There surely are others).

Table 11: Other Mystifying Terms Used in Federal Enterprise Architecture

Federal EA Term Problems with Terminology

Reference Models Completely misnamed, catastrophic consequences; must change from “models” to “taxonomies” (Better yet, don’t provide any name for them at all! They’re really only attributes that categorize several EA object types.)

Align

- “Align” is confusing and misleading - “Aligning to the reference models” is completely unclear; the directions should have used the more commonsense word “Classify”: “Classify investments according to the Business Reference taxonomy” “Classify software according to the Service Component taxonomy” “Classify technology according to the Technical Reference taxonomy” “Classify data according to the Data Reference taxonomy” “Classify performance measures according to the Performance Reference taxonomy”


Federal EA Term Problems with Terminology

Artifacts

- What’s wrong with good old-fashioned terms “data” and “documents”? - Definitions for the term in the EA-domain is inconsistent or often missing (e.g. it’s not included in the Chief Architect’s Forum’s Glossary of Terms) - The adoption of the term is another indicator how confused the practice of EA has become … “artifacts” can be anything!

Framework

Use in only one of two contexts: (1) a basic conceptual structure (as of ideas) Example: PMI’s Project Mgt Body of Knowledge (PMBOK) (2) a skeletal, openwork, or structural frame Example: object-oriented or software frameworks, e.g. .Net framework

Data

- the EA repository contains data, not metadata - even when the data originated as metadata from a CASE or other modeling tool, once in the repository it becomes data (see Appendix B: It’s Not Metadata)

Metadata

- The EA repository doesn’t contain metadata, it contains data, just like any other database - Even when the data originated as metadata from a CASE or other modeling tool, once in the repository it becomes data (see Appendix B: It’s Not Metadata)

Model The EA repository is defined by a model, not a metamodel

Metamodel The EA repository is not defined by a metamodel, it’s defined just like any other database, i.e. by a model

Ontology Sure, it’s a real word, and it’s sometimes applicable to IT, but its use in EA isn’t necessary and is often pretentious. If nothing else, using simpler and more intuitive terminology helps establish common understanding

Semantic Harmonization

- Not intuitive - Pretentious - Change term to a more commonsense term, such as “standard” - When talking about design or a repository, use of terms “common model” or “common definitions” would be much clearer

“Business-driven”

- Most architecture (i.e. design) is only indirectly “business-driven” -Mindlessly copied and (over)used in far too many descriptions of EA within the federal government - When an architect is poring over the details of a complex design, is he “business-driven” or “design-driven”? Similarly, when an IT technical designer is poring over her design, is she business-driven or design-driven? - The further that an architect or other designer delves into the intricacies of design, the further that business-driven considerations fade into the background

“Results-oriented”

-A mostly meaningless term: all activities should be “results-oriented” (Is there any time we don’t want results?) -Completely and mindlessly overused in far too many descriptions of EA within the federal government


POOR USE OF TERMINOLOGY PREVENTED A COMMON AND SHARED

UNDERSTANDING

―That's part of the whole problem with architecture — there are all kinds of terms thrown around.

There's no commonality of understanding and definition around things.‖69

– Randy Hite, GAO‘s Director of Information Technology Architecture and Systems Issues (2005)

Randy Hite‘s statement, made in 2005, is as true today as it was back then. There has never been a

―commonality of understanding‖ about Enterprise Architecture.

The lack of a common and shared understanding in the federal Enterprise Architecture program was an

inevitable result of the poor use of terminology and the imprecise, even sloppy, use of words to describe

EA concepts and parts of the EA program.

"Exhibit 6: A Confused Understanding‖ gave many examples that demonstrated this lack of a common

and shared understanding. The section also showed that the government recognized that there was a

problem, and grappled with it – unsuccessfully – from 2002 to at least 2006:

In 2002, the GAO commented that ―… agency executives have not fully understood the value

of enterprise architecture…‖, and that these executives ―… have not understood the purpose,

content, and value of these architectures…‖

In 2004, surprisingly even the GAO asked ―Should the FEA be described as enterprise

architecture?‖

In 2005, the chairman of the Chief Architects Forum (CAF) stated that even defining the term

―Federal Enterprise Architecture‖ would be difficult.

In 2006, in an effort to resolve the confusion over EA terminology, the CAF developed the

Federal Enterprise Architecture Glossary of Terms.

While these examples show the extent that a common and shared understanding was missing from the

federal EA program, the problem was never fixed, either because no solution was pursued (the first two

examples), or because the attempted solution didn‘t address the root cause (the second two examples).

FAILURE TO DISTINGUISH BETWEEN WHAT IS AND WHAT ISN’T

“ARCHITECTURE”

Before we continue, let‘s review what‘s been covered so far:

1. The first problem, and the one that led to the rest, was the poor use of terminology to describe

Enterprise Architecture

2. Even the word ―architecture‖ is often misused (Remember the Sewell‘s statement, ―The words

architecture and architectures are widely misused in the software industry, confounding

everyone.”)

3. The FEA has used many other ―mystifying‖ and even incorrect terms in its EA program that

make the problem worse

4. Most of what is done as ―Enterprise Architecture‖ isn‘t architecture (we‘ll expand on this

shortly)


5. Collectively, these problems prevented a correct, common, and shared understanding ―of the

thing actually to be done‖.

Enterprise Architecture includes two main functional areas – ―enterprise‖ (focused on the organizational

and management aspects of information technology) and ―architecture‖ (focused on the technical design

of computer systems), but there has never been sufficient recognition that only the second one is

associated with ―real‖ architecture.

This rest of this section explores the difference between these two parts of EA and provides some history

how we started with ―architecture‖ and ended up with something that, while still including aspects of

architecture, evolved into something broader and far removed from ―real architecture‖.

But before continuing, we need a simple guideline that can help us quickly understand (and decide) what

is and what isn‘t ―architecture‖. Once again the Sewells provide us what we need:

The essence of the role of the architect is design.70

Let‘s rephrase it to be more general: The essence of architecture is design. As we examine the many

activities or parts of ―Enterprise Architecture‖, we should look for actual design. If we ―see design‖, then

it‘s probably real architecture; if we don‘t see design, it‘s probably not architecture.

ZACHMAN’S “INFORMATION SYSTEMS ARCHITECTURE” WASN’T THE SAME AS TODAY’S

“ENTERPRISE ARCHITECTURE”

When John Zachman initially proposed his framework for information systems architectures in 1987, his

focus was on technical architectures only; the concept of ―enterprise architectures‖ only came later. (A

brief summary of Zachman‘s original article can be found on page 86.)

Specifically, Zachman concentrated on what he called ―architectural representations‖, or the diagrams

used in architecture to represent the design of buildings or the design of systems being developed. For

information technology, the ―architecture‖ of systems was represented by data and process model

diagrams that had by then been in use for more than a decade.

Because Zachman‘s original focus was on technical architectures, and these architectures were

represented by system modeling diagrams, early Enterprise Architecture initiatives mimicked this focus

and began creating the same types of diagrams in early efforts to ―develop enterprise architectures‖. (At

this time, they were still really only technical architectures, with no focus on the organization.)

But as time went by, Zachman‘s original concept of ―information technology architectures‖ evolved to

encompass a broader perspective that added the organizational and planning aspects of an enterprise‘s

information technology resources. This broader perspective represented an ―enterprise‖ perspective of IT,

and became known as ―Enterprise Architecture‖.

Unfortunately, the EA industry, already working diligently to populate EA repositories with the same

kind of diagrams and using the same system modeling techniques that had been in use for decades, failed

to make a corresponding adjustment.

Instead, for the most part, the industry continued to crank out volumes of diagrams like the one in Figure

12.


Why? Because much of the industry didn‘t understand that modeling information technology

architectures (i.e. the technical design of information systems) wasn‘t the same thing as ―modeling the

enterprise‖ (i.e. representing the organizational and other characteristics of an organization).

Figure 12: “Enterprise” Data Incorrectly Populated as “Technology Architecture” Metadata

Most of the industry maintained a system modeling mindset, continuing to believe that they were

―modeling technology architectures‖ and ―populating the EA repository with metadata‖. Unfortunately,

both beliefs were no longer true. (Or more precisely, they were only partially true, because some

traditional system modeling was still needed to capture systems‘ technical designs from across the

enterprise).

Why were these beliefs no longer true? Because as soon as enterprise architects started to collect and

populate data other than the true metadata that describes or models systems, they were no longer doing

traditional system modeling and design. In short, they were no longer ―doing real architecture‖.

A quick way to understand this is to ask what EA teams populate into EA repositories when they ―model‖

an organization. Is the information about organizational components (bureau, office, division) metadata?

What about information about the organization‘s employees? Is that metadata? And what about things

like strategic plans, project plans, investments, or even IT assets? Are any of these information types

considered metadata when we add or find them in other systems, for example a Human Resources system,

or a configuration management database?

The answer, of course, is ―No‖. It‘s just data!

In summary, a widespread mistake was made by many EA teams: they failed to understand that

Zachman‘s ―information systems architectures‖ weren‘t the same as ―enterprise architecture‖, and that

EA had changed significantly. No longer was it enough to collect and store only technical systems

diagrams and metadata; they needed to collect a whole lot of additional information!


GAO’S FAA STUDY IDENTIFIED “LOGICAL” AND “TECHNICAL” ARCHITECTURES

A distinction between different types of ―architectures‖ was also made by GAO as early as 1997.

In that year, GAO performed a study of the use of systems-wide architectures in the FAA‘s Air Traffic

Control systems modernization effort and in its report GAO divided its architectural review into

discussions of ―Logical‖ vs. ―Technical‖ architectures.

Here‘s how GAO described each:

Logical: ―At the logical level, the architecture provides a high-level description of the

organizational mission being accomplished, the business functions being performed and the

relationships among functions, the information needed to perform the functions, and the flow

of information among functions.‖ 71

The logical component represents a high-level perspective:

―… [it] describes FAA‘s current and future concept of ATC operations, requirements in terms

of business functions to be performed, associated systems to be used, relationships among

these functions and systems, information needed to perform these functions, and flow of

information among the functions and systems. This high-level systems blueprint also

provides a roadmap, or transition plan, for its ATC systems over a 20-year period.‖72

Technical: ―At the technical level, the architecture provides the rules and standards* needed

to ensure that the interrelated systems are built to be interoperable, portable, and

maintainable. These include specifications of critical aspects of the component systems‘

hardware, software, communication, data, security, and performance characteristics.‖73

The technical component defines the technical standards and ensures compatibility between

systems:

― [It] specifies the information technology and communication standards that will be used

to build systems, including communication protocols and programming languages, and

facilitates the migration to compatible, vendor-independent operating environments.‖74

Finally, the GAO made clear that both architectures are needed, and that the relationship between them is

that the technical component implements the logical component. Another way to say this is that the

logical component (the mission, functions, plans, and processes) is realized through the implementation of

the technical component (hardware, software, applications, data, etc.).

The GAO‘s two architecture types are roughly parallel to the ―enterprise‖ and ―technical‖ architectures

already discussed. The GAO‘s logical architecture is much like (but not quite the same as) the

―enterprise‖ architecture, while GAO‘s technical architecture is very much the same as (if not identical to)

the ―technical‖ architecture.

Unfortunately, the distinction between these different ―architectures‖ has not always been recognized and

maintained, and problems have ensued.

* Note mention of standards in GAO‘s description (in bold type)


THE RESULTS OF FAILING TO DISTINGUISH BETWEEN WHAT IS AND ISN’T

“ARCHITECTURE”

We have seen that largely due to the poor use of terminology – in particular the misuse of the word

―architecture‖ – there has never been sufficient differentiation between what is and what is not

―architecture‖. The end result is that everything is seen as architecture, and we end up trying to ―do

architecture‖ for things that aren‘t architecture. As the saying goes, ―If you‘re a hammer, everything

looks like a nail‖.

We also end up not doing things that we should be doing. For example many agencies don‘t populate an

―inventory‖* of their significant IT resources into the EA repository because it doesn‘t look like

architecture. But this inventory is critical, as it forms the foundation of an organization‘s ―Current

Architecture‖: it must be populated for EA to succeed. (And no doubt this paragraph itself will be

contested by many, due to the very confusion and misunderstanding described in this paper.)

If what is now known as ―Current Architecture‖ had not included the word ―architecture‖, would it not

have been clearer what it was actually supposed to be? i.e. ―Let‘s first identify what IT resources we

currently have, so we can better manage and modernize them.‖ And if we had better known what the real

need was, would EA practitioners have ever proposed skipping Current Architecture development

entirely? (It has literally been suggested more than once. See page 37 for examples.)

Following are other examples of problems that have occurred because organizations have failed to

distinguish between things that are ―real architecture‖ and things that have been mistakenly identified as

―architecture‖:

The wrong modeling paradigm is often used. As discussed above, many EA programs never

made the transition to account for the evolution of ―architecture‖ from Zachman‘s original

technical-based information systems architecture to the more recent Enterprise Architecture.

The result is that most practitioners are still using a modeling technique that is no longer the

right one for most of their work.

Agencies spent large sums on EA tools that were inadequate. Very closely related to the

prior point, because EA practitioners believed that EA ―was about modeling and metadata‖,

agencies purchased modeling and metadata management tools which had begun life as

system development or data administration tools. As long as people were doing ―old-style

modeling‖, these tools were typically sufficient. But as soon as ―architecture‖ changed from

Zachman‘s information systems architecture to Enterprise Architecture – with the

corresponding paradigm shift – these tools were no longer adequate, and all too often only

produced volumes of diagrams that were (as has been said before) ―useful only as doorstops‖.

The ―Current Architecture‖ is often only partially done or not done at all. Many

organizations don‘t understand that the Current Architecture isn‘t just technical diagrams; it

must also include an inventory of significant IT resources. After all, how can an organization

gain control over their typically vast IT resources unless they comprehensively know what

and where those resources are?

* This inventory isn‘t a full inventory of all physical assets such as desktops, printers, storage, and other peripherals

as one would find in a CMDB. Rather, for most assets it‘s an accounting of the type of assets used by an

organization, e.g. types of desktop computers, or depending on the organization‘s needs, possibly even types of

switches and routers.


A special methodology was developed, but it wasn‘t needed. Because FSAM‘s developers

thought that they were ―doing architecture‖, they developed a large and complex

methodology custom-made for just that – architecture. But as discussed in detail in section

―FSAM: A Bloated Methodology That Produces Little but Confusion‖, a special

methodology was not only not needed, it actually made things far more complicated and

confusing that they needed to be.

Complex assessment methodologies were developed to measure ―architectural success‖. In

much the same way as the last point, because OMB thought that architectural success needed

to be measured, they created overly-complex (and in the end, useless) reports for agencies to

complete each quarter. If it hadn‘t been for the misunderstanding of the term ―architecture‖

(along with the accompanying notion that ―something complex‖ was needed) much simpler

and more reliable reports could have been developed.* See section ―OMB Compliance /

Assessment Reporting: Burdensome, Confused, Ineffective‖ for more information.

These are only a few of many examples where the confusion and misunderstanding about Enterprise

Architecture often led to situations where ―architecture‖ was done where it wasn‘t needed, and where

critical tasks weren‘t done because they didn‘t ―look like architecture‖.

But that‘s not the end of it.

* In fact, and as will be discussed in part II of this report, it could be that no assessment or measurement reports were

needed at all.


CONCLUSION

“BEFORE ENTERPRISE ARCHITECTURE”: AN IMAGINED SCENARIO

Let‘s imagine a scenario, one that takes place before Enterprise Architecture came into being and before

John Zachman wrote his article on information systems architectures. In this scenario, as in real life,

federal departments and agencies operate mostly autonomously and sub-agencies often operate semi-

independently of their parent agencies.

Next, let‘s imagine that the President hires the first Chief Information Officer to manage the entire federal

government‘s information technology resources. The President gives the new CIO a single mandate:

―Reduce the amount the federal government spends for information technology.‖

The new CIO has worked in the federal government his entire career. He has plenty of hands-on

experience with information technology. He started as a programmer and worked his way up the ranks,

gaining experience in most aspects of IT, having served in many different roles. He knows the

technology.

He also knows how technology is used in the federal government.

With his background and years of federal IT work, he already knows firsthand some of the reasons why

the government spends so much for information technology. Agencies operate as separate organizations;

they have inadequate knowledge or control over their often vast IT resources; they not infrequently pay

for software that is no longer used; and they often have duplicate resources.

On more than one occasion he‘s seen large federal agencies purchase the exact same, expensive software

product from a vendor, not knowing that the software had already been purchased by another part of the

same agency. (He also knows that vendors are more than happy to sell the same product again to the

same agency, and will rarely alert the agency to the duplicate purchase.)

So the CIO already knows some of what ails the government when it comes to IT. But he also knows that

he needs to understand the current state of federal IT before he can begin making changes. And to do

this, he knows that he needs to collect information from all federal agencies about their IT resources. It is

only with this information that he can make a clear assessment and then plan for leaner and more efficient

federal IT operations.

To start, he decides that he needs information from federal agencies (including all bureaus and sub-

agencies) about seven types of IT resources. A simple classification taxonomy is also defined for each

type of data to be collected. *

1. Hardware and software products (with purchase and annual licensing costs)

2. Physical servers (with purchase costs; operational costs may come later)

3. Major industry technology standards used (.NET, AJAX, IPv6, etc.)

4. Major computer applications (with costs)

* The list of items to be collected has been simplified and abbreviated for this imagined scenario. In particular, it

doesn‘t include the defintions of relationships between these data types that the CIO knows is needed for robust

analysis.


5. Current IT investments (with costs)

6. Current IT human resources (managers and technical staff working in IT, both contractors and

federal employees; for now the CIO only wants head counts, no costs yet)

7. Major data resources

The CIO‘s IT staff reviews his requirements and then defines a database that will store the collected data

(so analysis can be performed) and an XML-based data interchange that will allow agencies to transmit

their data about IT resources for inclusion in the integrated, federal-level database.

Next, the CIO directs his staff to develop a relatively simple application that he (and they) will use to

access, browse, and analyze the collected data. The application will provide the ability to browse through

the integrated data and will provide simple OLAP capabilities that allow the CIO (and team) to perform

analysis of the data, allowing them to ―slice and dice‖ across any combination of selected resources and

agencies.

The CIO recognizes that the database and application software can also be used by federal agencies.

Together, the two can: (1) provide agencies a centralized point of collection for the required data, in

preparation for transmitting to the federal-level database; (2) for those departments or parent agencies that

don‘t already have an integrated IT resources database (almost all of them), provide a database where

agencies can start to collect and integrate their own agency data; and (3) provide OLAP capabilities that

will allow each agency to perform analysis that will reveal duplication, wasted resources, etc. within their

own agencies.

With his initial planning done and both the database and application software ready, the CIO issues a

memo to all federal departments and agencies, directing them to collect and transmit the specified data

about IT resources to his office. He doesn‘t direct them how to do the data collection, only that the

collected data must be consistent with the XML data interchange file‘s schema. (Specifications for the

data to be collected are also provided, with instructions and guidance that explains why this effort is being

undertaken.)

His memo lets agencies know that the integrated data will be made available online for their use, so they

can see what technology all other agencies are using, and eventually locate opportunities for information

exchange and joint development and possible resource sharing with other agencies.

The memo also tells agencies that the software can be downloaded for their own use, and that both the

database and application are fully extensible. In this way agencies can add to the model and collect data

specific to their own needs. The CIO also publicizes that the database and application will be maintained

as a federal-wide standard, and strongly recommends that all agencies adopt it. The CIO realizes that it

would be a bit ironic – even embarrassing – if each agency developed their own, incompatible solutions

for this initiative, one of whose objectives is to eliminate the very problem of incompatible IT solutions.

Finally, he directs all agencies to provide information about their hardware and software standards. He

wants to know the following about these standards:

What they are

Whether they‘re formally maintained and communicated

What scope the standards cover (i.e. department, bureau, or sub-agency level)

What process(es) exist to establish a new standard or retire old standards


How closely their hardware and software inventory actually matches their hardware and software

standards (he knows that this is a strong indicator showing how well agencies understand and

control their hardware and software inventory)

Ultimately, all of the agencies‘ IT resources data is collected and loaded into the CIO‘s database. The

CIO and his team examined the data thoroughly and among other observations, found the following:*

1. The data confirms that most federal departments and agencies operate as mostly-autonomous

organizations, with little coordination among them. This is true even for parent agencies and

their respective sub-agencies. (Many sub-agencies operate their own networks, some run

their own, data centers, and software products differ substantially between parent and sub-

agencies.)

2. As expected, most agencies have limited knowledge about, or control of, their IT resources.

These resources are often very substantial. (Many agencies discovered how little knowledge

they had about their entire IT resources inventory and sometimes found resources they didn‘t

previously know they had.)

3. There is extensive duplication of resources, both between sub-agencies and their parent

agencies, and even within single organizations. A quarter of departments operate duplicate

systems for the exact same functions (e.g. multiple payroll systems) and nearly all operate

several software products for the same functionality (e.g. many database products and

multiple products for data reporting and analysis).

4. Approximately 3% of IT expenses are for hardware and software that is no longer used, but

for which payments are still being made to vendors.

5. There is almost no coordination among departments to leverage or share their IT resources, or

to share knowledge among them. Most departments run their own HR, Payroll, Financial,

Training, Travel, and other business support functions. They also run separate and

incompatible systems for ―core‖ processes such as Grants, Government Benefits, etc.

6. Finally, by far most agencies have either weak or even no formal standards for their hardware

and software, and only a relatively few have processes that are followed to establish or

modify standards. Unsurprisingly, as a result of weak standardization, most agencies have

purchased a non-standard and even incompatible hardware and software products. Some

cases were even found where agencies had purchased software that was incompatible with the

agencies‘ hardware platforms.

During the data collection process, many agencies installed and began using the standard database and

application for their own use. Many have started examining their own resources inventory and have

already begun the process of eliminating duplication and removing unused software and even

applications. The database has provided them visibility into their IT resources that they never had before.

In turn, this added visibility has provided them with new—and often completely unexpected – insights

into how much duplication and overlap had existed in their IT operations.

Let‘s summarize what the CIO has accomplished so far:

1. For the first time ever, the current state of IT resources across all federal agencies is known

2. Standard software to analyze federal IT resources has been defined and made available to all

agencies

* Numbers are fictional, only for purposes of illustration.


3. A federal standard common data model for IT resources has been established that allows for

―apples-to-apples‖ comparison of agency data

4. A federal standard XML data interchange has been established. The standard allows IT resource

data to be uploaded, both from parent agencies to the federal database and from sub-agencies to

parent agencies

5. All agencies know the current state of their own IT resources, and parent agencies know the

current state across their entire organization

6. All agencies also have the basic information about IT resources that they need to inform and

support other IT-related processes such as IT governance, capital planning, application portfolio

management, technology portfolio management, and standards development.

7. The federal CIO has the information he needs on which to proceed. This information will allow

him to prioritize and organize a federal-wide plan for reducing wasted, duplicated, and

overlapping resources.

The CIO is on his way. With the knowledge of the current state of federal IT resources, he is ready to

begin meeting the President‘s mandate, ―Reduce the amount the federal government spends for

information technology.‖

He will begin by picking the low-hanging fruit. The data collected about IT resources lets him know

where the juiciest low-hanging fruit is, thus where to begin. He directs agencies to:

1. Remove IT resources that are no longer being used. This will eliminate licensing fees for unused

software, drop the cost of running unused servers and other hardware, and eliminate costs of

applications that are still running but not used. His analysis shows that the government should be

able to save some 3% of total costs within 12 months.

2. Identify duplicate resources (such as multiple database products) and begin standardizing on one

or two. This will eliminate licensing fees and over time will decrease costs by reducing the

number of skill sets needed to run agency systems. It‘s estimated that elimination of licensing

fees alone should save between 2 and 3% of IT costs over 2 or 3 years.

3. Analyze server use and identify under-used servers. Begin plans for server consolidation. (Note:

we‘re not ready to consolidate data centers; that will come later.) It‘s estimated that another 1 to

2% cost savings can be accomplished over 1 or 2 years.

What else has the CIO accomplished?

Without using any reference to “architecture”, the CIO did much of what the federal Enterprise

Architecture program had intended to do, but so far has failed to accomplish.

In particular, the CIO laid the foundation for all his subsequent plans by first establishing the current state

– what EA has called ―Current Architecture‖ – without a single reference to ―architecture‖ and without

the need for a new technology discipline and volumes of complex documentation produced to explain the

discipline.

As impossible as it may sound, our imaginary CIO, unfettered by the confusion and misunderstanding so

prevalent in Enterprise Architecture, has accomplished his goal without EA. But most important, he has

also shown that a new technology discipline wasn‘t needed.


WE CREATED A NEW TECHNOLOGY DISCIPLINE THAT WASN’T NEEDED

By now it should be clear that the practice of Enterprise Architecture has offered us nothing that wasn‘t already available to us before in our pursuit of a federal-level understanding and management of all federal IT resources. In fact, as this paper shows, EA not only didn‘t help us in this pursuit, it has actually hindered our progress. In our quest to ―do architecture‖, we have been misled by illusions of architecture. We have cast aside simple yet effective IT terminology and methodologies that have been in use for decades, and have replaced them with new but ultimately misleading terminology and bloated methodologies that are at times more complex than the problem being addressed. We have replaced simple, intuitive, and long-used terms like ―functional area‖ with dense, obtuse terms like ―Segment Architecture‖ that only manage to confuse, and have developed a corresponding methodology that defies comprehension and does little to actually help us analyze a functional area. (See section ―FSAM: A Bloated Methodology That Produces Little but Confusion‖). We have forgotten the importance of something as simple as standards, which have been helping us manage and control the selection and acquisition of IT resources since the earliest days of IT, but that have been all but abandoned in a confused and chaotic pursuit of ―architecture‖. While both of the seminal federal EA documents

* include mention of standards, as best as the author can

tell, in the confusion caused by Enterprise Architecture these standards have been left by the wayside. Most federal agencies, it seems, have inadvertently discarded standards as they attempted to develop their technology reference models, and more often then not, ended up with neither. If we analyze the importance of standards a bit further, we should come to realize that effective enterprise architectures (i.e. technology managed uniformly across an entire enterprise) depend far more on standards than ―architectures‖. To a great degree we can integrate information systems without speaking of architecture. But without well-managed standards that ―inform, guide, and constrain‖ the selection, purchase, and management of IT resources across the entire enterprise, we will always have wasteful duplication and overlap of these expensive resources. To be sure, this paper has focused on development of the current state as the foundation of Enterprise Architecture, and hasn‘t addressed other aspects of Enterprise Architecture such as strategic alignment and transition plans, or capital planning and portfolio management (depending on where one draws the line between EA and other IT management activities). It is believed, however, that what has been said about throwing out long-practiced terminology and methodologies that would have been sufficient for defining the current state applies equally to these other EA activities. For example, the concept of strategic alignment has never depended on ―architecture‖, and never should. Strategic alignment depends only on good technology management that effectively addresses and incorporates strategic business needs into IT planning. That and common sense. Finally, what has been said here should not be misconstrued to mean that we should never develop new techniques or new methodologies to develop and manage our information technology environments. There are, of course, times when change is necessary, when old methods no longer work, or when new technology truly requires new terminology or ways of managing it. From all that has been stated in this paper, however, this doesn‗t appear to be one of those times.

* The Federal Enterprise Architecture Framework and A Practical Guide to Federal Enterprise Architecture


FINAL VIEW: WHAT IF ENTERPRISE ARCHITECTURE WAS AS VISIBLE AS

BUILDINGS?

In their book ―The Software Architect‘s Profession‖, Marc and Laura Sewell, to illustrate the many

unseen and often spectacular failures of software development imagined that software systems were

suddenly as visible as buildings.75

The following passage, which in a similar fashion visually imagines

the failures of Enterprise Architecture, gratefully borrows from the Sewell‘s original idea.

If the products and results of Enterprise Architecture activities at federal agencies were suddenly

visible as physical buildings, of a size commensurate with their costs, the phrase ―boondoggle‖

might pepper the headlines. Perceptible to all would be a landscape strewn with vacant,

unfinished structures lying useless and abandoned by the side of the road. There would be a very

few functional buildings, but with empty rooms, dead spaces, and unhappy inhabitants.

Neighboring these inefficient buildings and exquisitely expensive failures, in a scene worthy of

Jonathan Swift, we would witness attempts to re-erect different versions of the same buildings,

sometimes by the same construction companies responsible for the empty fiascos, often by

entirely new companies that would, with the same ―confused understanding of the thing actually

to be done‖, also put up useless structures.

The builders would be brandishing new tools and sagely offering ―improved solutions‖ in the

form of new practice guidance and dense methodologies that would inevitably lead, again, to

failure.

Unfortunately the practice of Enterprise Architecture continues to produce results that fail to

meet expectations – or all too often produce no results at all – despite increasing and ever-

changing efforts.

The poor, forgotten clients – CIOs, IT managers, and the agencies themselves – continue to pay

for these efforts, often asking themselves: ―What is Enterprise Architecture, anyway?‖

We, as practitioners of this discipline known as Enterprise Architecture, need to provide a new and

understandable answer to this question.


INTRODUCTION TO PART II, THE PROPOSED SOLUTION

This document forms Part I of this examination of the federal Enterprise Architecture. Part II of the paper, titled

―The Proposed Solution‖ will propose a 5-step solution to fix and rehabilitate the federal EA. Part II is expected to

be completed by late October – early November 2010. This section introduces the five steps of the proposed

solution.

―Creating a new paradigm usually involves examining and challenging simple, underlying

assumptions. This is not done by climbing up to the leaves and branches of existing thought; it

happens when you dig down under the surface and get to the crucial radix – the root – of the tree,

or the very way you have been seeing the tree.‖76

Marc & Laura Sewell, The Software Architect‘s Profession

To fix the federal enterprise architecture, we need to reexamine the very way that we have been ―seeing

the tree‖, or the very way that we have previously ―understood‖ – or more accurately misunderstood –

Enterprise Architecture.

Enterprise Architecture has gotten thoroughly bogged down in a swamp of sloppy definitions and

misused words, grand definitions of architecture that too often have little or nothing to do with real

architecture, and poorly differentiated functionality, all currently lumped indiscriminately under a

common and misnamed banner: ―Enterprise Architecture‖.

Before we can begin to fix these problems and rehabilitate Enterprise Architecture, we first have to ―drain

the swamp‖. A five-step solution to do this is proposed:

1. Rethink and Fix the Analogy to Classical Architecture. The analogy to classical architecture first

made by John Zachman is faulty and incomplete. Over the years, it has also veered off course. We

need to reexamine the analogy and correct it.

2. Revisit the Basics. Some great ideas got lost in the flood of information – and misinformation – that

poured into the swamp. To reaffirm these great ideas, we need to revisit the basics by reexamining

some of the original (and excellent) guidance documents created by OMB and the CIO Council.

3. Reset by Communicating a New Understanding. Once we establish a new understanding of the ―thing

actually to be done‖, this new understanding must, of course, be communicated across the federal

government and to other stakeholders.

4. Revitalize the FEA and Agency Architectures. Only after we ―Rethink, Revisit, and Reset‖ can we

begin to revitalize Enterprise Architecture in the federal government. Part II proposes steps that need

to be taken to revitalize Enterprise Architecture use in the federal government.

5. Retire Parts that Impede, not Improve. Some parts or activities of the federal EA program actually

impede the progress that EA was supposed to improve. Once identified, these items should be

officially retired.


APPENDICES

APPENDIX A: THE FEA REFERENCE “MODELS” AREN’T MODELS

(Note: ―Exhibit 2: The FEA Reference ―Models‖: Tragically Misnamed‖ provided an initial, high-level synopsis

about the mistake of using the word ―model‖ to name what really is a set of taxonomies. This appendix goes into

more detail and provides additional examples how the misnaming has rippled throughout the federal EA program.)

As discussed in ―The Causes‖ section, the poor use of terminology to describe parts of the Federal

Enterprise Architecture has been the foremost problem that underlies many of the failures of the federal

EA program.

Both the federal EA program and the wider EA discipline offer many examples of the effects of poorly-

chosen words that describe parts or characteristics of Enterprise Architecture.

But there is perhaps no example, literally anywhere, that illustrates this more effectively than the

selection of the word ―model‖ to name what is really a set of taxonomies, i.e., the FEA reference models.

This is appendix will show how the use of the word ―model‖ – instead of ―taxonomy‖ or ―classification

scheme‖ – has resulted in a huge amount of confusion about what the intended purpose of these

―reference models‖ really was. It has also often made them far more difficult to understand and use than

they should have been.

Is it really significant that they were named ―Models‖ instead of ―Taxonomies‖?

Yes, it has been hugely significant! This appendix explains why.

First, let‘s confirm that they really are taxonomies. How do we know? Because that‘s how they‘re

described in many of the FEA guidance documents! In particular, the documentation about the

Reference Models describes them as taxonomies! To verify this, a representative sample of these

descriptions found in FEA documents is provided in the following table.

Table 12: Descriptions of FEA "Models" as Taxonomies Source Taxonomy / Classification Reference

FEA Consolidated Reference Model Document Version 2.3 (2007)

The SRM is a business-driven, functional framework classifying Service Components (6)

CIO Council’s Federal Enterprise Architecture Reference Model Maintenance Process (2005)

“The reference models are a taxonomy developed to provide a greater degree of transparency into the asset and information base of agencies through classification.”

The Data Reference Model – Draft Version 1 (2004)

The model is intended to provide a common, consistent way of categorizing and describing data. (p. 5) It is intended to support categorization and classification of information. (p. 20)


Source Taxonomy / Classification Reference

The Data Reference Model – Version 2 (2005)

“The other FEA reference models are types of Taxonomies” (p. 40) The DRM documentation goes into detail and even describes the Linnaean taxonomy for biological sciences as another taxonomy. See pages 9, 36, 38-41, 43 and 79 of the DRM document which expounds on “taxonomies”.

CIO Council’s Practical Guide to Federal Enterprise Architecture (2001)

Technical Reference Model – a taxonomy that provides a consistent set …” (pp 37 & 90)

FY06 FEA Additional Instructions (2004) An organization reflects its use of the FEA … when it consistently refers to this taxonomy …” p. 3 The document describes a numeric classification scheme for the BRM (pp 6-10; appendix)

FY07 Budget Formulation FEA Consolidated Reference Model

“The SRM is a business-driven, functional framework classifying Service Components …” p. 6 “The *BRM’s+ Business Areas separate government operations into high-level categories…” p. 22

GAO Report: The Federal Enterprise Architecture and Agencies' Enterprise Architectures Are Still Maturing (2004)

“GAO’s reading of *the FEA reference models] suggests that it is more akin to a classification scheme for government operations than a true enterprise architecture.” – Highlights page “Through the FEA, OMB is attempting to provide federal agencies and other decision-makers with a common frame of reference or taxonomy…” p. 2

Chief Information Officer’s Council. Reference Model Maintenance Process (2005)

“The reference models are taxonomy, developed to provide a greater degree of transparency into the asset and information base of agencies through classification.”

To dispel any lingering doubt (there is certain to be some), let‘s compare one of the FEA ―models‖ to the

Linnaean taxonomy for biological sciences, i.e. the taxonomy that biologists use to classify all living

things and the one used by the Data Reference Model document to explain ―taxonomies‖.

In Figure 13, below, the Linnaean taxonomy is represented in the table on the left. The BRM taxonomy

is represented on the right as both a table (top) and as the ―model diagram‖ found in FEA documentation

(bottom).

Viewing the figure, we can see that the Linnaean taxonomy is a seven-level hierarchical taxonomy. The

BRM is also a hierarchical taxonomy, but a simpler one, with only three levels. While the Linnaean

taxonomy classifies ―living things‖, from the figure we can see the BRM classifies IT investments. (We

also know that the BRM classifies the investments because it‘s included as a column in Exhibit 53. Note

that this is also a telling indicator about how the BRM should be represented in an Enterprise Architecture

repository. This will be explained below.)


Figure 13: Comparison of BRM to Linnaean Taxonomy

OK, by now it should be clear that the FEA Reference ―Models‖ really are nothing more than

taxonomies!

Now let‘s explore these taxonomies a bit further. Keeping in mind that taxonomies ―classify things‖,

what do the respective taxonomies in Figure 13 classify? The answer for the Linnaean taxonomy is easy:

it classifies ―living things‖. (We would have known even if the answer hadn‘t already been stated above).

What about the five FEA Reference Taxonomies? What do they classify? We‘ve already said that the

BRM classifies investments. (But that‘s not all! We‘ll return to this in a bit.) What about the others, the

SRM, TRM, PRM, and DRM?

The answer is: ―We don‘t know.‖ (Or at least most people don‘t know.)

And that‘s the source of one of the most significant problems with reference models:

It has never been clear what things these Reference Taxonomies were supposed to classify!

The FEA PMO developed wonderful hierarchical taxonomies, complete with values, but it never made

clear what these taxonomies would actually classify!

And this problem spread into other parts of the federal EA program.

For example, when it came time for agencies to populate the Federal Enterprise Architecture Management

System and ―align to the FEA Reference models‖, most didn‘t know what ―things‖ were supposed to be

populated. (FEAMS ultimately failed, in large part due to this.)

And when business case developers were asked to ―map to the BRM / SRM / TRM / PRM‖ in their

Exhibit 300s, more often than not, they didn‘t understand what really was being asked of them was

simply to classify four things related to their business cases: Investments, Service Components, the

Technology used by Service Components, and Performance Measures. *

So what things do the Reference Taxonomies classify? Table 13 shows the most likely ―candidate

entities‖ for each Reference Taxonomy. (These may vary somewhat between different agencies‘ EA

models).

* Having reviewed hundreds of Exhibit 300 EA sections, it‘s safe to say that a large majority of entries were

completely wrong and thus unusable for any purpose. For example, an almost universal error was to enter function

types (e.g. ―Case Management‖) in the SRM table instead of actual Service Components (e.g. ―Taxpayer Case

Management System‖)


Table 13: Likely Entities for the Five “Reference Taxonomies”

For Reference Taxonomy These Are the Most Likely Entities Classified by the Taxonomy

Business Reference Investments (and optionally Applications)

Service Component Service Components (i.e. “deployed software”)

Technology Reference Hardware Products, Software Products, and Industry Standards (i.e. the Technology Portfolio)

Performance Reference Performance Goals

Data Reference Data Sources (i.e. files, databases, other data)

But this isn‘t the end of the problems caused by the misnaming these taxonomies as models. Three other

types of problems are discussed next.

People Think that They’re System Design Models

Because the word ―model‖ means something specific in the field of system development (e.g. ―data

modeling‖), and because the field of Enterprise Architecture began with an exclusive focus on technical

models (see discussion of John Zachman‘s original paper in Appendix C: EA Modeling Used the Wrong

Paradigm), the FEA reference models have often been thought of in the same mindset: ―a system design

model‖. With this mindset, EA practitioners have used traditional data modeling practices, with many

unintended consequences. Here are some of the more significant ones:

1. The Data Reference Model Missed the Entire Point

Because its developers incorrectly believed the Data Reference Model must be a ―model‖, the

DRM metastasized far beyond what it should have been: a simple taxonomy to classify agencies‘

data in a uniform way across the federal government.

Instead of simply defining a hierarchical taxonomy similar to those that had been defined for the

other four FEA taxonomies, the DRM developers created something that seems to be more of an

(incomplete) data administration capability that includes both its own separate data model and a

rough set of data administration standards. (None of the other taxonomies defined their own data

model or corresponding standards.)

Ironically, even though its developers specifically – even emphatically – declared the DRM to be

taxonomy, they were so focused on creating a ―model‖ that they entirely overlooked the actual

definition of the taxonomy, complete with classification values. The DRM is the only FEA

taxonomy that failed to define an actual taxonomy (with values) that could be used government-

wide.

2. The Reference ―Models‖ Are Usually Modeled Incorrectly

Another example can be found in the way that the FEA reference classifications are modeled in

many (or most) EA repositories, including the Federal Transition Framework. The classifications

should be defined as attributes, but they are usually defined as entities. (Defining them as entities

is similar to defining the classification attribute ―Sex‖ as an entity.)


Figure 14 shows an example of this, where the TRM was modeled by an agency as three separate

entities. This type of definition is common in many federal EA models, but it‘s wrong* and is

more complicated than it needs to be. Specifically, the TRM‘s three-level classification hierarchy

is modeled as three hierarchically-related entities, instead of entity attributes, and a nebulous

relationship, ―alignment‖ is introduced.

Figure 14: TRM Incorrectly Modeled as Entities

The Federal Transition Framework also incorrectly modeled the Reference Models as entities.

Figure 15 shows the PRM, BRM, SRM, and TRM modeled as entities in the FTF.

* There is one case where defining the Reference Models as entities might be valid: in EA repository products

where vendors must provide the ability to customize the model. Defining them as entities allow them to be

customized and to classify many different things.

What‘s an

―alignment‖?


Figure 15: PRM / TRM / BRM / SRM Incorrectly Modeled as Entities in the FTF

No doubt many will defend the decision to model these as entities. In fairness, in data modeling

there isn‘t always a single way to model something.

But once we understand that the Reference models are really taxonomies, following a simple

five-step progression based on that fact should help illuminate why modeling them as attributes is

the correct way to do it:

1. In layman‘s terms, we would say that ―A taxonomy classifies things according to

their characteristics‖ (note that the taxonomy itself isn‘t the ―thing‖)

2. Expressing this same idea using data modeling terminology, we would say ―A

taxonomy classifies entities according to their attributes‖ (again, the taxonomy isn‘t

the entity)

3. Although the FEA documentation isn‘t completely clear about it, implicit in the

existence of these taxonomies is that several corresponding entities must exist.

(These entities have already been listed above in Table 13.)

4. If the FEA taxonomies aren‘t the entities then they must be attributes, and therefore

must be modeled as attributes in each respective entity (see footnote*)

5. Finally, because they are three-level hierarchical taxonomies, three attributes need to

be defined for each taxonomy. This is shown in Table 14.

* There are different ways to model the attributes. For purposes of simplified reporting and analysis of EA data, the example

proposes defining and populating three attributes directly into their respective ―Candidate Entities‖.


Table 14: Modeling FEA Taxonomy Attributes

For This Entity: Define These Reference Taxonomy Attributes:

Level 1 Level 2 Level 3

Investment (and possibly Application) (BRM)

Business Area Line of Business Sub Function

Service Component (SRM)

Service Domain Service Type Svc Component

Technology Product & Standard (TRM)

Service Area Service Category Service Standard

Performance Goal (PRM) Measurement Area

Measurement Category

Measurement Grouping

(DRM not included) No taxonomy defined for the DRM

For those who still might not be convinced, there is one final clue that strongly suggests that the

Reference Taxonomies shouldn‘t be modeled as entities: when modeled as entities, they only

have one or two non-key attributes, roughly ―Name‖ and ―Description‖. Almost all ―real‖ entities

have more than two non-key attributes; most taxonomies – or data codes – have only one or two

non-key attributes: ―Name‖ and ―Description‖.

3. The Reference ―Models‖ Trigger Other Modeling Errors

The error of modeling the Taxonomies as entities triggers a second type of related error, the

intermingling of entities and attributes. Figure 16 shows an example of this with the TRM. The

three taxonomy classification attributes, Service Area, Service Category, and Service

Subcategory, have been intermingled in the figure with two EA entities, ―Products‖ and

―Specifications‖. (―Products‖ are the Hardware Products and Software Products, and

―Specifications‖ are the ―Industry Standards‖ entities shown in Table 13: Likely Entities for the

Five ―Reference Taxonomies‖ on page 77.)

The figure reveals the frequent, muddled understanding of the relationship between the things

(entities) and the FEA Taxonomies that classify those things. A modeling error is caused because

attributes are being modeled as entities.


Figure 16: Intermingling of Attribute and Entity Definitions

Many Agencies Customized the Reference Models

Figure 16 also shows another result of the ―Reference Model confusion‖: in their efforts to get the

Reference Models to work, agencies often customized them, effectively ―hammering the square peg of the

Reference Taxonomies into the round hole of the rest of their EA repository model. Following is one

agency‘s explanation for changing the TRM‘s ―Standard‖ category to an agency-specific definition,

―Service Subcategory‖. In particular, note how the agency viewed the Products and Specifications

entities as simply lower level categorizations of the TRM itself.

In addition to the three tiers defined in the FEA TRM, [the agency‘s] TRM has more detailed

categorizations of ―Products‖ and ―Specifications‖. The ―Standard‖ category of the FEA TRM did not

satisfy the requirements for [the agency‘s] ability to make strategic investment decisions. The FEA TRM

ambiguity around the definitions of a standard, product, and specification, forced the introduction of

more specific categorizations tailored to [the agency‘s] need for more thorough procedures for analyzing

its IT landscape. First, the FEA TRM ―Service Standard‖ layer was renamed to ―Service Subcategory‖

for encompassing more granular categorizations of technologies: products and specifications.

The Reference Models Became Ends Unto Themselves

Because the term models implied that the Reference Models were real models of something or entities

that autonomously existed in their own right, many people assumed that they had a larger significance

than was actually called for. As a result, the Reference Models have become ends unto themselves.

Instead of being simple classification schemes that help the federal government perform apples-to-apples

comparisons of IT resources across the entire federal enterprise, they have become ―things‖ that need to

be independently managed within an EA. They are sometimes even thought to be ―architectures‖.

Service AreaThe Service Area is the high-level technical category of the FEA Technical Reference Model.

There are four main Service Areas consisting of Service Access and Delivery, Service Platform

and Infrastructure, Component Framework, and Service Interface and Integration.

Service CategoryThe Service Category is a sub-section of the Service Area that is a smaller

categorization of technologies, specifications, and standards.

Service SubcategoryThe Service Subcategory consists of both products and

specifications that are contained within a larger Service Subcategory.

ProductsProducts consist of those applications and system software that

support the business processes and mission of the enterprise.

SpecificationsSpecifications are technical blueprints from which products are

implemented. They are especially important for the continued

modernization of an enterprise’s IT infrastructure.


Perhaps the best example of this tendency to exaggerate the significance of these ―models‖ can be found

in the FEA PMO‘s the second version of the BRM. The document‘s subtitle was ―A Foundation for

Government-wide Improvement‖ and the document specifically stated that ―The BRM serves as the

foundation for the FEA.‖77

But the BRM can no better serve as the foundation of the FEA than the

taxonomy ―Race‖ can serve as the foundation of the U.S. census.

Finally, the BRM is sometimes believed to be the Business Architecture, but a ―business architecture‖ can

exist without a BRM taxonomy. The BRM only classifies IT investments in a common way. (Even the

name ―business architecture‖ should have been a clue that something was amiss – it‘s a nonsensical term,

only exceeded in strangeness by ―performance architecture‖.)

Figure 17 is representative of how agencies often believed the BRM to be the same as the Business

Architecture.

Figure 17: The BRM is NOT "The Business Architecture"

The End Result was Confusion

This misnaming has resulted in many federal agencies that have been limited or sometimes completely

unable to use the FEA taxonomies in a meaningful way. Some agencies‘ usage of the Reference Models

has been limited to nothing more than listing the taxonomy definitions, copied directly from OMB

documentation. Other agencies have ―no usage at all‖, because their EA staffs simply didn‘t know how to

use or to represent them in a repository.

The problem with calling the Taxonomies ―models‖ is compounded when other poorly chosen words are

used. For example, the word ―align‖ often confuses those who need to use or to provide information to

the EA. Business case developers working on Exhibit 300‘s are asked to ―align to the BRM / SRM /

TRM / PRM‖. This phrase is not clear, and even after explanations many users are still uncertain what

―aligning‖ to one of these strange ―models‖ really means – or perhaps more importantly why they‘re

being bothered to do this strange ―alignment‖ at all!

It would have been much clearer and self-explanatory if they were instead asked to ―classify the

investment‖ using the standard, federal-wide taxonomies defined by OMB.

(Summary on next page)


Summary

Most of the effort expended on the FEA reference models has been completely unnecessary. It would

have been much clearer if they had been more accurately named the ―FEA IT Resource Classifications‖

or, more simply, the ―FEA Taxonomies‖. Either would have been far more meaningful and intuitive than

―models‖.

Better yet, it would have been even better if they hadn‘t been given any name and had just been quietly

defined as classification values in a federal EA repository data model with no fanfare… and no unending

confusion.


APPENDIX B: IT’S NOT METADATA

Question: What’s the definition of “metadata”? Answer: The thing that causes most fights at data management conferences.

Although this quip is a tongue-in-cheek joke about the industry‘s lack of a good, agreed-upon definition

of ―metadata‖, anyone who has been in data management (or even has just worked with data), knows how

much truth there is to the joke: there is no clear, common, precise, and uniform understanding and

agreement about what is meant when people talk about ―metadata‖.

A personal experience made clear how completely – even comically – true this was (and still is).

Several years ago, working as the Metadata Manager on a data warehousing project, I was unexpectedly

asked to interview a candidate who would document the ETL programs and processes being developed.

Because my work was outside the actual ETL development, I was surprised by the request to interview. I

assumed that I was asked as a senior member of the project team.

The person was hired and I was again surprised when she was placed on my small metadata team. Our

new hire and I had both assumed that she would be part of the ETL development team because she would

be working with the team and documenting the team‘s products.

The (il)logic of the decision to make her part of the metadata team soon became clear. By taking the

industry‘s generally-accepted (and horribly imprecise) definition of metadata as ―data about data‖, and

determining that the documentation to be developed was also ―data about data‖ (specifically ―textual data

about warehouse data‖), it was concluded that the documentation itself must therefore be metadata.

Using this same logic, ultimately everything that wasn‘t actual warehouse data or ETL code was to be

considered metadata: documentation, planning documents, PowerPoint presentations, reports, even

meeting notes. Anything that was ―about the warehouse‖ – no matter how remotely ―about‖ – was

declared to be metadata (despite my advice against it).

So, on this project at least, the effective definition for metadata became: ―Anything that‘s not data and not

code‖.

Another fight was brewing at the data management conference.

So what‘s wrong here? The immediate problem, of course, is that the generally-used definition for

metadata, ―data about data‖, is terribly imprecise and, as the prior anecdote illustrates, when used

injudiciously can be stretched and convoluted so much that ultimately almost anything can considered

―metadata‖.

The more general problem is that there is enormous confusion and misunderstanding in the IT industry

about metadata. Many, perhaps most people in the IT industry don‘t really know what metadata is and

often can‘t even distinguish between data and metadata. This is particularly true in the field Enterprise

Architecture.

The confusion and misunderstanding about metadata in Enterprise Architecture is a major factor

impeding the development and use of EA in the federal government.


Here‘s why:

Contrary to the belief of many (or more likely most) EA practitioners, what is being populated into EA

repositories is not ―metadata‖, it‘s simply data, and with one exception, is exactly like data that is

captured and maintained in ―regular‖ information systems. Furthermore, the EA repository is not a

metadata repository; it‘s nothing more than a database that in almost all respects is just like any other

information system database.

This is not just a matter of semantics. EA teams, operating under the assumption that their task is to

collect metadata and populate a metadata repository, use modeling techniques taken from the systems

development discipline and painstakingly populate the EA repository by ―modeling‖. Almost always this

is accomplished by creating diagrams or ―…charts that look more like circuit diagrams than business

descriptions and that are useful as little more than doorstops‖.78

To quickly understand why this is the wrong technique to use, imagine an organization that maintains IT

investment data in an investment management system. (Notice that the prior sentence said ―investment

data‖ i.e. not ―metadata‖). Now imagine your EA repository, which should also record at least some

information about ―IT investments‖. Some of the Investment data in your EA repository will, of

necessity, be the exact same data as in the portfolio management system.

Is the information in the EA repository ―metadata‖? If you answered ―yes‖, then why is it ―data‖ in one

database (portfolio management system) but ―metadata‖ in another database (EA repository)? The

answer should be obvious: It‘s not metadata. It‘s data!

Now, imagine the people who enter information about IT investments into the portfolio management

system. Imagine them, when they want to add a new investment, dragging little boxes onto a diagram and

then linking these boxes with other little boxes to represent the investments‘ relationships to other data.

Now imagine these users in open rebellion because they think it‘s a pretty stupid way for them to have to

enter and maintain the information about IT investments.

Unfortunately, that‘s exactly how many or most EA repositories are being populated: ―dragging little

boxes and lines onto diagrams‖.

We should know better.

(See Appendix C: EA Modeling Used the Wrong Paradigm, which provides a fuller explanation.)


APPENDIX C: EA MODELING USED THE WRONG PARADIGM

"In presentations we have railed against traditional IT architecture efforts for their remoteness

from the reality of the business and their heavy reliance on mind-numbing detail represented in

charts that look more like circuit diagrams than business descriptions and that are useful as little

more than doorstops."

– Enterprise Architecture as Strategy: Creating a Foundation for Business Execution79

In one sentence, the authors of this quote perfectly described many, possibly even most, Federal

Enterprise Architecture efforts: ―remote from the reality of business‖, producing ―… charts that look

more like circuit diagrams than business descriptions and that are useful as little more than doorstops.‖

There‘s a shockingly simple reason why the main products of so many Federal Enterprise Architecture

programs are useless charts that deliver very little of value to their organizations:

Much, if not the vast majority of the “modeling” that is performed in federal EA programs is

using the wrong paradigm and the wrong tools for the task of populating the EA repository.

As outrageous as this claim will be to many practitioners, it can be shown that due to: (1) an industry-

wide confusion about metadata (see Appendix B: It‘s Not Metadata), (2) an imprecise and careless use of

the terms ―models‖ and ―modeling‖ (see Appendix A: The FEA Reference ―Models‖ Aren‘t Models), and

(3) the way that the Enterprise Architecture discipline evolved, many federal EA programs have used a

completely wrong ―modeling‖ paradigm, one that populates EA repositories slowly and ineffectively and

that produces volumes of quickly outdated diagrams that are almost never used.

Ultra-Brief, Selected History of Enterprise Architecture

To begin, it‘s useful to provide an ―ultra-brief, selected history‖ of Enterprise Architecture and the way

that the discipline evolved. *

By the mid 1980‘s, information systems were increasing in both size and complexity, and organizations

were not only becoming increasingly dependent on these systems, organizations were also having greater

difficulty defining, integrating, and managing them.

During this period, the idea of information systems architecture was conceived as a means to

methodically deal with this increasing system complexity. Simply stated, an information systems

architecture is an overarching ―… logical construct‖ (or architecture) for defining and controlling the

interfaces and the integration of all of the components of the system. 80

In 1987 John Zachman of IBM wrote a seminal article, ―A Framework for Information Systems

Architecture‖, in which he proposed a descriptive framework for organizing information systems

architectures (i.e. they were not yet enterprise architectures). Zachman based his framework on a logical

analogy between information systems architectures and other ―traditional‖ architectures, such as those

used for the building trades and manufacturing.

* This ―ultra-brief, selected‖ EA history has been written to be as concise as possible. In so doing, the history has

been simplified, but I believe not at the expense of accuracy.


Although Zachman‘s early thinking ultimately led to the concept and discipline of Enterprise

Architecture, his original article was limited strictly to architecture. 81

(Specifically, while Zachman very

briefly mentioned that there is a relationship between architecture and strategic planning, he expressly

limited the paper‘s context to only the architectural (and thus technical) aspects of information systems

architecture.82

)

Of note, Zachman‘s original thinking about information systems architecture did not include IT planning,

business alignment, or IT resources management; these were only later incorporated into the broader

discipline which became known as Enterprise Architecture.

Finally, Zachman focused much of his discussion on what he called ―architectural representations‖, or the

diagrams that are created for both traditional architectures and for information systems. For information

systems, these diagrams were largely the data and process model diagrams that had been in use for

decades , and that were (or should have been) created as part of the normal systems development process.

Zachman collectively organized all of these diagrams into his framework.

The details of the Zachman Framework are not relevant to this summary.

However, what is relevant is that because Zachman‘s original information systems architecture was

almost completely oriented around the technically-oriented diagrams created by the traditional system

development modeling paradigm, early Enterprise Architecture initiatives mimicked this and began

creating the same types of diagrams. Thus EA programs began ―modeling‖ and creating technical (i.e.

not ―organizational‖) system development diagrams.

To do so, they used the same modeling tools and techniques as had been used for system development.

Furthermore, because system development modeling (particularly data modeling) ―worked with

metadata‖, EA practitioners incorrectly assumed that their main task was also to ―work with metadata‖.

To this day, many EA initiatives still – incorrectly – fixate on diagrams, and operate under the assumption

that they‘re ―working with metadata‖.

Two Types of “Modeling”

Here‘s the fundamental problem: “modeling the enterprise” is not the same thing as “modeling a

system”.

Using ―Investment‖ as a specific example of an item (entity) that should be found in both an Investment

Management System and an Enterprise Architecture management system (e.g. an EA repository), we‘ll

review how Investments would be modeled and populated in each.

First, here is how we would model the Investment in the Investment Management System using the

traditional data modeling paradigm:


A single box is used to diagrammatically represent the entity (or object) named ―Investment‖ for which

data will be maintained. It’s critical to recognize that in a traditional data model, the box that

represents a data entity only defines or “declares” a data type – we don’t know whether there will

be one or one million instances of that data type entered into the actual system. With a single box

represented in a diagram, we‘ve ―modeled‖ the Investment. *

Once the physical database has been created, the Investments (plural, and actually Investment instances)

would be populated into the Investment Management System via one or more screens presented to users

that allow them to enter Investment data. The entry of this data will appear seamless to the user, who

(usually) knows nothing of the behind-the-scenes data modeling and the diagram that was likely created

during the design of the system. So, for the Investment Management System, investments are populated

just like any other data.

One thing is certain: to add new Investments to the system, the user of the Investment

Management System sure won’t be dragging little “Investment boxes” from a toolbar to a diagram

on the screen.

Which brings us to the way that Investments are incorrectly ―modeled‖ into an EA repository (they‘re

actually being populated):

Unlike the Investment Management System user, because the EA ―modeler‖† thinks he is ―doing

modeling‖ and has been given a modeling tool to perform this job, he will perform the job as if doing

traditional data modeling. He will ―model‖ by ―adding boxes to a diagram‖, just like traditional data

modelers have done for decades.

For each new Investment to be added, the EA modeler will:

1. Find and open the proper diagram where Investment occurrences are to be added

2. Create a new Investment occurrence by dragging a new ―Investment box‖ from a toolbar

onto the diagram

3. Double-click or in some other way open the box so that the detailed information about the

Investment may be entered (Investment Name, Creation Date, Budget, Project Manager, etc.)

4. Close the box to save the Investment data

5. Define relationships to the Investment by dragging lines between the just-created Investment

box and up to hundreds of other boxes that represent instances of other data types (e.g.

Applications, Projects, Segments, etc.)

6. Optionally, realign or reorganize all of the Investment boxes to put them in the proper order

or improve the visual appearance.

An example of the resulting Investments diagram is shown below.

* To simplify the discussion, we‘ve dispensed with the specification of attributes, keys, etc.

† In almost all cases, the term ―modeler‖ for doing EA work is a bit of a misnomer. Although in a rough sense he or

she may be ―modeling the enterprise‖, the work that is actually being performed is the same work being done in the

hypothetical investment management system: the entry and maintenance of investment data.


Figure 18: Incorrect Use of “Data Modeling” to Populate EA Repository

But how useful is the above diagram? Can we perform a query on the it? Would a non-technical

manager want to use the diagram? (Would he know how to?) Wouldn‘t a simple list be more effective?

What has happened? Here‘s the cause of the problem:

“Real” data modeling doesn’t instantiate data, but “enterprise modeling” does.

The EA modeler has used a traditional, manual data modeling technique to populate the EA repository,

but it‘s the wrong technique to use. Populating an EA repository this way is a slow, tedious, and

ineffective process that is prone to error and that produces mountains of useless diagrams.

Another problem is that the data, being manually entered, becomes out of date very quickly – almost

always long before an Enterprise Architecture is actually delivered for use.

A final problem is that the data, once entered, is almost useless because it‘s ―tied up in a diagram‖. How

useful is the above diagram to anyone who wants to perform even a simple analysis on the financial data

residing in the Investments in this diagram?

The answer should be clear:

The diagrams produced by most EA programs are almost completely useless to any potential user

of the EA system, in particular anyone who has little or no background in “modeling” or

information technology in general.

So, the problem is that the typical method used to enter data into an EA repository is based on an

incorrect paradigm (traditional data modeling), and it doesn‘t produce usable information.

What can be done?

First, it must be recognized that, contrary to the belief of many practitioners, what is being populated into

EA repositories is not metadata*, it‘s simply data, and the EA repository is a database, in most ways just

like databases defined for other information systems. This in turn is important because by recognizing

that an EA repository is being populated with data leads to another sometimes-overlooked recognition: an

Enterprise Architecture is actually a populated database, in most ways just like any other business system

database.

* See Appendix B: It’s Not Metadata


Second, we must then recognize that the use of traditional modeling techniques for the population and

maintenance of most* Enterprise Architecture data is the wrong method. Therefore, as much as possible

the use of diagrams for the entry and maintenance of EA data should be discontinued.

Third, as much as possible, discontinue the use of manually entered data. Instead, use data warehousing

and ETL (Extract – Translate – Load) techniques and programmatically retrieve as much data as possible

from other Sources of Record.

Finally, instead of ―tying up EA data‖ in diagrams, the data should be defined and entered into a normal

database (almost definitely relational, but conceivably a dimensional database).

* There are a few limited cases where the use of diagramming may be appropriate, for example where actual systems

development-type models are being created or re-created.


APPENDIX D: WHY FEAMS FAILED

Note: FEAMS is briefly mentioned elsewhere in the main body of this report, most significantly in these sections:

A Typical EA Program at Most Federal Agencies

Creation of Federal EA Repositories: Multiple Attempts Fall Short

Appendix E: Related Attempts to Create Federal EA Repositories – Additional Information

These sections don‘t provide information about the underlying reasons why FEAMS failed. This appendix goes into

further detail and provides information about why FEAMS was rejected by many agencies and why it failed after

only a bit more than one year of operation.

FEAMS (the Federal Enterprise Architecture Management System) was created to serve as the federal

government‘s integrated, government-wide EA repository. It began operation in late 2004 and was closed

a little more than one year later, in April 2006.

During this time, the repository was almost completely unused,83

and many agencies rejected FEAMS

itself (the federal level repository) and / or its underlying software product, EAMS, a GOTS product

available for agency-level use. In at least one occasion, even when directed by OMB to use FEAMS, an

agency declined to use it.*

As many other agencies found, both EAMS (the software product) and FEAMS (the federal-level system)

were cumbersome to use, difficult to input or retrieve data, and offered no way to perform analysis on the

underlying data.

FEAMS ultimately failed for several reasons. Some of these reasons were subtle and therefore somewhat

harder to recognize and fix, but others were obvious and should have been easy to diagnose and take

remedial actions.

Two fundamental problems with FEAMS‘ original inception doomed it to failure from the beginning.

These were:

1. Confusion about what the FEA Reference ―Models‖ were

2. Confusion about what to data to populate into FEAMS

These problem areas are examined next.

Confusion About What the FEA Reference “Models” Were

When FEAMS was introduced to the federal EA community and rolled out for actual use, the

documentation and explanations about the new federal EA repository usually included a new part of the

federal EA, the FEA Reference Models. As shown in Table 15 below, OMB expected FEAMS to be

populated with agencies‘ reference model data, and well as other EA data. (Highlighting has been added

to emphasize references to data expected to be populated.)

* See page 16.


Table 15: Descriptions of What to Load into FEAMS

What Should be Loaded into FEAMS?

“FEAMS is being used to house and maintain the FEA and associated reference data. … *It+ will contain all

FEA reference models.”84

“In addition to storing the FEA reference models, …. FEAMS will include general information on agencies’ IT initiatives. Initiative alignment to the BRM Lines of Business that they support, the service components and technology that these components leverage, and the performance metrics that they use in achieving performance objectives will be presented. It is OMB’s goal that FEAMS will eventually include information on all of the appropriate capital assets in which federal agencies invest.”

85

“The Federal Enterprise Architecture reference models and related information are being stored in FEAMS. FEAMS currently includes general information on Agencies' major information technology (IT) initiatives, and aligns the initiatives to the BRM Lines of Business they support.”

86

“The Federal Enterprise Architecture Management System is OMB’s software tool and repository in which agencies capture their FEA-related information and submit it to OMB. OMB then can combine all agencies’ information and query the information to look for cross agency initiatives, redundancy, and performance comparisons.”

87

Unfortunately, and as described in detail elsewhere in this document (see footnote*), confusion about

what the FEA reference models actually were prevented an accurate understanding about them. And

when it came time for agencies to populate FEAMS, what they were supposed to populate as ‗reference

model data‖ was entirely unclear.

Even the CIO Council and the FEA PMO seemed confused how the reference models should be

represented in FEAMS. One document developed jointly by both88

said that the reference models could

become an operational architecture by ―converging‖ them with agency architectures:

―Turning the reference models, to date mostly a collection of taxonomies, into an operational

architecture could be done by converging the reference models with agency enterprise

architecture via the Federal Enterprise Architecture Management System (FEAMS) ….‖89

But the reference models were misnamed and were actually only taxonomies that classified certain EA

object types including Investments, Service Components, Technology, Data, and Performance Measures.

(See Table 13: Likely Entities for the Five ―Reference Taxonomies‖.) As taxonomies, these reference

models could not possibly have been ―turned into an operational architecture‖, nor could they have been

independently populated as was conceptualized as shown in Figure 19. They could only have been

populated as attributes of EA objects defined as part of the FEAMS database.

To see why, imagine that Figure 19, below, was instead a diagram showing how data about new species

that were being discovered and classified by different teams working independently was going to be

integrated together. For this imaginary scenario, we would replace the three ―FEA Reference Models‖

blocks with ―Linnaean Taxonomy‖. But capturing the Linnaean taxonomy values is meaningless without

populating the actual entity being classified, i.e. either an animal or plant. In the same way, capturing

BRM, SRM, TRM, DRM, or PRM classification values without populating their respective EA objects is

meaningless. For example, what value is there in populating BRM entries ―Services to Citizens‖,

―Health‖, and ―Illness Prevention‖ unless these values are associated with an Investment which it is

classifying?

* See ―Exhibit 2: The FEA Reference ―Models‖: Tragically Misnamed‖, and Appendix A: The FEA Reference

―Models‖ Aren‘t Models


Figure 19: Incorrect Representation of Reference Model Data in FEAMS90

This confusion about what to enter into FEAMS as reference model data was compounded by general

confusion about what data to enter at all, discussed next.

Confusion about What Data to Populate into FEAMS

With the problems that were caused by the misnaming and consequent misrepresentation of the FEA

reference models, it is somewhat understandable that they might be conceived as separate ―things‖ to be

captured and entered into FEAMS.

But the source of the second problem, the confusion about what data agencies were supposed to populate

into FEAMS was glaringly obvious: the types of data that FEAMS was supposed to contain was never

adequately defined or communicated. More specifically, no common data model for the FEAMS

database was ever formally specified and communicated to the federal EA community. *

With no data specification, agencies didn‘t know exactly what types of data they were supposed to

contribute to the integrated, federal database. And with no formal data model – which would have

specified which entities and attributes that could be populated in FEAMS – agencies couldn‘t have

contributed data even if they knew what types of data were expected.

* If data specifications or a data model was ever published for FEAMS, I was unable to find any reference to them.


APPENDIX E: RELATED ATTEMPTS TO CREATE FEDERAL EA REPOSITORIES

– ADDITIONAL INFORMATION

The section titled ―Creation of Federal EA Repositories: Multiple Attempts Fall Short‖, discussed several attempts

by OMB to create repositories to collect EA-type information at the federal level. Additional information on each of

these efforts is provided in this appendix.

Federal Enterprise Architecture Management System (FEAMS)

The first attempt at building a federal-wide Enterprise Architecture repository was the Federal Enterprise

Architecture Management System, or FEAMS, which was released in 2004 for government-wide use. 91

Unfortunately, FEAMS never really worked and delivered little, if any real value.

After only two years, with disappointing results, minimal use, and oftentimes outright rejection by

agencies*, OMB closed FEAMS in April 2006. It was to be replaced by another repository, the

Component Organization Registration Environment (Core.gov), despite the fact that Core.gov was

developed to serve as a federal software components registry, not as an ―EA repository‖.

One trade press article that reported on the shutdown of FEAMS also raised the uncertain status of

Core.gov: ―...the Federal Enterprise Architecture Program Management Office is shutting down one IT

project repository that wasn‘t being used in favor of another that is hardly being used.‖ 92

FEAMS was a major failure of the federal government‘s EA efforts because it was caused by what should

have been obvious: The exact types of data that FEAMS was supposed to contain was never precisely

defined or communicated, and thus no common data model was specified and communicated for the

database. With no data specification, agencies didn‘t know exactly what types of data they were

supposed to contribute to the integrated, federal database. With no common data model, agencies

couldn‘t have contributed data even if they knew what types of data were expected. For additional

information, see Appendix D: Why FEAMS Failed

Although certainly arguable, OMB‘s decision to move the functionality of FEAMS to Core.gov, a

repository that had been created for a completely different purpose, appears not to have been a good one,

for three reasons: (1) little if any of FEAMS‘ original functionality or data was moved to Core.gov, (2)

the Core.gov system, built for the special purpose of registering software components, served essentially

only a subset of FEAMS‘ functionality, and (3) Core.gov also failed and never met its original purpose.

Discontinuing FEAMS ended the government’s best chance for defining and populating a federal

EA repository and with it the means to implement a true federal enterprise architecture.

CORE.gov

The second attempt at developing a federal-wide EA repository was the Component Organization and

Registration Environment, or Core.gov, launched by the CIO Council in March 2004. 93

Although

Core.gov was initially launched as a special purpose repository (serving as the federal government‘s

integrated registry of software components), it later became the ―official‖ EA repository in April 2006,

after FEAMS was terminated.

* As one example, the Department of Justice rejected FEAMS despite OMB‘s requirement to use it. See page 23 for

details..


Unfortunately, like its sister repository, FEAMS, Core.gov never really worked and delivered little, if any

real value.

Although Core.gov is technically still in use, its current function is a far cry from its original purpose.

Originally planned to be a federal-wide repository to centrally manage component development,

registration and re-use for sharing components across the government, during its six-year lifetime it has

been renovated or re-envisioned at least twice:

By fall of 2005, eighteen months after its rollout, Core.gov was revamped and its contents

were completely thrown out. Chief Architect Dick Burk explained the decision to re-start:

―…the contents of Core.gov have been only ambiguously useful because of the wide range of

artifacts posted within it.‖ ―What we‘ve decided to do is throw it all out.‖ 94

By 2007, some three years after its introduction, Core.gov still wasn‘t providing value.

Despite having about 1,800 registered users, the system wasn‘t meeting its goals and wasn‘t

driving best practices in component sharing.95

In August 2007, OMB decided to re-envision Core.gov, changing its fundamental purpose

from ―component registration‖ to ―collaboration environment‖ for enterprise architects.

By 2010 the Core.gov web site had declined to the point where questionable, non-EA

communities like ―bike and build‖, ―NC to SD Route‖, and ―Violence in the Workplace‖ had

been added to it.*

In summary, after six years in operation, Core.gov, like FEAMS, failed to meet its original objectives.

Although Core.gov is technically still in operation, it appears to be adding no value to Federal Enterprise

Architecture efforts.

The Federal Transition Framework (FTF)

Although not generally recognized as such, the third attempt at building a federal-wide EA repository was

the Federal Transition Framework which was released for government-wide use in July 2006.96

(The first

two attempts were FEAMS and Core.gov.)

The FTF was a special purpose EA repository, developed to maintain EA data strictly for cross-agency

initiatives. That the FTF was indeed an EA repository, in many ways very similar to FEAMS, can be

recognized by comparing the original goals for the FTF with those of FEAMS. Underlined words or

phrases are identical or nearly identical to the characteristics or data elements for FEAMS:

Increase the alignment of agency enterprise architecture with federal IT policy decisions or

other forms of official guidance

Increase sharing and reuse of common cross-agency business processes, service components

and technology standards

Increase collaboration through agency participation in cross-agency communities of

practice97

The Federal Transition Framework (FTF) is the means for uniformly cataloguing reusable

assets developed through cross-agency information technology (IT) initiatives 98

* No doubt that these Core.gov communities are all worthy, but their presence on Core.gov is indicative.


It‘s important to recognize that the FTF was a limited attempt at implementing a federal-wide EA

repository, and was actually a subset of the functionality that should have been implemented in the first

repository, FEAMS. Had FEAMS been successful, the FTF would never have had to be separately

developed.

While FEAMS had a web-enabled interface that would have allowed users to explore FEAMS data,* it is

puzzling why no such interface was ever developed (or even envisioned) for the FTF. The lack of a user

interface severely crippled the FTF. And while FTF data was available to agencies as XML documents, it

was left to individual agencies the task of actually making the data useful. Few agencies bothered.

Finally, unlike FEAMS, the FTF actually collected data (not all of it useful), and created a ―catalog‖ of

the Cross-Agency Initiatives. But because the data was locked up as XML, the FTF catalog wasn‘t much

better than a Word document. Ironically a Word document would have been much less expensive to

develop and would have delivered equivalent functionality.


Although the Enterprise Architecture Segment Report was created for segment architecture compliance

reporting to OMB99

, because it also collects EA data (much of the same data that was supposed to be

maintained by FEAMS and that was also collected in Exhibits 53 and 300), it is included as one of the

―EA repository / data collection efforts‖.

The most recent EASR Instruction Guide, perhaps unwittingly, even raised the similarity if the EASR to a

federal EA repository by linking the EASR to the original goal of ―shared architectures‖ and stating that

EASR and the FSAM (another ―EA data collection effort‖) are both tools to establish these shared

architectures:

―A long sought goal of the Federal Enterprise Architecture (FEA) has been the creation of shared

target architectures among federal agencies. The initial e-Government Initiatives and ―Lines of

Business‖ defined shared architectures for several business-specific areas, based on the then level

of maturity of the FEA. The Federal Segment Architecture Methodology (FSAM) and the

Enterprise Architecture Segment Reports (EASR) provide the tools for federal agencies to take

the next step towards establishing shared target or ―to-be‖ architectures for key, cross-boundary

government functions.‖100

Finally, as explained in the next section, the relationship of the EASR to the other fragmented parts of the

federal Enterprise Architecture (FTF, FSAM, FEA Taxonomies, Exhibit 300) has recently been

recognized.

Recent Repository Work

Detailed information about recent work done by the Object Management Group‘s Government Domain

Task Force (GovDTF) is currently limited. But a two paragraph summarization of this work from a

March 2009 GovDTF document shows that there is now (finally) recognition that there is a relationship

between the efforts described on these pages:

* Unfortunately, for a number of reasons, not enough data was ever collected from federal agencies to populate

FEAMS, so although it had a user interface, there wasn‘t enough data to actually use it.


―In 2008, OMB's Chief Architect Kshemendra Paul, successor to Mr. Burk, continued the

OMB/OMG relationship with work supporting the Federal Segment Architecture Methodology

(FSAM).

The original intent was to produce a metamodel standard focused on the Enterprise

Architecture Segment Report (EASR) template, which had an existing data model. A team

including the original developers of the EASR, OMB representatives, and vendors was assembled

to define the metamodel, formally modeled using the UML as was done for the Federal Transition

Framework. While analyzing the supplied data model, it was determined that the scope of the

metamodel required expansion to address normalization with existing specifications, including

the OMG Metamodel for the Federal Transition Framework (FTF) and the OMB‘s FEA

Consolidated Reference Model and Exhibit 300.

This is work that is underway. The joint team has already extended the concepts addressed by the

EASR template‘s initial data model on a path toward a foundational semantic model that would

enable agencies to maintain a single information set, and then purpose that information in

multiple ways. For example, an agency could maintain a single information set and use it for

generating the EASR submission as well as other artifacts supporting the FSAM.‖101

[emphasis

added]

Summary of Object Types Defined by Different Repository Initiat ives

Table 16, next, shows the EA object types that were to be collected by each initiative, along with the

object types that are being proposed by this paper for a common, federal-wide EA repository model that

will allow EA data to be shared across departments, agencies, and bureaus across the federal government

(in right-most column).

(Note that because the EA data types for FEAMS were not well-documented or communicated to

agencies, so only those object types that could be found in FEAMS computer screen facsimiles are

included in the table.)

Table 16: Object Types Defined by Different Repository Initiatives

EA Object Types / (Entities)

FEA

MS

Co

re.g

ov

(1st

Ve

rsio

n)

FTF

EASR

FSA

M

Pro

po

sed

by

This

Pap

er

Federal Organizations (FTF: “Party”)

X X X X

Cross Agency Initiatives (FTF Initiatives)

X X X

Agency Plans X X

Plan Objectives X X

Applications X

Business Functions X

Business Processes X X

Data Stores X X

Groups X

Hardware Products X X


EA Object Types / (Entities)

FEA

MS

Co

re.g

ov

(1st

Ve

rsio

n)

FTF

EASR

FSA

M

Pro

po

sed

by

This

Pap

er

Industry Standards X X

Investments (“Initiatives”) X (x) X X X Investment Budget Lines X

Exhibit_300s X X

Locations X

Performance Goals X X X

Persons X

Person Roles X

Agency Positions X

Projects X

Role Types X

Segments X X X

Servers X

Service Components X X X X

Skills X

Software Products X X X X

OTHER OBJECT TYPES (Not yet included in “Proposed” object types)

Data Exchange Package X X

Exhibit 300 Milestones X

PART Data X X

Guidance X

Community of Interest X

Deliverable X

Business Requirement X

Mandate X

Outcome X

Query Point X

Component Repository X

SmartBUY Agreement X

Object Classifications (FEA reference models/Taxonomies

BRM X X X X

SRM X X X X X

TRM X X X X X

PRM X X X X

DRM (x) (x)


APPENDIX F: THE DATA REFERENCE MODEL, BIRTHED IN CONFUSION

Note: To better understand this analysis of the Data Reference Model, the reader may first want

to review Appendix A: The FEA Reference ―Models‖ Aren‘t Models beginning on page 74 and

Appendix B: It‘s Not Metadata on page 83.

The Data Reference Model is both a direct casualty and proof of the confusion and misunderstanding that

this paper has shown is so widespread throughout the entire FEA.

While the DRM‘s many development errors and resulting problems could provide enough content for a

separate paper (and perhaps someday will), the major problems with this data taxonomy have already

been discussed elsewhere in this paper, so will only be summed up in this appendix. (These other

discussions of the DRM can be found on pages 14, 37, and 77.)

While the assertion that the Data Reference Model was indeed ―birthed in confusion‖ is likely to be

controversial (and hotly contested by some), the results of this confusion are readily apparent:

Model or Taxonomy?

It is clear that the DRM developers became confused about whether their objective was to define a model

or a taxonomy.

Although the developers specifically (even emphatically) declared the DRM to be a

taxonomy, they were so focused on creating a ―model‖ that they entirely overlooked the

actual definition of the taxonomy, complete with classification values).

Instead of just defining a hierarchical taxonomy similar to those that had been defined for the

other four FEA taxonomies, the DRM developers created something that seems to be more of

an (incomplete) data administration capability that includes both its own separate data model

and a rough set of data administration standards.

The DRM metastasized far beyond what it should have been – a simple taxonomy to classify

agencies‘ data – into a ―confused, bloated, useless monster‖.

Its creation was so confused that its ―DRM Implementation Framework‖ really was just the

document‘s table of contents re-expressed as a two-dimensional matrix (i.e., a table).

The DRM is Very Different from the Other Reference Models

Another way to see that things got confusing is to compare the differences between the DRM and the

other four reference models. Even a cursory examination of these differences shows that, at best the

DRM is very different from all the others; and at worst that its development very much ―went down the

wrong track‖:

The DRM is the only one that failed to define an actual taxonomy (with values)

The DRM is the only one that defined its own data model (actually three of them!)

The DRM is the only one that had multiple parts, or ―standardization areas‖ (data description,

data context, data sharing)


The DRM was developed both after and almost completely independently of the other

―models‖. It was also developed by an entirely different group of people.

The DRM is the only one that wasn‘t part of the first version of the Consolidated Reference

Model (a high level description, but no taxonomy was added in later versions)

The DRM is the only that was never populated in the Exhibit 300 (except for perhaps a single

year, the DRM wasn‘t even defined to the 300)

The DRM is the only reference one that is not included in the ―FEA Reference Models‖ XML

document created by OMB.

Other Considerations

Two final items are, if not proof, then at least strong indicators that suggest that development of the DRM

was indeed confused and that this confusion led to a creation that many in the government ultimately

found unusable:

There is scant, if any, evidence that can be found where the DRM has been successfully used

in any federal government. (If it‘s there, I haven‘t been able to find it.)

Development of a federal Information Sharing Environment (ISE) was mandated as part of

the Intelligence Reform and Terrorism Prevention Act (IRTPA) of 2004 ―… for the sharing

of terrorism information in a manner consistent with national security and with applicable

legal standards relating to privacy and civil liberties.‖63

Two versions of the document that defined the ISE were released, the first in May of 2008,

the second in June of 2009. Although not offered as uncontestable proof, it appears that

those responsible for the ISE found the DRM to be unusable: the DRM was part of the ISE‘s

first version in 2008, but all references to it had been removed in the second version in 2009.


APPENDIX G: “DIAGRAM CONFUSION”

Exhibit 6: A Confused Understanding and Exhibit 7: Confusing / Misleading / Incorrect FEA Diagrams

discuss the confusion in the industry and the multiple and often dissimilar beliefs that are held by

different EA practitioners. This appendix describes a personal experience that illustrates the differences

of opinion between EA practitioners, even on a fundamental item where agreement should be a given.

While doing research for this paper, I wanted to get some feedback or confirmation about what I saw as

anomalies in one of the FEA PMO‘s most basic diagrams (see Figure 20, below). My original post is

provided below, followed by the responses of three individuals who replied.

Note that I‘m neither agreeing nor disagreeing, nor criticizing the ideas or opinions any of the three

people who replied; only presenting an example that illustrates the lack of a common and shared

understanding of the elements of the Federal Enterprise Architecture.

My original post:

―I'm doing some research for an article about the Federal Enterprise Architecture, and would like to get

some feedback on something.

In reviewing some of the documentation about the FEA models, I see a diagram that graphically

illustrates these models.

Figure 20: “What Does this Diagram Really Represent?” 102

To me, this diagram doesn't seem to accurately reflect the relationships between the different models. I'd

like to see if I'm missing something, or whether my assessment is correct.

First, the document conveys a hierarchy between the models, by the top-to-bottom placement of the

models in the following order: PRM, BRM, SRM, DRM, and finally the TRM. I don't think this is an

accurate depiction.

For example, the DRM is shown directly under the SRM, but shouldn't the DRM be subordinate to, or

hierarchically organized according the BRM? (The highest level of the DRM is based on BRM

classifications.)


I can't see why the PRM would be the top-most layer. Shouldn't the PRM be at the bottom, or if nothing

else, shouldn't it at least be below the BRM, as one of the PRM's measurement areas is *based* upon the

BRM?

There also two vertical arrows at each side of the diagram, one marked "Performance and Business

Driven", the other "Component-Based Architectures". While I certainly understand and appreciate the

significance of these two concepts *generally* to "Federal Enterprise Architecture", I don't think that they

are specifically useful or relevant to the "FEA Models" diagram as shown. If these are valid, wouldn't

"Customer Centric" or any of the other "FEA buzzwords" also be just as valid on this diagram?

This diagram doesn't make sense to me... Any input and discussion would be appreciated.‖

Response 1

I don't think that the authors of the FEA RMs intended for this to be interpreted as a hierarchy. Each RM

gives a different perspective, but the architecture needs to be viewed as an integrated cross-walk of all the

RMs in order to understand the what, why & how well an IT investment is doing.

The meaning really is that of a workflow. Specifically, federal business managers identify a performance

improvement need. This need is then mapped to at least one business, the business(s) is then mapped to

services which are implemented through technology. The Data element applies if the services exchange

data with other services beyond your enterprise.

In this regard, following the FEA RMs in the order indicated by the diagram is a recipe for executing the

processes necessary for completion of the OMB 300 process.

The meaning of two arrows, in my view, is the following the. "performance & business driven" simply

indicates that if you follow the workflow then you will build an IT investment plan that is driven by really

performance needs against agency business requirements, and not be driven by technology drivers that

have no real business need.

"Component-based Architectures" is less clear to me, but I interpret it as indicating that this process is not

applied once at an enterprise level, but many times at the component level.

Response 2

I tend to agree with Steve's reply that the FEA RMs indicate a broad workflow rather than a hierarchy.

At the same time, I think the following 3 questions are applicable even in the workflow context.

1) Talking of the PRM, I've seen a few EA documents following your suggestion and discussing PRM at

the end. It is like saying, "this is my architecture, and let us find out what all we can achieve and provide a

measurement metric to those possibilities" - a case of the tail wagging the dog.

I see it more as a model that forces us to take a deeper look at the Agency's Strategic Management Plan

and Goals.

i) Those goals can be translated (or dulled down) to the top two layers of the PRM, the Mission and

Business Results (MBR) as well as the Customer Results (CR) that the agency will report and its

leadership will be measured and held accountable for.

ii) There is the need to engage the business (particularly the leadership of the various offices, programs,

directorates within the agency) to identify the Processes and Activities (PA) that will help achieve the


MBR and CR, arriving at PA goals.

iii) This is a challenge for the technologists. Now, IT has to identify the goals it should achieve in order to

help the various offices, programs, and directorates to achieve their PA goals. Of course, this will

eventually be extended to all Govt. Resources.

So, having set the goals up front, a gap analysis across the various layers of the PRM needs to be done.

- What business processes affect the agency's ability to achieve its PA goals (or MBR / CR goals)?

- What changes can and should be done to the business processes and activities to meet these goals?

This will be followed by a similar analysis on the technology front.

- Which application or technology component is (or likely to be) an impediment in helping the business to

achieve the IT goals (or the PR goals, and thus indirectly the MBR / CR goals)

- What changes can and should be done to meet these goals?

- What changes needs to be done to align with the changes in the business processes and activities?

So, the target state Architecture is being derived from the Gap Analysis being performed against the

PRM. So, PRM deserves to be done early in the process and not towards the end.

2) Talking of the DRM, there is definitely a business view of the data (and the earlier version of the FEA

RMs had it this way). But at the same time, there is also the application view of the data. And, there is

value in viewing the enterprise data in both these contexts (and I'd like to think it is not one or the other,

but both).

To remove ambiguity, I use the two terms -

- information (a very high level business view) and

- data (a little-bit drilled down view of the "information")

Information will be discussed as part of the Business Architecture itself. Data will be discussed in the

DRM section for each Service / Application that supports the corresponding business. This helps me to

have both the views and analyze the relationship between data and business (indirectly through the link

between data and information) as well as data and applications / services, to come up with any

recommendation on sharing, re-use, and other such optimizations.

3) Talking of the TRM, I believe the diagram does reflect the point you are making. The TRM is

connected to the SRM directly and not to the DRM. Even if you take the hierarchical view, the TRM and

DRM are siblings under SRM.

But, taking the broader "workflow" perspective, I see the Technology Architecture as applicable to both

the SRM and DRM. But, all the data management services are defined within the SRM and the

technology supporting the data will be captured through that.

In terms of relationship, I view the Reference Models something like this -

PRM

|

BRM

___|___

| |

SRM -- DRM

|______|


|

TRM

I view the FEA diagram more as a broad guideline to the workflow rather than

a hierarchy or something that needs to be strictly complied.

Response 3*

EA uses reference models for the engineering of reuse and interoperability. Based on this assumption, the

FEAPMO reference models, in my humble opinion, is a hierarchy. In a stove pipe system, standards and

patterns is not a concern. In an EA environment where systems reuse and shared resources are needed to

learn from the others experience, standards and patterns are critical.

EA has initially used the TRM to organize standard profiles and later on the concept has extended to the

PRM, BRM, SRM, and DRM following the IBM pattern approach. The idea is that for a line of business,

we can find a pattern and standards of IT solutions. For example, all the banks have similar business

processes (BRM), data model (DRM) and they can use similar application services (SRM) and

technologies (TRM) based on their performance requirement (PRM). Therefore, based on the line of

business in the enterprise, we can find the patterns of common solution and IBM are expert in this area.

Based on this description, I suggest that the FEAPMO reference models are hierarchical.

* Some minor editing done for spelling and grammar


APPENDIX H: SUMMARY OF OCTOBER 2010 FEDERAL EA COMMUNITY

SEMINAR

Federal Enterprise Architecture Community Seminar. October 1, 2010 Summary Approximately 80 senior architects, CIOs, and CTOs from throughout the federal government convened

on October 1, 2010 to discuss actions that the federal Enterprise Architecture (EA) community needs to

take to be of value to agency line of business owners, program offices, and leadership. The community

has felt recently that it has been underutilized and that there is an overall misconception of their role.

Several panels, discussions, and question/answer sessions gave community members a chance to

express their ideas and concerns. During the seminar, five overall themes arose:

1. Fundamental Change

The EA community realized they are not as influential and successful as in the past. Vivek

Kundra said that the federal EA community has been often focused on compliance

documentation at the expense of supporting mission improvements. The community realized it

has to change. Enterprise Architects need to be involved in agency strategy, business, and

budget planning sessions, not just focused on information technology. Trust needs to be built

between the agency CXOs, program managers, and architects.

Feedback from attendees reflected agreement on the importance of delivering tangible, mission

and outcome-oriented results. The time for a change has come. There is a window of

opportunity where the community feels it can make the change and be successful.

2. Success Stories and Value

The need to create a source of EA success stories and a set of program evaluation metrics to

reflect where value is created are items that came up throughout the meeting. Community

members felt that if there were more success stories available to them, convincing agency

leadership that EA can contribute to mission improvement would be easier. The EA community

needs to communicate better both internally and to agency leadership. Coming up with

marketing materials in a vocabulary that can be understood without much knowledge of EA will

help agency leadership become familiar with what EA can offer.

3. Where Does Enterprise Architecture Belong?

Currently, agency leadership often associates EA with IT and not with business or strategy.

Some community members felt that in part this was due to the EA function reporting to the

agency CIO and not the COO or CEO equivalents… or having stronger collateral relationships


outside of the CIO organization. The community felt that if the EAs were seen as a strategic

asset instead of an IT practice, the architects could add more value across the agency.

4. New Approach

Currently, there is a lack of coordination and clarity among federal sector architecture concepts

and practices. A number of community members expressed a desire to see a ‘common

approach’ to federal architecture be developed that could be adopted by civilian, military, and

intelligence agencies to promote the ability to better exchange architecture information and to

improve work being done on multi-agency, sector-wide, inter-government, and international

efforts. A new approach would need to be over-arching and include all aspects of EA practices.

5. Expanding Level of Scale

Expanding the existing levels of scale to include a Sector architecture and Government-Wide

architecture was well received. There was a healthy debate with questions including creation

and enforcement of standards at these levels.

Action Items The community discussed action items to be pursued over the next six months. These action items will

be worked on collaboratively by the community and will be reviewed by the Federal Chief Architect and

the AIC, as well as by Vivek Kundra and Mike Howell.

1. Updated approach

a. Supports commonality

b. Supports specific functional areas

c. New levels of scale (sector and government-wide)

d. Mission driven

e. Supports collaboration

f. Open standards

2. Example implementations

3. Communicating Value/Success

a. EA community

b. Examples of agency EA success

c. Measures from OMB

d. Overlooked areas

4. Role Clarification

Next Seminar The next Federal EA Community Seminar is tentatively scheduled for Friday, April 8th, location TBD.


REFERENCES

1. Andrues, Wes. The Clinger-Cohen Act, 10 Years Later: The Five Percent Solution. Government

Executive website: http://www.govexec.com/dailyfed/0706/071106cc.htm. July 11, 2006.

2. Chief Information Officer‘s Council. Architecture Alignment and Assessment Guide. Oct. 2000.

3. Chief Information Officer‘s Council. A Practical Guide to Federal Enterprise Architecture. 2001.

4. Chief Information Officer‘s Council. Federal Enterprise Architecture Framework. Sept. 1999.

5. Chief Information Officer‘s Council. Reference Model Maintenance Process. June 2005.

6. Chief Information Officer‘s Council. Service Component-Based Architectures. Version 2.0. June

2004.

7. Chief Information Officer‘s Council. Smart Practices in Capital Planning. Oct. 2000.

8. Chief Information Officer‘s Council. Summary of First Practices and Lessons Learned in

Information Technology Portfolio Management. March 2002.

9. Chief Information Officer‘s Council. What Every CIO Needs to Know About Metadata. Feb.

1999.

10. Daukantas, Patricia. OMB identifies common lines of business. Government Computer News.

March 15, 2004.

11. Evans, Karen S. The Federal Transition Framework (memo). July 6, 2006.

12. Federal Chief Architects Forum. ―Summary of Federal Enterprise Architecture Community

Seminar‖, October 1, 2010. Found at:

http://semanticommunity.wik.is/Federal_Chief_Architects_Forum/2010_October_1. Also

included as Appendix H: Summary of October 2010 Federal EA Community Seminar.

13. FEA Program Management Office. Federal Enterprise Architecture (FEA) / Draft Service

Component Reference Model (SRM) / Draft Technical Reference Model (TRM). (PowerPoint

presentation dated January 29, 2003.)

14. FEA Program Management Office. The Business Reference Model Version 2.0: A Foundation for

Government-wide Improvement. June 2003.

15. FEA Program Management Office. The Data Reference Model (DRM) Draft Version 1.0: Vol 1 –

DRM Overview. Jan. 2004.

16. FEA Program Management Office. The Data Reference Model Version 2.0. Nov. 2005.

17. FEA Program Management Office. Enabling the Vision of E-Government: Federal Enterprise

Architecture. (PowerPoint presentation given February 2004).

18. FEA Program Management Office. FEA Practice Guidance. November 2007.

19. FEA Program Management Office. Federal Segment Architecture Methodology (FSAM).

Version 1.0. January 12, 2009.

20. FEA Program Management Office. Suggestions for the Federal Enterprise Architecture (FEA)

Data and Information Reference Model (DRM). (PowerPoint presentation given January 2003,

Brand Niemann).

21. Federal Enterprise Architecture Certification Institute. A Graphical Guide to the U.S. Federal

Enterprise Architecture and its Components Relationships. URL:

http://www.feacinstitute.org/ea-news/documents/DraftFEALaminatebothsidesV2.0.pdf.

http://www.govexec.com/dailyfed/0706/071106cc.htm

http://semanticommunity.wik.is/Federal_Chief_Architects_Forum/2010_October_1

http://www.feacinstitute.org/ea-news/documents/DraftFEALaminatebothsidesV2.0.pdf


22. Gartner. Enterprise Architectures Provide Business Benefits Only When They're Used. April 4,

2008. ID No. G00131249

23. Gartner. Myth Busting: What Enterprise Architecture Is Not. April 4, 2008. ID No. G00155970

24. General Accountability Office. Air Traffic Control: Complete and Enforced Architecture Needed

for FAA Systems Modernization. Feb. 1997. Report number GAO-AIMD-97-30.

25. General Accountability Office. Executive Guide - Improving Mission Performance Through

Strategic Information Management and Technology. May 1994. Report number GAO/AIMD-94-

115.

26. General Accountability Office. Enterprise Architecture Use Across the Federal Government Can

Be Improved. Report number GAO-02-6. February 2002.

27. General Accountability Office. OMB Leadership Critical to Making Needed Enterprise

Architecture and E–government Progress. Report number GAO-02-389T. March 2002.

28. General Accountability Office. HUD Needs to Strengthen Its Capacity to Manage and

Modernize Its Environment. Report number GAO-09-675. July 2009.

29. General Accountability Office. Information Technology: A Framework for Assessing and

Improving Enterprise Architecture Management (Version 1.1). Report number GAO-03-584G.

April 2003.

30. General Accountability Office. Information Technology: Leadership Remains Key to Agencies

Making Progress on Enterprise Architecture Efforts. Report number GAO-04-40. Nov. 17, 2003.

31. General Accountability Office. Architecture Needed to Guide NASA‘s Financial Management

Modernization. GAO-04-43. November 2003.

32. General Accountability Office. FBI Needs an Enterprise Architecture to Guide Its Modernization

Activities. Report number GAO-03-959. September 2003.

33. General Accountability Office. Homeland Security: Efforts Under Way to Develop Enterprise

Architecture, but Much Work Remains. Report number GAO-04-777. August 2004.

34. General Accountability Office. The Federal Enterprise Architecture and Agencies' Enterprise

Architectures Are Still Maturing. Report number GAO-04-798T. May 2004.

35. General Accountability Office. DOD Business Systems Modernization - Long-standing

Weaknesses in Enterprise Architecture Development Need to Be Addressed. Report number

GAO-05-702. July 2005.

36. General Accountability Office. FBI Is Taking Steps to Develop an Enterprise Architecture, but

Much Remains to Be Accomplished. Report number GAO-05-363. September 2005.

37. General Accountability Office. Business Modernization: Some Progress Made Toward

Implementing GAO Recommendations Related to NASA's Integrated Financial Management

Program. GAO-05-799R. September 9, 2005

38. General Accountability Office. Homeland Security: Progress Continues, but Challenges Remain

on Department's Management of Information Technology. (Testimony Before Congressional

Subcommittees, Randolph C. Hite, Director, Information Technology Architecture and Systems

Issues.) March 2006.

39. General Accountability Office. Leadership Remains Key to Establishing and Leveraging

Architectures for Organizational Transformation‖. Report number GAO-06-831. August 2006.


40. General Accountability Office. Strategy for Evolving DOD‘s Business Enterprise Architecture

Offers a Conceptual Approach, but Execution Details Are Needed. Report number GAO-07-451.

April 2007

41. General Accountability Office. DHS Enterprise Architecture Continues to Evolve but

Improvements Needed. Report number GAO-07-564. -May 2007.

42. Grossman, Ira. The Chief Architects Forum and the Federal Enterprise Architecture Glossary of

Terms. (PowerPoint presentation given by CAF Chairman, May 3, 2005.)

43. Hagan, Paula J., Dr., (Ed). Guide to the (Evolving) Enterprise Architecture Body of Knowledge

(Draft). The MITRE Corporation. Feb. 6, 2004. (Note: Although it appears that this document

didn‘t progress beyond its draft form, based on MITRE‘s excellent reputation and on the value of

much of the contents that covered the history and components of the federal government‘s EA

program, it was decided to use the Guide as a legitimate reference.)

44. Haycock, Robert. FEA Program Management Office. Accomplishments and Next Steps.

(PowerPoint presentation dated March 26, 2003.)

45. Hinchcliffe, Dion. Fixing Enterprise Architecture: Balancing the Forces of Change in the

Modern Organization. Sept. 3, 2009. Ebiz.net website:

http://www.ebizq.net/blogs/enterprise/2009/09/fixing_enterprise_architecture.php

46. IT Governance Institute. Control Objectives for Information and related Technology (COBIT)

4.1. 2007. ISBN 1-933284-72-2.

47. Lao, Haiping. Developing the Enterprise Architecture Management Guide. Journal of Enterprise

Architecture. Volume 2. Number 3. August 2006.

48. Marakas, George M. Decision Support Systems in the 21st Century. Second edition. Prentice

Hall. 2003.

49. McDonough, Frank. Bush's legacy is Obama's uncertain mandate. Federal Computer Week

online. Feb 06, 2009. URL: http://fcw.com/articles/2009/02/09/mcdonough-what-now-for-

egov.aspx.

50. Miller, Jason. OMB begins last-round check of its architecture system. Federal Computer Week

online. Feb 09, 2004. URL: http://gcn.com/articles/2004/02/09/omb-begins-lastround-check-of-

its-architecture-system.aspx?sc_lang=en.

51. Miller, Jason. OMB releases EA assessment tool. Federal Computer Week online. Apr 24, 2004.

URL: http://gcn.com/articles/2004/04/28/omb-releases-ea-assessment-tool.aspx?sc_lang=env.

52. Miller, Jason. OMB wants to expand Core.gov. Federal Computer Week online.

http://fcw.com/articles/2007/08/13/omb-wants-to-expand-coregov.aspx.

53. Miller, Jason. OMB Closes FEAMS for Core.gov. Government Computer News. April 30, 2006.

http://gcn.com/articles/2006/04/03/omb-closes-feams-for-coregov.aspx.

54. Mosquera, Mary. OMB to issue EA best practices to drive business value. Federal Computer

Week online. Sep 06, 2007. URL: http://fcw.com/articles/2007/09/06/omb-to-issue-ea-best-

practices-to-drive-business-value.aspx?sc_lang=en.

55. Object Management Group. Federal Transition Framework Metamodel: Government Domain

Task Force Whitepaper. September 26, 2006. OMG Document: gov/2006-09-06.

56. Object Management Group. OMG Value Proposition for Government Organizations:

Government Domain Task Force Whitepaper. Version 1.0. March 12 2009. OMG Document:

gov/2009-03-16.

http://www.ebizq.net/blogs/enterprise/2009/09/fixing_enterprise_architecture.php

http://fcw.com/articles/2009/02/09/mcdonough-what-now-for-egov.aspx

http://fcw.com/articles/2009/02/09/mcdonough-what-now-for-egov.aspx

http://gcn.com/articles/2004/02/09/omb-begins-lastround-check-of-its-architecture-system.aspx?sc_lang=en

http://gcn.com/articles/2004/02/09/omb-begins-lastround-check-of-its-architecture-system.aspx?sc_lang=en

http://gcn.com/articles/2004/04/28/omb-releases-ea-assessment-tool.aspx?sc_lang=env

http://fcw.com/articles/2007/08/13/omb-wants-to-expand-coregov.aspx

http://gcn.com/articles/2006/04/03/omb-closes-feams-for-coregov.aspx

http://fcw.com/articles/2007/09/06/omb-to-issue-ea-best-practices-to-drive-business-value.aspx?sc_lang=en

http://fcw.com/articles/2007/09/06/omb-to-issue-ea-best-practices-to-drive-business-value.aspx?sc_lang=en


57. Office of Management and Budget. Circular No. A-11, Preparation, Submission, and Execution

of the Budget (FY11). August 2009.

58. Office of Management and Budget. Enterprise Architecture Segment Report (EASR) Instruction

Guide. Version 1.0. December 2008.

59. Office of Management and Budget. Enterprise Architecture Segment Report (EASR): Interim

Instruction Guide for Quarter 4 FY2009. Interim version 1.3. September 2009.

60. Office of Management and Budget. E-Government Strategy: Implementing the President‘s

Management Agenda for E-Government. Feb 27, 2002.

61. Office of Management and Budget. OMB and OMG Collaboration On the Federal Transition

Framework. December 2006.

62. Office of Management and Budget. Development, Maintenance, and Implementation of Agency

Information Technology Architectures. June 1997.

63. Office of Management and Budget. FEA Consolidated Reference Model Document v 2.3.

October 2007.

64. Office of Management and Budget. Enabling Citizen-Centered Electronic Government 2005 –

2006 FEA PMO Action Plan. March 2005.

65. Office of Management and Budget. Federal Enterprise Architecture home page,

http://www.whitehouse.gov/omb/egov/a-1-fea.html. (October 3, 2006).

66. Office of Management and Budget. Implementing the President‘s Management Agenda for E-

Government / E-Government Strategy. February 27, 2002.

67. Office of Management and Budget. Records Management Profile. Version 1.0. December 15,

2005.

68. Office of the Director of National Intelligence. Information Sharing Environment Profile and

Architecture Implementation Strategy. Version 1.0. May 2008.

69. Office of the Director of National Intelligence. Information Sharing Environment Profile and

Architecture Implementation Strategy. Version 2.0. June 2009.

70. Paul, Kshemendra. Instruction for Agency Submission of Enterprise Architecture Segment

Reports (memo). August 17, 2009.

71. Paul, Kshemendra. Interim Instruction for Agency Submission of Enterprise Architecture

Segment Reports (memo). September 11, 2009.

72. Panko, Raymond R. Business Data Networks and Telecommunications, 7th Edition. Prentice Hall.

2009.

73. Perera, David. CIO Council proposes reference model updating. Federal Computer Week online.

Sep. 12, 2005. URL: http://fcw.com/articles/2005/09/12/cio-council-proposes-reference-model-

updating.aspx?sc_lang=en

74. Perera, David. Core.gov undergoing renovation. Federal Computer Week online. Sep 14, 2005.

URL: http://fcw.com/articles/2005/09/14/coregov-undergoing-renovation.aspx?sc_lang=en.

75. Perera, David. Federal architects ready glossary of terms. Federal Computer Week online.

August 24, 2005. http://fcw.com/articles/2005/08/24/federal-architects-ready-glossary-of-

terms.aspx?sc_lang=en.

http://fcw.com/articles/2005/09/12/cio-council-proposes-reference-model-updating.aspx?sc_lang=en

http://fcw.com/articles/2005/09/12/cio-council-proposes-reference-model-updating.aspx?sc_lang=en

http://fcw.com/articles/2005/09/14/coregov-undergoing-renovation.aspx?sc_lang=en

http://fcw.com/articles/2005/08/24/federal-architects-ready-glossary-of-terms.aspx?sc_lang=en

http://fcw.com/articles/2005/08/24/federal-architects-ready-glossary-of-terms.aspx?sc_lang=en


76. Perera, David. Federal architecture poised to become real. Federal Computer Week online. Sept.

26, 2005. http://fcw.com/articles/2005/09/26/federal-architecture-poised-to-become-

real.aspx?sc_lang=en.

77. Perera, David. Federal enterprise architecture at a crossroads. Federal Computer Week online.

September 19, 2005. http://fcw.com/articles/2005/09/19/federal-enterprise-architecture-at-a-

crossroads.aspx?sc_lang=en.

78. Perera, David. Hula Hoop, Rubik's Cube ... enterprise architecture?. Federal Computer Week

online. September 19, 2005. http://fcw.com/articles/2005/09/19/hula-hoop-rubiks-cube--

enterprise-architecture.aspx?sc_lang=en.

79. Pulley, John. Getting the message out. Federal Computer Week online. Aug 20, 2007. URL:

http://fcw.com/articles/2007/08/20/getting-the-message-out.aspx?sc_lang=en.

80. Raines, Franklin D. Funding Information Systems Investments. OMB memorandum M-97-02.

Oct. 25, 1996.

81. Robertson, David; Ross, Jeanne W; Weill, Peter. Enterprise Architecture as Strategy: Creating a

Foundation for Business Execution. Harvard Business School Press. 2006.

82. Sessions, Roger. A Comparison of the Top Four Enterprise-Architecture Methodologies. May

2007. Microsoft MSDN Architecture Center web site, http://msdn.microsoft.com/en-

us/library/bb466232.aspx.

83. Sewell, Marc T. and Sewell, Laura M.. The Software Architect‘s Profession – An Introduction.

Prentiss-Hall, Inc. 2002.

84. Ruskin, John. The Seven Lamps of Architecture (1849).

85. Tash, Jeff. Why Is EA So Important? CIOIndex web site, at:

http://www.cioindex.com/channels/enterprise_architecture/enterprise_architecture_articles/enterp

rise_architecture_view_articles/smid/1417/articleid/1765.aspx.

86. U.S. Department of Justice. The Status of Enterprise Architecture and Information Technology

Investment Management in the Department of Justice. Audit Report 06-02. Nov. 2005.

87. Zachman, John. A Framework for Information Systems Architecture. IBM Systems Journal, Vol

1, No. 3. p. 276-292. 1987.

http://fcw.com/articles/2005/09/26/federal-architecture-poised-to-become-real.aspx?sc_lang=en

http://fcw.com/articles/2005/09/26/federal-architecture-poised-to-become-real.aspx?sc_lang=en

http://fcw.com/articles/2005/09/19/federal-enterprise-architecture-at-a-crossroads.aspx?sc_lang=en

http://fcw.com/articles/2005/09/19/federal-enterprise-architecture-at-a-crossroads.aspx?sc_lang=en

http://fcw.com/articles/2005/09/19/hula-hoop-rubiks-cube--enterprise-architecture.aspx?sc_lang=en

http://fcw.com/articles/2005/09/19/hula-hoop-rubiks-cube--enterprise-architecture.aspx?sc_lang=en

http://fcw.com/articles/2007/08/20/getting-the-message-out.aspx?sc_lang=en

http://msdn.microsoft.com/en-us/library/bb466232.aspx

http://msdn.microsoft.com/en-us/library/bb466232.aspx

http://www.cioindex.com/channels/enterprise_architecture/enterprise_architecture_articles/enterprise_architecture_view_articles/smid/1417/articleid/1765.aspx

http://www.cioindex.com/channels/enterprise_architecture/enterprise_architecture_articles/enterprise_architecture_view_articles/smid/1417/articleid/1765.aspx


ENDNOTES

1 Summary of Federal Enterprise Architecture Community Seminar

2 Dion Hinchcliffe.

3 David Robertson, et. al. 47.

4 David Robertson, et. al., vii, 47.

5 Haiping Lao, 29.

6 Dion Hinchcliffe.

7 Haycock, slide 9.

8 U.S. Department of Justice, 11-12.

9 Franklin D. Raines, OMB memorandum M-97-02.

10 CIO Council, Federal Enterprise Architecture Framework, 9.

11 CIO Council, Federal Enterprise Architecture Framework, 3.

12 CIO Council, A Practical Guide to Federal Enterprise Architecture, 5.

13 FEA Program Management Office. Federal Enterprise Architecture (FEA) (etc), slide 45.

14 Object Management Group, OMG Value Proposition for Government Organizations: Government Domain Task

Force Whitepaper, 14. 15

Message received from FTF website, at https://ftf.fido.gov/Security/Signin.apx: ―Data Collection for the Federal

Transition Framework Catalog has ended.‖ (Dec. 2009 through June 2010) 16

Paul, Kshemendra. Instruction for Agency Submission of Enterprise Architecture Segment Reports (memo). 17

Miller, Jason. OMB releases EA assessment tool. 18

Author‘s notes and e-mail exchanges from a cross-agency presentation of EA tool usage , Washington DC, June

2009. 19

General Accountability Office. HUD Needs to Strengthen Its Capacity to Manage and Modernize Its

Environment, 22. 20

Paul, Kshemendra. Interim Instruction for Agency Submission of Enterprise Architecture Segment Reports. 21

Office of Management and Budget, Enterprise Architecture Segment Report (EASR) Instruction Guide Ver 1.0, 1. 22

Government Accountability Office, Enterprise Architecture Use Across the Federal Government Can Be

Improved, 28. 23


Improved, 12. 24

Ibid, 24. 25

Government Accountability Office, The Federal Enterprise Architecture and Agencies' Enterprise Architectures

Are Still Maturing, Highlights page. 26

Government Accountability Office, Information Technology: Leadership Remains Key to Agencies Making

Progress on Enterprise Architecture Efforts, 23. 27

Ibid., 2. 28



Government Accountability Office, Leadership Remains Key to Establishing and Leveraging Architectures for

Organizational Transformation. 30

Government Accountability Office, Leadership Remains Key to Establishing and Leveraging Architectures for

Organizational Transformation, 12. 31

John Ruskin, 7; and Marc and Laura Sewell, 21.

https://ftf.fido.gov/Security/Signin.apx


32

David Perera, ―Federal architects ready glossary of terms‖. ―The project‘s goal is to gain consensus among

government architecture practitioners on the exact meanings of some commonly used terms. ‗We‘ve got to be talking

the same language; by that I mean have the same vision,‘ [Chairman of the Chief Architects Forum Ira] Grossman

said.‖ 33

David Perera, ―Federal architects ready glossary of terms‖. Quote from Ira Grossman, Chairman of the Chief

Architects Forum: ―People often confuse the architecture‘s five reference models with the federal architecture itself,

but they‘re only a part of it.‖ 34

Paula Hagan, et.al., 28-29 (Also see note on this resource in the Resources section). 35

Paula Hagan, et.al., 14: ―The EA is distinct from an EA framework, though the two are sometimes confused.‖ 36

Jeff Tash, 1.

37 OMB‘s Federal Enterprise Architecture home page, http://www.whitehouse.gov/omb/egov/a-1-fea.html, (October

3, 2006) 38

OMB, E-Government Strategy:Implementing the President‘s Management Agenda for E-Government, 4-5;

FEA PMO. Enabling the Vision of E-Government: Federal Enterprise Architecture, slide 3. 39

Author‘s notes from a presentation given at Association of Enterprise Architects, Washington DC, June 2006. 40

David Perera, ―Federal architects ready glossary of terms‖. 41

Office of Management and Budget, Consolidated Reference Model Document Version 2.3, p. 5. 42


Are Still Maturing, 4. 43

E-Gov Enterprise Architecture Guidance (Common Reference Model) Draft – Version 2.0, 4. 44


Are Still Maturing, 15. 45





Ibid., 2 48

Ibid., 22-23 49


Improved. Highlights page, 2-3. 50



Patricia Daukantas. 52

David Perera. ―Federal enterprise architecture at a crossroads‖. 53

Ira Grossman, slide 11. 54

David Perera, ―Federal architects ready glossary of terms‖. 55

FEA Program Management Office, Enabling Citizen-Centered Electronic Government 2005 – 2006 FEA PMO

Action Plan, 11. 56

Haycock, Robert. FEA Program Management Office. Accomplishments and Next Steps. 57

Chief Information Officer‘s Council, Reference Model Maintenance Process, 3. 58

FEA Program Management Office, FEA Practice Guidance, 2-11. 59

Office of Management and Budget, Records Management Profile, 13. 60

Federal Enterprise Architecture Certification Institute, A Graphical Guide to the U.S. Federal Enterprise

Architecture and its Components Relationships, slide 1.


61

Perera, David, ―Hula Hoop, Rubik's Cube ... enterprise architecture‖? 62

Government Accountability Office, Information Technology: Leadership Remains Key to Agencies Making

Progress on Enterprise Architecture Efforts, 45. 63

Office of the Director of National Intelligence. Information Sharing Environment Profile and Architecture

Implementation Strategy, Version 2.0, vii. 64

Office of the Director of National Intelligence. Information Sharing Environment Profile and Architecture

Implementation Strategy, Version 1.0 compared to Version 2.0. 65

Marc and Laura Sewell, 25. 66

FEA Program Management Office, Federal Segment Architecture Methodology (FSAM), Overview, 2. 67



David Perera. ―Federal enterprise architecture at a crossroads‖. 70


General Accountability Office, Air Traffic Control: Complete and Enforced Architecture Needed for FAA Systems

Modernization, 2. 72

Ibid, 5. 73

Ibid, 2. 74

Ibid, 6. 75

Marc and Laura Sewell, 15-16. 76


FEA Program Management Office, The Business Reference Model Version 2.0, ii. 78

David Robertson, et. al, vii. 79

David Robertson, et. al.,vii. 80

John Zachman, 276. 81

John Zachman, 276: ―The discussion is limited to architecture and does not include a strategic planning

methodology.‖ 82

John Zachman, 277: Although information systems architecture is related to strategy, both information strategy

and business strategy, this paper deliberately limits itself to architecture and should not be

construed as presenting a strategic planning methodology. The development of a business strategy

and its linkage to information systems strategies, which ultimately manifest themselves in

architectural expression, is an important subject to pursue; but it is quite independent of the subject

of this work, which is defining a framework for information systems architecture. 83

Jason Miller, ―OMB Closes FEAMS for Core.gov‖. 84

FEA Program Management Office. Status of Federal Enterprise Architecture. PowerPoint presentation dated

Dec 3, 2002. Slide 5. 85

CIO Council, Service Component-Based Architectures, 19. 86

Brand Niemann, FEA Program Management Office, ―Suggestions for the Federal Enterprise Architecture (FEA)

Data and Information Reference Model (DRM)‖, Slide 7 87

Robertson, et. al. 56. 88


David Perrera, ―CIO Council proposes reference model updating‖. 90


Jason Miller, ―OMB begins last-round check of its architecture system‖.


92



David Perera, ―Core.gov undergoing renovation‖. 95

John Pulley, ―Getting the message out‖. 96

Karen S. Evans. 97

Object Management Group, Federal Transition Framework Metamodel: Government Domain Task Force

Whitepaper, 4. 98

Object Management Group, OMG Value Proposition for Government Organizations: Government Domain Task


Office of Management and Budget, Enterprise Architecture Segment Report (EASR) Instruction Guide Version

1.0, 1. 100

Office of Management and Budget, Enterprise Architecture Segment Report (EASR): Interim Instruction Guide

for Quarter 4 FY2009, 6. 101

Object Management Group, OMG Value Proposition for Government Organizations: Government Domain Task


The Technical Reference Model Version 1, 4.

Why Doesn’t the Federal Enterprise Architecture...

Documents

Transcript of Why Doesn’t the Federal Enterprise Architecture...