i journal of enterprise architecture - library

I

Journal of !

Enterprise Architecture

Feature

Architect's Spotlight: George Paras

Articles

Updating the Enterprise Architecture Planning Model Steven Spewak and Michael Tiemann

Lessons from Classical Architecture Alex Pavlak.

Enterprise Architecture in the Federal Aviation Administration Air Traffic Organization Douglas Findlay

Applying Pattern Concepts to Enterprise Architecture Robert Cloutier and Dinesh Verma

Case Study

Department of Interior: A Practical Approach to Enterprise Architecture - Part 2 Colleen Coggins

May 2006 I Volume 2 , Number 2

8

11

20

28

34

51

A quarte rly p u b licatio n of t h e Assoc iatio n of Enterprise Arc hi tects An I nternational Forum for Enterprise Architecture

a\EA www.aeajo urnal .o rg JO U RNA L

Journal of Enterprise Architecture

Editor: Scott Bernard, PhD Carnegie Mellon University / Syracuse University

Beryl Bellman, PhD California State University,

Los Angeles

Patrick Bolton, MS . EA Practice Lead BAE Systems, Inc.

Haiping Luo, PhD Senior Enterprise Architect

Department of Veterans Affairs

Kristian Hjort-Madsen, MS Danish Ministry of

Science, Innovation and Technology

Ann Reedy, PhD Senior Enterprise Architect

Mitre Corporation

Associate Editors

Andrew Blumenthal, MBA Chief Enterprise Architect

U.S. Secret Service

Michelle Kaarst-Brown, PhD School of Information Studies

Syracuse University

Stephen Marley, PhD Senior Enterprise Architect

NASA

Matthew Newman, MS Professor, IRM College

National Defense University

Kathie Sowell, MM Senior Enterprise Architect

Mitre Corporation

John Gotze, PhD Department of Informatics

Copenhagen Business School

William Krauter, PhD Lockheed Martin

Corporation

Thomas Mowbray, PhD Senior Enterprise Architect

Keane, Inc.

Felix Rausch, MS Executive Director

Federal EA Certification Institute

Michael Tiemann, MSSM Senior Enterprise Architect

Booz I Allen I Hamilton

About the Journal: The Journal of Enterprise Architecture (JEA) is a peer-reviewed international quarterly publication of the Association of Enterprise Architects (aIEA). Issues are published in February, April, August, and Novernber each year. JEA supports global academic and practitioner communities of interest through the publication of articles that promote the profession of enterprise architecture, issues regarding practices and methods, case studies, and standards at the national and international level.

Copyright: all rights reserved. The reproduction, storage, or transmission of JEA articles or other content is prohibited without prior permission in writing from the JEA Editor, who can be contacted via email at [email protected] or in writing at 6348 Crooked Oak Lane, Falls Church, Virginia, 22042.

Article Submissions: Authors may submit properly formatted manuscripts to the JEA Editor at [email protected] for peer-review and publication consideration. Author subrnission guidelines are available on the alEA website at www.aeajournal.org. Approximate timeframes frorn submission to publication for successful manuscripts are 6 to 12 months, depending on the backlog of previously accepted manuscripts. Copyright of all accepted articles and other published content is transferred by the author to JEA upon notification of acceptance by the JEA Editor.

Subscriptions: One-year subscriptions to JEA can be ordered for $75.00 (USD) per year through the alEAwebsite at www.aeajournal. org and can be paid for on-line (Visa, MasterCard, or American Express), or by downloading and mailing the JEA Subscription/alEA Membership Form and a check to the Chief Editor at 6348 Crooked Oak Lane, Falls Church, Virginia, 22042. Student subscriptions are available at $45.00 for college students and for the first year for those in alEA-affiliated EA training classes. A group rate is available for $300.00 for 5 individuals from the same organization (each person will receive a copy of JEA). All subscriptions to JEA include membership in the Association of Enterprise Architects (aIEA).

Back Issues: Copies of a JEA back issue can be ordered through the alEA website for $5.00 plus $2.00 U.S. domestic shipping or $3.50 international shipping (per copy). Expect 1-3 weeks to receive each order. The shipping price for orders of multiple copies of JEA back issues must be coordinated via email with the JEA Editor at [email protected].

aJEA Membership: Membership in alEA is automatically obtained and maintained through subscription to JEA. Each subscriber is assigned to the alEA Chapter that is nearest to that member, or to the global "At-Large Chapter." Selection of alEA Chapter affiliation is made by the subscriber/member as part of the initial subscription and annual renewal process, done online at www.aeajournal.org, or via the downloadable form (see Subscriptions).

- -- - ----- -- -- ------ -------

The Journal of Enterprise Architecture May 2006 Volume 2, Number 2

Features

Editor's Corner

alEA International Committee News and Events

alEA Local Chapter Points of Contact

Architect's Toolbox

Architect's Spotlight: George Paras

Articles

Updating the Enterprise Architecture Planning Model Steven Spewak and Michael Tiemann

Lessons from Classical Architecture Alex Pavlak

Enterprise Architecture in the Federal A viation Administration Air Traffic Organization Douglas Findlay

Applying Pattern Concepts to Enterprise Architecture Robert Cloutier and Dinesh Verma

Case Study

Department of the Interior: A Practical Approach to Enterprise Architecture - Part 2 Colleen Coggins

2

3

4

5

8

11

20

28

34

51

© Journal of Enterprise Architecture - May 2006 1

alEA JOURNAL

Scott Bernard, Editor

The May 2006 issue of JEA is our fourth issue and marks the completion of the first full "set" of this quarterly publication. I continue to be impressed with the quality and variety of submissions we are getting from authors around the world, and I thank each of the authors who have contributed thus far. The August 2006 issue will be somewhat unique in that it will be devoted to EA standards. We will resume the regular format of articles and case studies on a variety of EA subjects in the November 2006 issue.

JEA will continually be in the hunt for high quality articles on EA that have not been previously published. We are fortunate to now have a modest backlog of manuscripts that has put the "submission-to-print" delay at 6-9 months, so authors submitting manuscripts this spring and summer (that are accepted by our Board of Editors) will see the resulting article in the February or May 2007 issue. The line will only get longer, so get your articles in soon. Manuscripts are submitted to the Editor at [email protected] and the submission format and guidelines are available on alEA's website at www.aeajournal.org.

Please note that back issues of JEA are available for $5.00 plus shipping, order them by contacting the Editor via email (see details on the inside cover). Also, the Board of Editors decided in December to begin allowing advertising in JEA on a limited basis. I have pushed back the start of an advertisement section to the August 2006 issue due to various production, notification, and timing issues. As was mentioned in the last issue, this will be done tastefully in a way that and does not give a commercial feel to JEA. The reasons for allowing advertising are twofold: (1) advertising income will supplement member dues and help to keep the price of JEA as low as possible; and (2) to allow the vendors that support the EA community to be more visible in a way that maintains JEA's neutrality on products and approaches. We will also provide page for members and other independent EA consultants to post a small advertisement at a nominal fee.


We begin the May issue of JEA with "Architect in the Spotlight" that features George Paras, Vice President of Strategy for Troux Technologies, a long time mover and shaker in the EA community, and the Editor of Architecture & Governance magazine (www.ArchitectureandGovernance.com). I met with George in March, at the EAC (EA Conference) in Orlando, Florida. EAC is held twice a year and is the longest running and perhaps largest ongoing EA event anywhere. The "Architect's Toolbox" feature is an analysis of Ala Win by our tool expert, David Rice.

The "Articles" section begins with a wonderful and unique contribution by Steven Spewak and Michael Tiemann on "Updating the EAP Model." Mike and Steve had been collaborating on the EAP update when Steve passed away in 2004, and we a fortunate that Mike was able to finish the work and obtain permission from Steve's other business colleagues to allow the publication of this article, which not only makes the EAP approach more relevant and current, but represents yet another contribution to the EA community by one of the founders.

The next article is a very insightful piece by Alex Pavlak on the lessons that the EA community can learn from traditional architecture. This is Alex's second article in JEA, and his cogent writing style and insightful analysis drew some of the highest marks to date from our Board of Editors. The third article by Douglas Findlay provides an interesting look at how EA is being implemented in one of the Federal Aviation Administration's key business units. The last article by Robert Cloutier and Dinesh Verma is a highly original look at how patterns and the recognition thereof are a foundational aspect of EA. The featured Case Study is the second of a two-part article on how the Department of the Interior turned around a troubled EA program to become one of the leading architectures in government.

I hope you enjoy this issue of JEA and I thank you for your support and readership.

alEA JOURNAL

International Executive Committee

• President: Scott Bernard [email protected]

• Vice President: Jaap Schekkerman [email protected]

• Secretary: Kristian Hjort-Madsen [email protected]

• Treasurer: Mike Hall [email protected]

• Resources Coordinator: Tanaia Parker [email protected]

Since December, the International Committee has been busy working on the update of the alEA website and the establishment of a new linked blogging site. John Gotze (one of JEA's Associate Editors), Mike Hall, and Tanaia Parker have been collaborating on these improvements, which will continue thru June. As always, we welcome input and content from alEA members. There is now a link to an EA document library on the alEA website homepage (www.aeajournal.orgl; found at the "Library" tab, accessible only to members. Another addition to alEA services is a quarterly electronic newsletter to be sent via email.

Just as we did last quarter, alEA welcomes two new chapters; the New Zealand Chapter and the New York City Chapter. This makes seventeen chapters plus the "Global-at-Large Chapter." Also, alEA now has just over 400 members, with 18% growth seen in the last quarter alone. Please remember that renewing your annual membership is done via the alEA website at www.aeajournal.org. Mike Hall (the alEA Treasurer and Webmaster) has added functionality that now allows members to update their profiles at any time, including chapter affiliation. This helps members who joined before there was an alEA Chapter in their area.

As a reminder, back issues are available for $5.00 USD plus shipping. Orders are placed via email with the editor at [email protected].

International Standards Committee • Chair: Haiping Luo

haiping@aeajournal,org

The alEA International Committee on EA Standards serves two related purposes: (1) identify, develop, and promote international standards on enterprise architecture; and (2) build, manage, and expand an EA knowledgebase in aIEA. The Committee is continuing to develop the Enterprise Architecture Management Guide that provides a taxonomy of EA topics and candidate EA standards. The Committee has established two subcommittees on EA tool interoperability and EA meta-model standardization. The Committee welcomes EA community's involvement and contribution. Please contact Dr. Haiping Luo at [email protected] if you would like to help with EA standards work.

2006 alEA International Conference October 2006 - Seoul, Korea

alEA will hold its first annual International Conference in late October in Seoul, Korea. The conference will feature presentations by local and global alEA members, industry practitioners, and government officials on EA issues of interest to the international community; including standards, taxonomies, tools, and methodologies. Registration information will be provided in the quarterly email newsletter and the August issue of JEA.

2006 alEA U.S. Conference September 2006 - Washington, DC

alEA will hold its second annual U.S. Conference meetings in September 2006 as part of a larger government and industry EA Conference at the Ronald Reagan Federal Building in Washington DC. Details will follow in the quarterly email newsletter and the August issue of JEA.


alEA JOURNAL

International

Australia Chapter Keith Frampton e4591 [email protected]

Canada Chapter Mike Giovinazzo [email protected]

Chile Chapter Alfredo Piquer: [email protected]

Denmark Chapter John Gotze [email protected]

Global At-Large Chapter Scoll Bernard [email protected]

Korea Chapter Hong SikKim [email protected]

New Zealand Chapter Mike Lowe [email protected]

South Africa Chapter Graham McLeod [email protected]

United Kingdom Chapter John Good [email protected]

United States

Delaware Valley Chapter Michael Robison [email protected]

Dallas I Fort Worth, Texas Chapter William Krauter [email protected]

Mid-South California Chapter Kenneth Griesi [email protected]

Midwest Chapter Chuck Ohms [email protected]

New York City Chapter Brian Clark [email protected]

Seattle, Washington Chapter Steve Farowich [email protected]

Syracuse, New York Chapter Mike Hall [email protected]

Tennessee Valley Chapter Jon McKinley [email protected]

Washington DC Metro Chapter Margaret James [email protected]

Readers wishing to join the Association of Enterprise Architects (aIEA) and to subscribe to JEA can only do so through the alEA website at www.aeajournal.org. Annual dues (including JEA subscription) are $75.00 USD for regular members, $45.00 for students, and a group rate of $300.00 for five members. On-line payment with credit card is available (Visa, MasterCard, American Express), and a downloadable mail-in form is also available for those who prefer to send a check.

alEA members can select the local chapter that they want to belong to, if one exists nearby. All members who are not part of a local chapter are automatically assigned to the Global At-Large Chapter. Members can change their chapter affiliation when they renew their membership, or by sending an email to the alEA treasurer and webmaster, Mike Hall, at [email protected]. The alEA Local Chapter points of contact are listed above. Please contact these people for information on Local Chapter events, meetings, and locations.


alEA JOURNAL

David Rice

Review of KBSI's AI" Win® 7.0 When people refer to Enterprise Architecture (EA) modeling tools they are typically referring to expensive, behemoth tools that attempt to "do it all" and "be everything to everyone."

Considering the volume of data to be collected in many EA projects, and the myriad of forms in which it is to be collected, a variety of EA modeling and analysis tools are often needed. Just. as a mechanic's toolbox should have a spanner for a variety of tasks, the toolbox should also have specific precision tools if the architect is expected to be able to do quality work across the spectrum of EA activities. Sometimes, combining tool functionality is called for and the productivity gains of a precision tool often justify the investment in that tool and an interface to a larger EA tool.

Tool Overview and Purpose A/0 Win is an IDEF-O activity modeling tool, and one might call it a precision tool for specific types of EA work. A/0 Win is very relevant for those following the Department of Defense Architecture Framework (DODAF) or for use in many industries that need detailed activity models and where there is a desire to work with an activity modeling language that has a proven track record and is stable. Doubtless the preceding statement will stir up preferences over methodology among many architects, and those favoring Object-Oriented (00) approaches to activity modeling that use the Unified Modeling Language (i.e., Use Cases, Event-Trace Diagrams, and Activity Sequence Diagrams) will also have their day in a future issue's Architect's Toolbox.

It suffices to say that in the DoD EA space IDEF-O activity models are the preferred form for completing the OV-5 artifact. That being said, it is also true that the built-in implementations of IDEF-O in several of the larger EA tools (e.g., System Architec(TM, and MetisTM) can be difficult to use and even some of the smaller more focused tools such as Proforma™ have built-in IDEF-O features that are equally difficult to use. In several tools the

implementation IDEF-O is nowhere near the standard specifications from IEEE and FIPS for symbology and use.

A/0 Win is a very specialized tool that implements IDEF-O well. It does so in a data and rules oriented manner, so that the architect can focus on the job at hand (data collection and analysis) and not on the nuances of diagram drawing and remembering all the method rules and constructs - the A/0 Win tool effectively takes care of that.

Just to make this perfectly clear, given a set of activities, related in a hierarchy the tool produces the necessary IDEF-O diagrams and node trees; given a set of Inputs. Controls, Outputs, and Mechanisms (ICOMs) the tool will produce a fully "drawn" IDEF-O diagram that is properly balanced and validated.

The architect can use the traditional views of a Node Tree and Activity Diagram to input IDEFo information, and A/0 Win makes this easy by auto-placing and auto-drawing the input (and auto-redrawing and balancing if a change in order or hierarchy is made). A/0 Win also provides a unique input mechanism called an "Activity - ICOM Matrix." In this matrix the architect assigns 'Concepts' (what A/0 Win calls a "yet unassigned ICOM") to an 'Activity' via a matrix by clicking in a cell with the appropriate modeling letter selected: I, C, 0, or M. This attaches the 'Concept' to the 'Activity.' The rules engine knows what is attached to what in real time and prevents the architect from assigning ICOMs in a structure that would violate IDEF-O rules. You can change levels of the model within the matrix as well, and when you do change levels you find that diagram consistency balancing has happened automatically and the ICOMS are ready for use at the new level. Auto-balancing, rule enforcement, and automatic drawing and placement are the "magic" the make the use of Win A/0 for creating and editing an IDEF-O model so fast and easy.


Installation on Your PC Talk about easy, A/0 Win is essentially a desktop PC-based activity modeling and analysis tool, and the installation is actually easier than many commercial desktop applications I have worked with. Installing A/0 Win takes only a minute or two and is up and running - no glitches noted in my experience.

Setup When you start up the A/0 Win software it asks to you configure a "repository". A/0 Win is a tool-based modeling tool and repository that is essentially a file on your hard drive, but something that is significant to note is that what you are actually setting up is a shared space for IDEF-O models. You can have multiple models in one file and they can share common Activities and Concepts, ICOMs, and Sources across these models.

Overall Architecture In the modeling tool space there are two classes of tool. Tools that aid in your thinking and analysis process and tools that presume you have done that and need to document the results. Most modeling tools fall in the latter category. The structure and purpose of A/0 Win seems to be for the former.

A/0 Win's architecture is that of a rules engine at the core - knowledgeable of the rules of IDEF-O, both of the allowable relationships of activities and ICOMs and also of the numbers of boxes per page and how they and their ICOMs should be laid out. The tool allows for a small amount of flexibility here for building purposes, but flags the diagram as FEO (For Exposition Only) which is the standard IDEF-O notion for a diagram that does not meet standards.

On top of this rule base are four basic interfaces for building the IDEF-O model; a Node List, a Node Tree, an Activity Diagram, and an Activity-ICOM Matrix. These interfaces are interlinked via the data inherent to the model. A change to the model in anyone interface is immediately reflected in the others because essentially they are all co-related in changing the data. About the most fascinating thing you can show to someone that is used to "drawing" an IDEF-O diagram is to build the "Activity Diagonal" in the Activity Model, switch


to the Matrix, and fill in the ICOM information and then change screen windows to the Diagram view and then see the complete diagram drawn. Most do not believe it at first, and then remark about how much time they wasted in doing I DEF-O with other tools.

Version Control There really is none in A/0 Win. It is a filebased tool so backup your files.

Customizability There is a facility to add some user-defined attributes to the Activities, ICOMs, etc., but as far as the types of customizations we have in tools like Metis and System Architect, this tool is nowhere close.

Integration Capability IDEF-O has a standard interchange language called IDL (not to be confused with CORBA IDL). A/0 Win supports this language to a degree but since it auto-places and routes diagrams, it does not store its coordinates so user attempts to use IDL to transport models to other IDEF-O tools resulted in data but not the diagrams being transported.

Other interface mechanisms exist, however, such as SVG for diagram rendering, and XML Visio Interface for import and export (a proprietary but easily readable text file format).

Available Integrations There is a commercial bi-directional integration with System Architect.

Analysis Capability A/0 Win has extensive Activity Based Costing capability as well as integration with KBSI's other costing tools: EasyABC Plus™ or EasyABC Ouick™.

Reporting Capability Built-in reports are not customizable, but are selectable in content,. There is no reporting language such as SOL. I strongly favor building the model in this tool and transporting the data elsewhere for analysis. That being said; the reports for IDEF-O that exist are good

and should be used if they fit the need. They are neat, clean, and well suited to the purpose of reporting the data in the standard form.

Overall Impressions Afro Win is just plain pleasant to use for IDEFo model creation and editing. I find it so fast and easy that I would have no reservation about taking it into a facilitated architecture session or one-an-one meeting and doing data gathering right in the tool... how many tools can you say that about? Editing an existing IDEF-O model that was created in another tool, (particularly one where editing models, changing activity levels, and rebalancing ICOMs is especially hard), is also relatively easy in Afro Win. It is worth investing in an interface between Afro Win and larger EA tools to do this type of model importing and manipulation.

The reporting and analysis functions of Afro Win leave something to be desired, and I favor moving IDEF-O model data out of the tool once the model is created for those purposes. There are simply stronger reporting tools and stronger analysis tools. The tool has the reports sufficient for strict IDEF-O reports and a few other useful reports but very little in the way of model analysis.

One comment on version and adoption of modern technology; KBSI has been somewhat slow to upgrade Afro Win. It is only in version 7.0 yet the tool was first released in the late

eighties. Certain common Windows™ notions are not present, for instance there is no COM interface, a feature found in most Windows tools these days. But what they do well they do extremely well and better than the "MultiTool" type tools on the market - and that is a good thing for those of us who need it.

Knowledge Based Systems, Inc. KBSI is a privately held company. It has been in business since the mid-eighties and is largely an R&D shop, but also has had commercially available tools for most of its existence. Afro Win is one of its most mature tools and the company founder and President (Dr. Richard Mayer) was part of the ICAM project in which the IDEF methods were developed. KBSI looks to me to be a stable company with a successful track record. KBSI can be reached at:

Knowledge Based Systems, Inc. 1408 University Drive East College Station, TX 77840 Phone: 979.260.5274 Fax: 979.260.1965 www.kbsLcom

Tool Cost: The per-license cost of the Afro Win tool is currently $2,000.00. Annual maintenance is $400.00.

Contact David at [email protected]


alEA JOURNAL

George Paras: Vice President of Strategy, Troux Technologies

This issue's "Architect in the Spotlight" is George Paras, Vice President of Strategy for Troux Technologies™, who acquired Computas and their popular Metis™ EA tool in early 2005, and is also Editor-in-Chief of Architecture and Governance Magazine. Mr. Paras has more than 25 years of expertise in EA management processes, organizational effectiveness, governance and communications strategies. He has coached and mentored hundreds of private and public sector IT leaders through the launch and iterative refinement of their EA programs. Mr. Paras has helped establish current thinking on EA discipline best practices and methods through his thought leadership, research, analysis, and evangelism of EA concepts as Chairman and featured speaker for the Enterprise Architecture Conference. Prior to joining Troux in 2005, Mr. Paras was Vice President of the Enterprise Planning and Architecture Strategies group at META GroupTM.

JEA: Mr. Paras, thank you for agreeing to be interviewed as the featured architect for this issue of JEA. Your work in the IT industry, with META Group, and now with Troux Technologies gives you a uniquely informed view of changes in the landscape of EA practice. In that light, what do see as being the most important issue that EA faces today as a growing area of professional practice?

G. Paras: The continued evolution of EA is entirely dependent on its acceptance as a legitimate management discipline. This is no small task. Too often viewed as a subspecialty within IT, I often see "architecture" receive too much emphasis while the "enterprise" aspect receives too little. To fulfill the promise of EA, the discipline must operate to transform the enterprise from its current state to its strategic future, approaching the problem from the context of the enterprise as system. It must do so by considering all perspectives on EA, from business strategy and capabilities through services, processes, information and technology. Overcoming


misperceptions about the role of EA by delivering fully across its potential is the essential element to the success of the discipline.

JEA: What do you see as being the most pressing issue(s) for enterprise architects who would like to make EA a career?

G. Paras: While enterprise architects must possess a broad range of hard and soft skills, one skill stands out in my mind as critical to long-term success. The ability to think, c?n?eptuallze and ~nalyze systemically distingUishes an enterprise architect from other architects. Possessing, or developing, this skill gives the enterprise architect the ability to traverse all the abstraction levels of the enterprise. Doing so provides clarity on where and when to target value activities, sustaining both an EA practice and an individual career.

JEA: You have been coordinating and/or hosting major EA conferences for over a decade... perhaps longer than any other EA thought leader. What are some of the insights that you've gained into the profession of EA through these gatherings, and what direction do you think EA is going in?

G. Paras: The EA profession continues to attract a steady stream of fresh talent, from all industries, that is a real pleasure to see. Many of these "newbies" come to EA after successful careers in other IT and management disciplines, contributing their own perspectives. Likewise, established professionals are only getting better. I see the same architects year after year at EAC. It is very clear that each year they move to a new, higher level. Many have become speakers and they share their knowledge freely.

To your second question, I think that EA is going in two directions. First, practitioners are getting very good at the mechanics of delivering EA models, creating repositories supporting development teams, and running an EA program to produce value. Second, I think a smaller subset of practicing enterprise

architects are taking it to the next level and combining EA with IT Governance. These groups are moving closer to the business's strategy function, the place I think EA will eventually reside.

JEA: Service-Oriented Architecture (SOA) has gained a good deal of attention in the past three years. How do you see SOA relating to EA?

G. Paras: I think the vast majority of the market, the analyst firms, the consultants, etc. have SOA mostly wrong. They focus too much attention on the promises of the technology of SOA, to deliver reuse and provide software development efficiencies. Don't misunderstand me, SOA shows promise as a way to help solve many problems, but I think what's most important about SOA isn't the technology, but is instead the way· it drives us to look at ourselves and the business. The philosophy of a services approach forces us to think about fundamental building blocks, such as business services, and how they relate together in the context of a larger system, the enterprise. Think about this portfolio of services, the characteristics they must have, the rules to combine and recombine them for agility, and identify how they deliver value to the enterprise, from my perspective that's what EA has always been about. SOA is a very powerful concept we can use to think about organizing and analyzing an enterprise, plus it has the advantage of being directly "implementable". Furthermore, we now have a hype curve to attach to and use to EA's advantage, provided we can push through the noise and confusion surrounding the concept.

JEA: ERP vendors have jumped on the SOA bandwagon, but seem to be slow to embrace EA. Is this a correct perception? Can EA help to make ERP implementations more successful?

G. Paras: I think that is definitely a correct perception. Read back to my prior answer about SOA hype to partially understand the race to SOA-enable applications, valid technical reasons notwithstanding. On the EA front, EA will help ERP implementations as much as any other application implementation. Even a full-blown, "all-in" move towards ERP by any company cannot hope to include the

entirety of the enterprise. EA identifies strategic alignment, creates implementation principles and rules, and creates reference models as target designs. Even though ERP vendors may solve some of the more hairy problems such as integration middleware, consistent data model, etc. they too will benefit from stable and efficient infrastructure, welldefined interfaces between application models, a consistent corporate approach to information and end-to-end views of business strategies, capabilities, requirements, processes, and services.

JEA: Troux Technologies produces one of the most popular EA tools; "Metis." How do you advise clients about using an EA tool as part of their EA program, and what "expectation management" might you want to conduct with potential customers?

G. Paras: Understand what you want to do, and why. Before selecting a tool infrastructure, it is critical that the EA group has an appreciation for the work that goes in and the value that comes out. One of the most important concepts to grasp is that good decisions require good information, and that many constituencies wind up needing the same information to solve their separate problems. In the absence of a stable, persistent, repository, many EA groups recreate information with each new question. For that reason, my advice to new EA teams is to consider a tool environment with an enterprise repository relatively early in their evolution, if for no other reason than to take advantage of that leverage at the earliest possible point.

JEA: Your role at Troux is to develop corporate strategy for the company's EA services and products. What can you share with us about plans for the next year or two?

G. Paras: I believe that there are three critical elements to success at EA. The first is "transformation" - the enterprise architect must be able to answer the "why" questions of the business and chart a course to achieve enterprise transformation goals. The second is "information" - EA must support and inform all decisions in the context of that transformation objective in the form of a single, consistent, upto-date, version of the truth. The last element


is "value" - EA must provide value early and often, to multiple constituents. Value, of course, is ultimately in the context of the enterprise transformation objectives. Troux

products and services do, and will continue to, support the growing needs of the enterprise architect across all these dimensions.

Call for Papers The Journal of Enterprise Architecture

is accepting article submissions for its 2006-2007 issues

Research and Best Practice articles are sought on EA-related topics, including:

Case Studies, Configuration Management, Culture, Documentation, Evaluation, Frameworks, Governance, Implementation, Maintenance,

Methodologies, Taxonomies, Theory, Training, Tools, Use, Value

Issue February May August November

Due Date November 1 February 1 May 1 August 1

Send articles to the JEA Editor at [email protected]

Author submission guidelines can be found on the alEA website at www.aeajournal.org

(http://www.aeajournaLorg/documents/JEA%20Documents/JEA%20Submission%20Guidelines.doc)


alEA JOURNAL

UPDATING THE ENTERPRISE ARCHITECTURE PLANNING MODEL

Steven Spewak and Michael Tiemann

ABSTRACT

The Enterprise Architecture Planning (EAPTM) methodology and model are a seminal part of the common body of EA knowledge that remain relevant in their own right and which have influenced a number of other current frameworks, methodologies, and best practices in the public and private sector. However foundational, the EAP ™ approach has become, according to some EA practitioners, somewhat dated in its content, presentation, technological examples utilized, and in its relationship to some aspects of how EA is being practiced today. The intent of this article is to refresh one Wrt of the EAP approach, the famous EAP model (also known as the Wedding Cake M) and to provide explanations of each part of the updated model.

KEYWORDS

enterprise architecture, planning, wedding cake, methodology, EAP

INTRODUCTION

The Enterprise Architecture Planning (EAP) methodology, based on its 1992 publication date and widespread adoption, could be argued to be one of the foundational works in the common body of knowledge of the practice of Enterprise Architecture (EA). This being said, the EAP methodology and supporting model have become somewhat dated and require refreshment to capture key aspects of current EA practices and to ensure that EAP remains a viable approach for EA implementation. For example, many current practitioners agree that EA is a continuing program, not an all-or-nothing short-term project, and the updated EAP model emphasizes this point. The purpose of models are to help people visualize otherwise abstract concepts and relationships, and hopefully the updated

EAP model accomplishes this to an even greater degree by virtue of these revisions.

Models are essential to EA, and just as the famous Dutch artist M.C. Escher found ways to draw images that provided new and sometimes provocative views of otherwise ordinary worlds and the objects in them. To do this, Enterprise Architects must be able to:

• See the big-picture (forest) from the pixels (trees)

• Notice patterns and trends where things are going

• Detect the inconsistencies and consistencies

• View multiple perspectives of the whole and its pieces

• Separate the idiosyncrasies from the synchronies


• Distinguish what from how, who, when, where and why

• Articulate the blueprints so that others not only see and understand them, but embrace them as well

THE NEED TO UPDATE EAP

Let me (Tiemann) tell a short story that captures the essential reasons for updating EAP. Several years ago the authors were speaking with a colleague, William "Bill" Rummer about the need to update EAP, and he said "It's a beautiful little process that is well organized and simple to understand. Do you really think it needs to be changed?" I replied emphatically, "Yes and here's why ... we have learned much about how and why EA works or doesn't work since EAP was first published, and the fact is that things are changing so fast and so many specialties have grown up in and around the practice and profession of EA that to not change EAP would undermine the continued viability of the approach." As things got going, Steve contributed his own changes.

What happened next was a series of followon discussions and work sessions between the authors that resulted in a number of subtle but important changes to the EAP approach and supporting general model (sometimes called the 'Wedding Cake" EA model). The simplicity of the approach was preserved in recognition that EAP uniquely enables Enterprise Architects to implement an EA program and jump-start it by capturing the primitive artifact information that is required to quickly and effectively populate the top two rows of the Zachman EA Framework (Zachman, 1992).

A review of a number of EA projects that had used the EAP methodology revealed that another implementation phase was needed, where solutions and systems components are detailed, planned, designed, and implemented. This phase involves considerably more than a transition plan, rather it is a programmatic institutionalization of EA and a directed development process that continuously uses and relies on the EA for direction and correctness.


This is a good point in the article to mention that one of the reasons we changed the EAP Wedding Cake model was to insure that as a part of the institutionalization of the EA program that governance is effectively established. We recognize that without it, the migration or transition plans created are just un-validated projects. Only through effective governance do they become a real portfolio of approved transition plan projects. This aspect is perhaps the most important of all of the reasons for changing the EAP Wedding Cake model and its descriptions.

The remainder of this article focuses on changes to the EAP Wedding Cake model, in that this is perhaps the most well known and recognizable element of the overall EAP methodology... a methodology that is comprehensive in its ability to support the establishment, implementation, and ongoing maintenance of an EA program in the public or private sector.

CHANGES TO THE EAP MODEL

For those who are familiar with the original EAP Wedding Cake model, you should be able to easily spot the changes. For those to whom the model is new, the changes are in the "Business Knowledge," "Repository Management," and "Program Transition and Follow-on Design" areas, each of which replace a previous model part.

In the original EAP method, each area in the model corresponds to a set of well-defined steps in a very organized and ordered EA process, as is shown in Figure 1 on the next page. Updates to the EAP model are shown in Figures 2 and 3, also on the next page.

Generally speaking, the model works such that the process flows from top to bottom and from left to right. Planning initiation (shown at the top) is preparation for the architecture process and not actually part of the EAP implementation steps. EA planning should be viewed as a project activity, usually estimated to take from six to eight months and that usually results in a final go or no-go presentation to a decision-maker who would support the EA's implementation.

P R o J E C T

Planning Initiation

Business Current

Modeling Systems & Technology

Data Applications Technology Architecture Architecture Architecture

Implementation / Migration Plans

Figure 1. The Original EAP 'Wedding Cake" Model - Circa 1992

PLANNING INITIATION

----------

M A N A G E M E N T

Figure 2. Intermediate Version of the EAP 'Wedding Cake" Model - Circa 2000


PLANNING INITIATION

VALUES & PRINCIPLES

PROJECT REPOSITORY MANAGEMENT CURRENT MANAGEMENT

BUSINESS SYSTEMS & KNOWLEDGE TECHNOLOGY

DATA APPLICATIONS TECHNOLOGY ARCHITECTURE ARCHITECTURE ARCHITECTURE

IMPLEMENTATION & MIGRATION PLAN

.... ....

PROGRAMMATIC TRANSITION & FOLLOW -ON DESIGN

Figure 3. The Updated EAP Model - Circa 2006

It is our observation from many prior EAPbased architecture projects, that rarely did senior executives not approve the transition plans. This is because the team doing the EAP implementation usually did its homework, ensured executive level involvement, and presented an EA plan that was well documented and aligned to the business. Executive management had worked alongside the EA team for the duration of the process, and indeed was presented with options making many decisions over the course of the project. Therefore, it would be unlikely for them to reject a recommendation to transition to a future architecture they had helped to define and document. Lessons learned from many EAP projects supports early definition of the success criteria that would ensure, if met, the plan would be approved and the EA succeed. This criterion is usually established in the Planning Initiation step.

However, treating EAP in a project-centric approach could cause the EA process to be viewed as a one-time event, instead an ongoing program that is an important part of how an enterprise develops, manages, and changes its business and technology


operating environment. Other concerns included the lack of coverage for the knowledge base or repository management for EA information. This is an important topic that is stressed in EAP courses, but was not very evident in the original model or EAP book. This is a major change in how EA is done and increasingly sophisticated tools and repositories are helping Enterprise Architects manage and get value from EA programs.

As we learned more about the business area of the EAP model, we know now that the business information defined within the EA needs to be more than just a simplified description of the higher order functions. What is required today is a full set of business artifacts, describing the business knowledge base that integrates the strategic initiatives and vision, through the principles and business rules, right down into the processes, tasks and activities. In fact, with Service Oriented Architectures, these tasks and activities must also be translated into patterns and ultimately become business services. So the term "business model" is too limiting.

When I wanted to call this part of the model the Business Architecture, Steve felt the term "architecture" was still too static and limiting in the aforementioned context and part of the EAP process, so he said "lets just call it Business Knowledge." I thought about it and decided that it made sense given all of the various facets that make up the Business Knowledge base. I saw that "architecture" could be misconstrued only as a limited set of high level functional definitions leaving out the critical details like, business rules and explicitly defined and documented processes, tasks and activities. As EA progresses and evolves, tying into other popular EA approaches (e.g., Service Oriented Architecture, Model Driven Architecture) the need for robustness in Business Knowledge will grow.

As a result of our redefining several of the elements of the EAP Wedding Cake model, we decided that it was important to get these changes out to the EA practitioners, and consequently we began writing a pamphlet entitled "Using Enterprise Architecture Planning in Government" (AT&T/PIEAI, 2004). The pamphlet described the revisions to the Wedding Cake model in the context of how EAP could be applied in the government, with special emphasis on how it related to and supported the Federal Enterprise Architecture Reference Models, which is currently used in EA programs in the federal government. The following discussion is an overview of the information on EAP updates that was presented in the pamphlet.

THE NEW EAP MODEL

Planning Initiation - This is the preplanning phase that is critical to setting all of the things in place to be able to use an EAP approach to creating an EA. The main outcomes from the following activities are a detailed project work plan and commitment of resources:

• Define the "enterprise" and ultimately the scope of the EAP (and the EA)

• Establish an EA future vision

• Install and customize (as needed) a basic toolset. This used to mean very basic tools

As EA has evolved and the process has become more stringent in requirements for details, it has increasingly become necessary to decide on a tool that has more functional capabilities to capture details and to graphically represent them in a myriad of articulated views:

• Identify, select, and obtain approval of time requirements for team members' participation. Team members refer to the representatives from the business units (or staff from the program areas) that will be on the EAP team

• Identify success factors, obstacles, acceptance criteria, and use these to conduct an assessment to determine organizational readiness to do the EAP

Each of these steps can be further broken into sub-steps, and there are, of course, a defined set of artifacts, documents, or deliverables that are created.

Values & Principles - These stated "Values and Principles" are basis for starting an EA. They create the basis for all future decisions involving the EA and what's defined within it. Ratified, well-formed principles shape the foundation for architectural decisions. The acceptance of those decisions and continuing the on-going management of the implementation plan, as well as, the institutionalization of the EA program are in a major way resultant from completing this step.

• Define supporting values on which to base the effective governance of information and technology that determine proper actions and decisions

• Define and approve EA Principles

Business Knowledge - This is often referred to as a business model and sometimes as the business architecture. Completing this step provides the core that inter-relates business strategies to the current and future information technology (IT) architectures and implementation plans:

• Identify and relate all strategic goals (Business and IT) to the EA

© Joumal of Enterprise Architecture - May 2006 15

• Compile a knowledge base about enterprise functions, sub-functions, processes, activities (and sometimes tasks), the information used, the performance measures and metrics, business rules and opportunities for process improvement

Current Systems & Technology - The outcome of this step is an inventory of application systems, components and services, data schemas, interfaces and technology platforms that provide a baseline for transition, modernization and or migration plans and for utilization in operational IT management:

• Define and document current (as-is) applications systems (components and services) and supporting technology platforms to the level of detail required and defined in the Planning Initiation step

• Use the baseline to establish EA metrics in terms of an ultimate return on investment, based on cost savings and avoidance from economies and elimination of unnecessary redundancy and duplication and other similar results

Data Architecture - The outcome of this step is a common business language that enables improved and consistent communication across the enterprise:

• Define major kinds of data to form basic vocabulary for business language

• Assign critical attributes

Applications Architecture - As a result of this step, identifying the systems required to support the business, the team will be equipped to address operational capabilities and characteristics in applications and components (and services) that are required to manage and utilize data and information:

• Define sets of capabilities to manage data

• Develop the (create, read, update, or delete-CRUD) relationship to the data


• Facilitate identifying opportunities for business improvement, strategic goals, and current system issues

Technology Architecture - This phase is fitting sometimes hundreds of potential and current technologies (components) to enable different capabilities that the enterprise will require, to implement the architecture:

• Identify and categorize the capabilities that are required

• Establish a standards profile and a technical reference model

• Select various technologies and/or technology strategies to implement

• Validate the sufficiency of selected technologies

Implementation & Migration Plan (also called a Transition Plan) - This plan is resultant from the analysis of the gap between the baseline and target architectures. As an outcome of this step, the organization will be ready to begin transition to the future (to-be) architecture through an organized and prioritized plan:

• Make judgments about including or excluding current systems

• Determine sequence for implementing applications, components and services

• Schedule resources and times for implementing projects

• Analyze net cost-benefit and ROI to feed business cases

• Develop master project plan for a program transition period after EAP

Programmatic Transition & Follow-on Design - After completing the EAP, management receives final reports, deliverables, electronic databases, files and presentation of results, but then, needs to begin the transition into an EA Program. The EA Program is a continuing function or set of activities that not only ensures the updating and upkeep of the EA and the transition plan, but also integrates with the governance and budget decision processes. Ultimately, it also integrates the IT operations and the systems, services and

components design, development and implementation steps as well. Additional activities that could fall within this phase are:

• Institutionalize use of architectures and procedures to keep architectures current

• Oversee required EA reporting and funding mechanisms

• Ensure that IT designs, upgrades, and implementations are continuously synchronized with architectures

• Update EA policies, standards, guidance, and procedures

• Recommend acquisition of new technologies.

• Establish positions and training programs for new skill sets to support EA work and governance

• Prepare for implementing architectural blueprints establishing linkage to System Development Life Cycle (SDLC) or other implementation approaches and or strategies, including the Model Driven Architecture and/or Service Oriented Architecture

Additionally, in the new model there are now two areas "outside" of the model's components that are key to the implementation of EA. These are the "Project Management" and "Repository Management" elements. These elements of the model are shown on either side, because they tend to be important aspects of the overall processes of defining and doing of the EA, throughout. When I suggested to Steve that we should use the second area to emphasize the repository management function, which just like Project Management, was also required and important throughout the process, he thought it was a great idea. It emphasized, he said, as he taught in his EAP classes, that the building of the EA knowledgebase (managed in the form of a repository) is important. The key facets of each of these aspects of the process, as we revised them, are Project Management and Repository Management.

Project Management - Any activity of any scope these days in the enterprise will be managed as a project that has a schedule, a

work breakdown structure (WBS), specific deliverables and in some cases a performance metric approach like Earned Value Management or at least completion criterion. The specific things covered are:

• Develop a detailed project management plan (that will eventually morph into a continuing annualized EA Program Management Plan)

• Develop a Work Breakdown Structure that identifies specific deliverables aligned to specific completion objectives

• Provide periodic reports or briefings on status and completion of the EA

Repository Management - As EA methods and programs have evolved, it is becoming increasingly important that the correct modeling tools and a very efficient repository, both with appropriate configuration management and appropriate security administration are in place to support the EA and its various uses. This has become a niche area within EA that is both specialized in some ways (working and used EA Modeling Tools) and common to other systems and supporting knowledge management capabilities for projects and programs (operating and managing a portal or repository system). Some of the specific areas of requirement are:

• The identification of a tool and or repository to support the EA

• The acquisition of the toolset and lor repository and its implementation with configuration management and proper security and systems operations management

• The training of the EA team and others to access and use the tools and the repository

• The continuous updating (and versioning) of the EA artifacts and documentation into the repository

CONCLUSION

The revised EAP Wedding Cake model is an important part of the refreshment of the EAP approach. This refreshment helps to


strengthen and reconnect EAP to the continually evolving stream of EA methodologies that are in use globally. In the Foreword to the original 1992 EAP book, John Zachman stated that his EA Framework identifies what to define, but the EAP process was the first published and practical approach to tackling how to develop and document this information in Zachman's top two rows. In our update to the EAP model, we have presented several significant changes that reflect updates in how and when to do EA that we felt were needed to advance and refresh the originally defined process. This will help make EAP more current and hopefully still very useful in understanding how to do EA in the public and private sectors.

AUTHOR MIKE TIEMANN'S NOTE

While this article was drafted by me, the material was created collaboratively with Steve Spewak before his death in 2004. Therefore, it seemed fitting that we both be listed as co-authors, especially since EAP is his very original and unique creation. Steve was a really smart guy who was as talented as he was witty and fun. He used to come over to my house and I would have to pry him loose from the baby grand piano to go do work, like our discussions that lead to this article. He could play the rock opera "Tommy" by heart.

The characteristics of an enterprise architect listed at the beginning of this article are from an inscription he wrote in an M.C. Escher collection book, which he gave me as a present when I came to work with him at AT&T Global Services in the 2002-2004 timeframe. We both liked Escher and appreciated the analogies to our work.

All of us who call ourselves Enterprise Architects are indebted to Steve and his thought leadership in creating and teaching EAP to so many people over the years. EAP influenced a number of other EA approaches including the Federal EA Framework (Federal CIO Council, 1999) and the EA3 Cube Framework (Bernard, 2005). It is my hope that this article not only shows how Steve was thinking about updates to EAP, but also refreshes his legacy and


helps our community of enterprise architects to continue to use and benefit from the EAP methodology that helped set much of the initial common body of knowledge for EA process in place. Lastly, I have been in touch with Stefan DeVocht and Gary Matyas, both of whom were good friends and business partners of Steve. They reviewed this article and support its publication. It is my hope that at some point in the future that we (Stefan, Gary and I) can provide a follow-on article that revises the entire detailed set of EAP processes and materials, so that this approach remains relevant in all aspects.

It should also be noted that "Enterprise Architecture Planning" (EAP) and the 'Wedding Cake" are registered trademarks of the Enterprise Architecture Institute, now doing business as Partners in Enterprise Architecture Institute (PIEAI), and are used with permission.

AUTHOR BIOGRAPHIES

Dr. Steven Spewak continues to be recognized internationally as one of the principal founders of the discipline of Enterprise Architecture, who developed a number of practices that are common to many EA approaches, including the first methodology, multi-dimensional model, and the concept of principals that EA implementation should be based on. Dr. Spewak's seminal book "EA Planning: A Blueprint for Data, Applications, and Technology" (1992) not only popularized the term 'Enterprise Architecture,' but also presented the myriad of concepts and practices in an easy to understand manner that helped many architects implement EA programs in the public and private sector. Dr. Spewak passed away in March 2004.

Mike Tiemann is a senior IT management consultant with Booz [ Allen [ Hamilton, specializing in Enterprise Architecture. He is a graduate of Texas A&M University, where he earned a bachelor's degree in architecture, he also holds a MS in Systems Management from the University of Southern California. Prior to joining Booz Allen, he was the EA Practice Director with AT&T Government Solutions and completed

a distinguished career in the federal government, including the position of Chief Architect for the Department of Energy. He was DOE's representative to the Federal CIO Council's Architecture and Infrastructure Committee and was the founding Chair of the Federal Architecture Working Group. Mr. Tiemann, who currently chairs the Governance Subcommittee of the Industry Advisory Council's Enterprise Architecture Shared Interest Group, has written and lectured widely on various aspects of EA.

REFERENCES

AT&T / PIEAI (2004). Using Enterprise Architecture Planning in Government, Version 2.1. Published Monograph.

Bernard, S. (2005). An Introduction to Enterprise Architecture (2"d Edition). Authorhouse, Bloomington, IL.

Spewak, S. (1992). Enterprise Architecture Planning: Developing a Blueprint for Data, Applications, and Technology. John Wiley & Sons, New York, NY.

Zachman, J. (1987). A Framework for Information Systems Architecture. IBM Systems Journal. Vol. 26, No.3, pgs 276-290.

Zachman, J. (2002). The Zachman Framework for Enterprise Architecture. Zachman International (www.zifa.com).


alEA JOURNAL

ENTERPRISE ARCHITECTURE: LESSONS FROM CLASSICAL ARCHITECTURE

Alex Pavlak, PhD

ABSTRACT

The main lesson that results from looking at Enterprise Architecture (EA) through the lens of classical architecture is that EA development should be executed in two sequential stages: an architectural stage followed by an engineering stage. The architectural stage begins with a general need and synthesizes distant to-be alternatives, one of which is chosen by the "client." This selected to-be architecture provides a stable specification for engineering development. The engineering stage begins with the chosen to-be architecture and produces an optimized to-be enterprise design along with a staged transition plan. The transition plan migrates between as-is and to-be enterprise design states (not architectures). A robust to-be architecture does not change during the EA life cycle. The enterprise engineering design changes in response to new technology and requirements creep. Staging EA development in this manner enables early management buy-in and reduces risk by providing stable intermediate milestones. While the architecture stage is a low cost effort, its success demands quality execution and is best executed with special expert teams (Pavlak, 2005). - In addition to the main lesson, private sector experience suggests that EA's greatest value to the enterprise will come from Information Technology (IT) enabling the elimination of unnecessary processes. High value process-driven architecture should be initiated by the organization's strategic planning function.

KEYWORDS

enterprise architecture, classical architecture, special expert teams, business process, synthesis, thin framework, fat framework, engineering design, development, waterfall

INTRODUCTION

Classical architecture reflects thousands of years of history and involves several mature disciplines. The definitions, models and processes are well established and reflect a good deal of experience and wisdom.

In contrast, EA is an evolving discipline and today's practice reflects its information systems origins. There is a tendency to look at EA from the perspective of information technology (IT).


There is confusion over basic questions such as: What is the purpose of EA? What is the difference between architecture and engineering? What comes first, the to-be of the as-is? Is the to-be stable or variable?

The intellectual basis for this article is traditional systems architecture (Rechtin, 1991). This article shows that EA closely corresponds to classical architecture as reflected through Rechtin. There is little need for new terms and special processes. This is particularly true if we

follow tradition and split EA, as currently practiced, into an architectural stage and an engineering stage.

The correspondences between EA and system architecture works well because the enterprise itself is a system; by Rechtin's definition a complex assembly that performs a function greater than the simple sum of the parts. Note that this definition is broader than the EA convention of defining a system as an information system.

Other views of classical architecture such as Alexander's patterns (Alexander 1964) are also illuminating. However, at the current state of EA development Rechtin's system perspective is most useful in addressing basic questions.

THE IMPORTANCE OF PROCESSES

I begin with a most important message from private sector case studies: the big performance gains come from reengineered business processes, that is, new processes made feasible by IT. Simply automating existing processes is usually disappointing.

For example, in the mid-1980's Ford™ automated its accounts payable system and reduced that department's size from 500 to 400 people. At the same time Mazda ™ was performing the same task with 5 people. The difference is that Mazda employed new processes that took advantage of IT. Ford was automating processes that evolved under a paper-based system (Hammer & Champy, 2003).

Case after case reinforces this same lesson. Wal-Mart™ spends an extraordinary effort clarifying essential value-added processes and eliminating unnecessary busy work. Over the past ten years modern corporations have evolved from functional organizational structures into flat process-based structures that rely heavily on process teams.

Automating existing processes with information technology is analogous to "paving old cow paths," improving productivity by 10-30%. On the other hand, IT-enabled reengineering can improve productivity by 500 - 1000% (Hammer

& Champy 2003). Huge productivity gains come from eliminating steps that are made unnecessary by information systems.

I've concluded that both business process and information systems need to be viewed as having equal importance when creating to-be structure of the enterprise.

EA RELATIONSHIPS

It is appropriate to begin by defining terms. Since terms are most useful if they are defined in the context of their use, every effort has been made to keep these terms consistent with classical architecture. Creating non-traditional definitions causes considerable confusion.

• Architecture 1: the structure of components and their relationships

• Architecture 2: the practice of creating architecture. Starts with a general need, produces an actionable specification

• Engineering: starts with a specification, deduces the design of a product/process that optimally satisfies the specification

•

•

•

•

Business Process: an activity that creates an output by adding value to an input. The processes can be administrative or missionspecific

Enterprise: an organizational unit defined by a clear purpose

Enterprise Architecture (EA): the architecture of the enterprise, the structure of the relationship between business processes and information systems

System: any organized assembly of resources and procedures united and regulated by interaction or interdependence to accomplish a set of specific functions. (DoDAF, 2003,)

,.-..... ..-

The purpose of an organization is typically expressed in mission/vision statements. The organization's senior managers then create a strategy and a strategic plan to achieve this purpose. This business strategy defines the scope of the enterprise, as is illustrated in Figure 1 on the next page.


Private sector experience suggests that EA should place processes and information systems at a level of equal importance. Business Strategy requirements can be satisfied in a number of different ways. There is more than one set of business processes that can execute the business strategy, and some of these processes would be easier to automate than others. Likewise, there is more than one information systems configuration that can automate anyone of the business process option. This paper posits that a primary purpose of EA is to understand this relationship and develop appropriate combinations of business processes and information systems.

IT ALIGNMENT

Early efforts to control IT cost aligned IT investments with business needs. The resulting relationships are illustrated in Figure 2. Existing business processes are presented as requirements for the development of information systems. A good definition of this relationship is Enterprise Wide Information Systems Architecture (EWISA).

Business Strategy

~ Business

Processes

+ Information

Systems

Figure 2. Information f;ystems architecture

relationshi~s

EWISA relationships reflect the IT origins of EA. Looking up at the enterprise from the perspective of IT, one expects the organization to provide requirements. EWISA achieves efficiency gains through commonality and standardization but does not realize the large gains resulting from IT-enabled reengineering of business processes. While EWISA is a rational intermediate development stage, it is necessary for EA to evolve beyond EWISA

THE CLASSIC DEVELOPMENT WATERFALL

Classical architecture can be described as a problem solving approach for ill-defined problems; problems that have more than one feasible solution because the goal is defined in general terms. The archetype is a client who


Business Strategy

+ Enterprise

Architecture t t.

"- ~ Business Information

Processes Systems

Figure 1. EA relationships

wants a "dream house." As the client is often unclear about exactly what is a dream house, there is more than one feasible solution. Only the client can decide which is satisfactory. The architect's challenge is to create feasible structures that have the potential to satisfy the needs of a specific client.

The solution approach is hypothesis testing. The architect explores the range of feasible solutions. For the homeowner client, the architect prepares models, sketches, rough cost estimates, and presents alternatives to the client for selection. The architect's presentation contains no more detail than necessary to clarify the fundamental choice.

The client then chooses a concept. Each alternative concept has a different mix of cost, performance, schedule and risk. Each alternative is feasible. Client satisfaction is a value choice. There is no optimum, no objective basis for choosing one or another. Anyone of the alternatives is a feasible solution. As is shown in Figure 3, the basic development model is a waterfall, variations of which are presented in most systems engineering textbooks.

GENERAL

NEED ~ PRELIMINARY CREATE SPEC

ALTERNATIVES ~ . ..,.. ~=" FINAL CLlENT~ SPEC CHOICE ~ dJ"

ENGINEERING ~ DESIGN ~

BUILD Figure 3. Basic Systems Development Model

In military systems client choice is a "concept decision" that kicks off system development (0001 5000.2, 2003). Selecting architecture, the client choice, is a major milestone that changes the character of the project.

Prior to client choice, the project is all about alternatives, potentials and possibilities, fundamental structure, form, balancing, and needs. Client choice, the selection of architecture, results in a unique concept definition, a structure, a preliminary specification that begins an engineering effort. Engineering begins with the preliminary specification and is all about the design and optimization of a product that can be built. The end result of engineering design is a final specification.

GENERAL NEED i=, ==~:::::-

Managing the architectural stage is substantially different than managing engineering design. Engineering design tasks can be partitioned and employ thousands of workers. In contrast, creating to-be alternatives requires a unified vision, a holistic view of the whole concept. This is the province of small teams. The best way to create to-be architectures is to construct special expert teams (Pavlak, 2005).

Skill sets are another reason for separating the architectural stage from engineering design. The architectural stage requires inductive reasoning; think outside the box. The engineering design stage requires deductive analysis, attention to detail. At high skill levels, these two skill sets are generally incompatible and the different stages are likely to need different people.

4 To-be -HarchitecturE -H-

nterprise--1-'

Transition plan

CREATE --===::::: (Thin framework) ALTERNATIVES - ~S -c- To'be --

- renterprise--

CLIENT C' =::::::::-CHOICE ~ S'meWOrk)

ENGINEERING c:==::: DESIGN' ~

BUILD

Figure 4. Enterprise Architecture Development

EA DEVELOPMENT WATERFALL

The central postulate of this paper is that the EA development waterfall (Figure 4) should follow the same sequence as the basic development waterfall. For EA, the general need is the business strategy; there is more than one way to

execute a strategic plan. The problem has more than one feasible set of business processes and more than one feasible information system. The architectural challenge is to determine what structure the client finds to be most satisfactory.


As in basic development, the architect explores the range of structural options. Typically there will be a small number of fundamental design drivers that dominate the analysis. The architect characterizes each approach to illuminate the fundamental choices. This is a high level characterization. The level of detail should be sufficient to specify each so there is no confusion between alternatives. This specification includes requirements, rough estimates of cost, performance, schedule, and risk. Too much detail during the architectural stage obscures the client's fundamental choices. As in basic development, client choice is a major project milestone. The selected concept has a "to-be" architecture defined in sufficient detail to initiate engineering design.

Client choice initiates the high manpower engineering design stage. By selecting a to-be architecture, the client is buying into the project. The client is committing to certain levels of cost, performance, schedule, and risk.

WHO IS THE CLIENT?

In our archetype, the homeowner, the person with the checkbook, makes the client choice. For EA, the client is the person or the group responsible for achieving the purpose that defines the enterprise.

For certain situations such as a large politically sensitive organization, the client can be constructed for the purpose of selecting the tobe. In this case the client could consist of major stakeholders. Encouraging such a group to reach a consensus requires some attention.

FRAMEWORKS

Various frameworks have been developed to provide a common basis for describing enterprise architectures. The Zachman Framework consists of data artifacts organized in a way that helps the architect think about structure in a disciplined manner (O'Rourke, 2003). Another well-developed framework is the Department of Defense Architecture Framework (DODAF 2004).

The view posited in this article is that frameworks are analogous to "drafting


standards" in classical architecture. The framework is not the structure of the enterprise but a method for expressing the structure.

In classical architecture, the client chooses architecture on the basis of sketches and models of the building and its important features. For client choice, the architect will focus on what is important to the client and clarify distinctions between alternative structures. Too much detail is counterproductive as it obscures fundamental distinctions. At this stage there is no need for details such as wiring diagrams.

This paper suggests a "thin" EA development framework (see Figure 4), as the analog to classic architecture sketches. Thin Framework includes only those framework elements necessary to characterize fundamental structure - to distinguish between options and support rough estimates.

Using the Zachman Framework, Thin Framework to-be architectures would consist of a complete description of Scope, and partial high-level descriptions of the Business and Information Systems models. The Technology Model, Detailed Representation and Functional System contain more detail than necessary to describe fundamental structure.

This article also suggests that a "Fat Framework" is the EA analog to detailed engineering design description. The "Fat Framework;" is a set of framework elements with sufficient detail to document the design. (Since the design has architecture, documenting the design also documents the arChitecture.)

ENGINEERING DESIGN STAGE

In classical architecture, client choice produces a specification that initiates engineering design. For a new home, engineering design consists of code compliant detailed drawings and a list of materials for builder quote. For a new bridge or skyscraper, engineering design consists of detailed structural analysis, authorized working drawings, detailed drawings, schedules and materials specification.

As in classical architecture, the enterprise engineering design stage begins with a preliminary specification, the client selected tobe architecture. The purpose of engineering

------------- - ----------

design is to prepare a detailed description of the to-be enterprise and a transition plan that migrates from the as-is to the to-be. Based on this engineering design, the client can purchase information systems and begin to migrate to new business processes.

As is shown in Figure 4, the Transition Plan migrates between an as-is and to-be enterprise states (not architecture). The transition that needs to occur is to migrate from one enterprise design state to another. An enterprise design description contains more information (e.g., interface specifications) than an architectural description of fundamental structure. It is not clear how to migrate from one architectural state to another without including more information than necessary to characterize fundamental structure.

The risk associated with an EA project is highly contingent on the quality of the transition plan. With a distant to-be architecture as a goal, a simple gap analysis may not be sufficient. The gap may be too large for simple transformations. It is not necessary to proceed in one fell swoop. Indeed, the first stage in most engineering design programs is critical item development. For EA, this could include pilot programs to verify business process models and high-risk aspects of the information system. A transition plan can proceed in a sequence of steps with stable intermediate stages. At these intermediate milestones, the client can judge progress and change emphasis or even terminate the project. Intermediate milestones substantially reduce the risk of migrating to a tobe enterprise that is substantially different than the as-is enterprise.

TO-BE ARCHITECTURE AS A STABLE GOAL

In most classical architecture domains, once the client chooses an alternative, the selected architecture does not change during the project life cycle. Homes, bridges, buildings, weapon systems, chemical plants - once the client chooses a concept, the development waterfall proceeds into engineering design and there is no feedback. (spiral development occurs within engineering design.) There are exceptions of course but these exceptions tend to be costly, a failed architecture.

In contrast, engineering design does change and evolve with changing requirements and improved technology. During its life cycle, an aircraft like the U.S. Air Force's B-52 bomber has undergone endless engineering design upgrades to engines, avionics, sensors, and weapons. However, its basic form - airframe, payload, range - has been stable. This paper posits that this stable underlying form is the architecture of the aircraft. Indeed a "robust" architecture can be defined as one that can tolerate substantial engineering design changes without changing its basic form.

While classical architecture suggests that the tobe enterprise architecture should be defined in a way that it is stable during its life cycle, a more compelling reason to do so is that a stable to-be has great value to the client. A stable to-be architecture provides the basis for long-term investments. The client can make commitments with confidence that the whole structure will not be scrapped in a few years.

Still another reason for a stable to-be is that it provides a target for aligning current decisions, for engineering the enterprise. The to-be design is likely to be implemented in stages, one subsystem now, one later. The stable to-be architecture is the glue that ties it all together.

CREATING THE TO-BE ARCHITECTURE

Knowing what we know about the business today and information technology available today, what should the enterprise look like? What is the high value concept, the fundamental structure?

Classical architecture suggests that EA should begin with the to-be architecture. It starts with purpose, the enterprise business strategy (see Figure 1). An architecture team explores alternative structures from the perspectives of key stakeholders and IT. The team focuses on system drivers, those functions that primarily determine performance. Synthesis, the creation process, is accomplished through aggregation, partitioning and balancing (Rechtin, 1991).

Patterns and reference models are useful in organizing this. The product for each alternative is characterized by high level partitioning allocated to business process and information systems. The result is a small set of balanced


alternatives available for client choice.

Alternatives result from the fact that there are generally more than one feasible model of the business and more than one feasible model of the information system scope is common across all alternatives. Several salient points:

1. The purpose of to-be alternatives is to provide the client with the basis for a value choice.

2. Client choices should be fundamental. Beware of too many options and too much detail that obscures fundamental structure.

3. Ideally, the to-be time frame should be far enough in the future so that structure is independent of legacy systems. Legacy systems are accommodated in the transition plan.

4. In most cases, the number of fundamental feasible fundamental combinations of business processes and information system options will be small.

5. The to-be design can be a radical departure from the as-is enterprise yet still be low risk. Risk is mainly a function of the transition plan.

6. The IT aspect of the to-be architecture is a logical structure, technology free.

7. Client choice results in a stable to-be architecture that initiates engineering design.

8. Client choice also means client buy-in.

The architecture team must have experience and judgment, the ability to differentiate between what is absolutely essential from what is merely important. In addition, EA involves the synthesis of two deep disciplines: business process and information systems. Experts in these disciplines have vastly different cultures and values. Communication would benefit from facilitation. The creation of to-be EA is not a high cost effort but is critically dependent on quality of execution.

SUMMARY

The private sector clearly teaches us that the greatest productivity gains comes not from automating existing business processes but through eliminating processes that are made unnecessary by information systems. This


article posits that the primary structural question - the purpose of EA - is to determine the relationship between business processes and information systems. Well-defined problems can be solved by logically deducing a solution. This is engineering, which begins with a specification. With EA, the relationship between business process and information systems is not well defined. There is more than one feasible solution. When the problem is not well defined, the classical approach is to split the project into two sequential phases, an architectural phase followed by an engineering phase. This is the basic development waterfall. The transition between the phases two is a to-be architecture, generally chosen by a client from a finite set of alternatives.

If the project is split into architectural and engineering stages, the concept of EA frameworks needs to be clarified. The suggestion made in this article is to think about Thin and Fat Frameworks. A Fat Framework is the usual fully populated description that presents the result of a complete engineering design. The Thin Framework contains only enough information to characterize fundamental structure: the to-be architecture.

In the Zachman model, a Thin consists only of Scope and descriptions of the Business Information Systems Model.

Framework high level

Model and

Classical architecture suggests that the to-be EA should be stable. Since it represents fundamental structure, it should not change with evolving requirements and new technology (the design changes, but not the architecture). A stable to-be has value to the enterprise because it provides a stable basis for long-term investment and a distant target for current decisions.

Creating the to-be architecture involves exploring the relationships between business models and information systems models:

Knowing what we know about the business today, and information technology available today, what should the enterprise look like? What is the high value concept, the fundamental structure?

AUTHOR BIOGRAPHY

Dr. Alex Pavlak (PhD, ME, PEl is an engineer and independent consultant. He has led several major projects that involved creating systems architecture. This includes a 1985 project that synthesized the architecture of an unprecedented submarine sonar system. He offers training workshops, guest lectures, coaching and consulting services for Special Expert Teams, problem-solving, advanced teamwork, and creating architecture. For the past thirteen years, he has been investigating the limits of expert problem solving teams. Under grants from NSF and NIMH, Dr. Pavlak has setup scientific expert teams addressing fundamental problems in basic science. Prior to 1992, Dr. Pavlak spent 25 years managing a wide variety of research and development projects. He can be reached at [email protected]. A more detailed biography and significant publications can be found online at http://mywebpages.comcast.netlthales/

REFERENCES

Alexander, Christopher, Notes on the Synthesis of Form, Harvard University Press, Cambridge, MA,1964.

DoDI 5000.2, "Operation of the Defense Acquisition System," 2003, (available online at: http://www.dtic.mil/whs/directives/ corres/pdf2li50002p.pdf).

DoDAF, "The Department of Defense Architectural Framework," v1.0 Deskbook, 2004, (available online at http://www.defenselink. mil/nii/doc/DoDAF _v1_VolumeJpdf).

Hammer, M., Champy, J. (2003), Reengineering the Corporation; A Manifesto for Business Revolution" Harper Collins Publishers, Inc., New York, NY, 2003, p. 35.

O'Rourke, C., Fishman, N., Selkow, W., Enterprise Architecture Using the Zachman Framework, Course Technology, Boston, MA, 2003.

Pavlak, A., "Simplifying the Creation of EA with Expert Teams," Journal of Enterprise Architecture, 1:1, August 2005, pp. 29-35.

Rechtin, E., Systems Architecting: Creating and building Complex Systems, Prentice Hall, Englewood Cliffs, NJ, 1991.


alEA JOURNAL

Implementing Enterprise Architecture in the Federal Aviation Administration Air Traffic Organization

Douglas Findlay

ABSTRACT

Enterprise Architecture (EA) is a still-emerging discipline. As such, it faces significant challenges despite numerous federal mandates for its implementation across all government agencies. EA is bolstered by an emerging presence in academia, but it suffers from setbacks in the practical world of management. In some cases, organizations have tried multiple approaches to EA implementation with mixed results. The significant challenge facing anyone tasked with implementing EA is not technological, but rather one of understanding organizational dynamics at the macro level and human nature at the micro level. For successful implementation, the people that make up an organization must take ownership of EA, rather than have it thrust upon them. This article explains how this may be accomplished, as exemplified by the EA effort in the Federal Aviation Administration's Air Traffic Organization.

KEYWORDS

enterprise architecture, implementation, strategy, FAA, federal aviation administration, ATO, air traffic organization

BACKGROUND

As a relative newcomer to the field of management science, Enterprise Architecture (EA) is a maturing discipline (Boddie, 2005). Enterprise Architecture is a byproduct of the Information Age, and it joins a long list of fairly recent initiatives in management science. Sometimes disparagingly called the "flavor of the month," many of these initiatives undergo a painful yet mercifully short lifecycle of emerging, surging, and purging (Best, 2006). If for no other reason than this, aspiring enterprise architects must focus more on the human side of EA, rather than on enabling technologies.

"If enterprise architecture doesn't produce results, then it simply is going to be the next thing that gets blown away." - Dick Burk, OMB Office of E-Government and Information Technology (Perera, 2005).


The Department of Defense Architecture Framework (DODAF) addresses this human side. According to a May 9, 2003 memo from the Department's Chief Information Officer (CIO) on Net-Centric Data Strategy, one of the key steps to successful implementation is to leverage the successes of existing Communities of Interest (COl). This implies that there is already some type of EA-like activity in existence, even if by another name and that there may be EA products available as well. There is other evidence to support the notion of EA products predating EA itself. Ira Grossman, who chairs the Chief Architects Forum, says that architectures already exists in organizations, and that EA seeks " ... to make it more efficient and interoperable." (Perera, 2005)

The Federal Aviation Administration's (FAA) Air Traffic Organization (ATO) resembles DoD in several important ways. As a tactically-oriented service organization, it continuously conducts large-scale operations in a highly dynamic

environment. Upgrades to its information technology (IT) infrastructure, as well as changes to IT-intensive processes, must not disrupt ongoing operations that effect safety of flight in U.S. and international airspace. The bulk of the FAA's "tactical decisions" occur as events unfold in the theatre of operations, far from the insular world of headquarters management. From my prior experiences as a U.S. Marine and my current work with the FAA, I've observed that both of 000 and FAA have particularly strong cultures, especially in terms of being missionoriented.

There are significant differences as well. The military has relatively clear lines of authority, and obeying orders is a fact of life. II's unrealistic, however, to expect military discipline to be a cornerstone of the culture of a civilian agency. While the ATO has lines of authority too, I've observed them to be somewhat diluted in comparison to 000, relying more heavily on consensus-driven decisions. Though being mission-oriented is part of the culture of both organizations, it's well understood that military operations can result in loss of life. In contrast, the safety-oriented culture of the FAA is paramount, and any loss of life in the aviation world adversely impacts the FAA's most critical performance measures (FAA, 2005).

FAA Chief Operations Officer Russ Chew has been strengthening ATO's safety culture since he joined the FAA in 2003. For example, he created a safety program that impacts all proposed changes that affects operations in the National Air Space (NAS), and these proposed changes must now undergo a formal "Safety Risk Management Evaluation" prior to approval (FAA, 2004; Shane, 2005). The result is that change proposals require more time and resources go through the preparation and approval process, which may serve to promote stability within the NAS architecture for the sake of maintaining established levels of safety, but may also make needed changes more difficult to implement, thereby reducing agility and driving up operating costs beyond what is needed to maintain requisite margins of safety.

The FAA has long been involved in finding and managing IT solutions, and the ATO (including its forerunner organizations) has a long history of managing its own IT infrastructure. The business of air traffic control has depended upon computers since 1963, when the world's first air

traffic control computer system was commissioned in New York. The NAS has been managed by a number of oversight and development programs, which now includes the NAS Architecture Program, that have weighed costs and benefits of infrastructure investment since 1965 (Preston, 1998). Though it has evolved significantly over the years, cultural norms affecting the development and approval of investments in IT resources that support NAS operations are well established throughout all levels of the ATO organization.

If EA is to succeed in the ATO, it must complement and enhance existing cultural norms, rather than displace and disrupt the timetested approach to developing and approving critical operational services and core business processes. Like 000, the ATO must make full and effective use of its communities of interest so the people of ATO claim ownership of EA, rather than consider it to be the latest external mandate in a long and painful string of less than successful (and unwanted) government management initiatives.

FIRST STEPS

Though many things must occur for EA implementation to be considered a success, none of these will matter without an effective communication strategy to lead the way. In my discussions with numerous academics and practitioners who work in the field of information resources management, it is a commonly accepted fact that cultural change is far more difficult to institute than technological change. According to Con Kenney, Chief Enterprise Architect for the FAA, "It's easy to change technology, but you spend most of your time changing culture." (Kenney, 2005).

"Nothing is more difficult to introduce than a new order. Because the innovator has for enemies all those who would have done well under the old conditions and lukewarm defenders in those who may do well under the new." - Nicolo Machiavelli, 1515

CIO Magazine reported that Bill Godfrey, the CIO of Dow Jones, first tried implementing EA with a fully empowered Chief Architect. This effort failed largely due to uncooperative business units that perceived EA as an obstacle to getting the technology they wanted. The


second EA attempt at Dow Jones, using a federation of architects from its business units, failed as well - this time due to business units co-opting their architects to get what they wanted in the first place. Their third EA attempt, ongoing at the time the article was written, appeared to be making headway by combining the best features of the two previous tries. This consisted of a federated approach led by a strong central figure, resulting in what Mr. Godfrey called an "Architecture Zoning Board" (Koch, 2005).

Anyone who has faced a Community Zoning Board would know that getting approval for proposed changes can be a daunting task. Overcoming resistance to change with a perceived obstacle to change is a risky proposition at best. Enterprise Architects that are members of review boards would be wise to avoid being perceived as "Dr. No" so they don't alienate the very people they need for ongoing EA program support.

By refocusing from the bureaucratic side of EA to its human side, there are better opportunities to be exploited. In my discussions with Mr. Kenney, he described his role as Chief Enterprise Architect as one of being a "hero builder." His preferred methodology consists of listening and learning. As an example, instead of preaching EA to the NAS Architecture's communities of interest, he gathers information on existing and developing solutions. "I'd much rather have them come to me totally frustrated with the non-NAS [administrative] side [of their organizations], desperately looking for help. Then I just connect them to someone else who's got a potentially useful solution for them." In finding and linking these people together, Mr. Kenney is virtually connecting the dots so his federation of NAS architects can willingly take ownership of EA (Kenney, 2005).

On a related note, Mr. Kenney is particularly conscientious about how not to work with communities of practice. In a cautionary tale alluding to DoD's Net-Centricity approach, he says he avoids the temptation to co-opt them, which could compromise their natural entrepreneurial nature (Kenney, 2005).


NEXT STEPS

We can apply a hybrid central/federated EA implementation approach to ATO with minimal adjustment to its existing NAS Architecture program by giving the FAA's Chief Enterprise Architect a place on the NAS Configuration Control Board (CCB), the decision-making body for proposed changes to the NAS. The Chief Architect could report directly to the CIO and, as a full CCB member, could significantly influence IT spending decisions.

But from a practical standpoint, the FAA Chief Enterprise Architect would spend most of his time working closely with system developers, who'd act as a de facto federation of architects, for each program area within the NAS Architecture program. The greatest risks to successful implementation appear to lie in the human side of organizations. For this reason the Chief Enterprise Architect should spend the bulk of his energy in working with and understanding the needs of the federated architects. And this particular approach coincides with Mr. Kenney's philosophy that, rather than express and promote his professional opinions, it's more effective to study and learn from others.

This studious learning approach is a practical application of the premise that people are basically honest, motivated, and willing to work. Commonly known for decades as the Theory Y approach, it may be the best choice for EA implementation. Theory X, which conversely proposes that people must be compelled to work, may seem like a preferred approach for some ideological EA purists. Douglas McGregor states in his seminal book "The Human Side of Enterprise," both of these approaches may be self-fulfilling prophesies, giving both perspectives considerable validity (McGregor, 1960). Yet given a choice between willing ownership versus reluctant compliance, seeking out ideas and building heroes seems like the better option.

BUILDING ON SUCCESS

Once an understanding of the human element of EA is cultivated, the next steps can address the myriad of hands-on activities that are associated with finding or developing EA products. However, in developing EA work products there

is a risk of trying to do too much too soon, as well as the risk of producing nothing of tangible near-term value to the organization. With this in mind, the work of understanding the human element of EA should flow into a somewhat political approach to implementation: Architects should work to cultivate communities of stakeholders that have bought into EA rather than attempt to force-feed the entire organization. The very notion of EA is enterprise-wide, and it inherently motivates EA disciples to think big. EA is more than theory, and needs more than debate. Successful EA implementation starts with winning the small yet strategic battles in the real world, building and combining a progressive string of successes. When it comes to EA implementation, progress is far more beneficial than perfection.

It is not enough to focus on tallying up communities of interest. Quite simply, there may be too many COls to be able engage them all at once. Applying the military principle of force concentration, especially where its outcome is a foregone conclusion, it is better to choose only battles you're sure to win (Tzu, n.d.). In large and complex undertakings like EA, entrenched pockets of resistance should be bypassed in favor of small yet strategic objectives (Matloff, 1973).

An organization is a group of individuals, and culture is an aggregate pattern of individual behaviors. As Mr. Kenney described in a November 2005 briefing to FAA executives:

'~n organization is a complex, adaptive system that does not simply follow rules. People in organizations learn from experience, and adapt their behavior to a dynamic environment.... organizations can respond in unpredictable ways to attempts to change their behavior."

It is therefore prudent, when strategizing the human side of EA implementation, to understand both group dynamics and human nature. Interestingly, Mr. Kenney also said in his 2005 briefing that

"EA itself must encourage changes in organizational behavior." So it is not enough for people to change as a way of accommodating EA. For genuine success, people must accept EA as a way

for them to handle the challenge of changes that they must inevitably face."

MEASURING SUCCESS

What is success? To measure it, one must first be able to identify it. EA may be a way to better manage IT resources and align them to an organization's mission. However, EA is also about managing change, and the most profound organizational change is transformation. A bureaucratic organization uses standardized business processes, and bureaucracies typically deal with change by trying to eliminate it. But change is not only a fact of life in the information age, its pace is accelerating. So it would be wise to implement processes that are designed to accommodate change rather than pursue an increasingly futile attempt to eradicate it. This is one of the most powerful aspects of EA: a way to institutionalize effective change management.

Though EA is inherently a holistic approach to the business of an organization, it is not enough to rely on the overall performance measures of an organization. These are certainly most important, but these measures are influenced by many factors more significant to organizational outcomes than EA. As a prime example, the number of commercial air carrier fatalities is a primary FAA performance metric, where a single catastrophic event would easily eclipse EA success. Other examples are less extreme, but all measurable outcomes at the strategic level in the FAA are influenced by multiple outputs (FAA, 2005).

Mr. Chew stresses the need to improve value to the FAA's customers, and unit cost is possibly the highest level metric that EA could predominantly affect. Though this metric has yet to be adequately developed for performance measurement purposes, its creation and use is inevitable.

EA can also benefit from performance metrics that align with its intended outcomes. Direct measurements could be derived from external mandates, such as Office of Management and Budget (OMB) Circulars A-11 and A-130. One sure, if not overly coarse, measurement would be how successful an agency is at staying within its IT budget. Additionally, new agency EA program grading criteria from both OMB and the U.S. Government Accountability Office (GAO)


provide as a revealing and useful set of EA program measures.

There are other approaches worth considering. If a more immediate goal of EA implementation is to identify and engage communities of interest, perhaps an index that conveys quality and quantity of cal participation would be useful. Using a systems-thinking approach, another measure could be to track the number and strength of the bridges built between the communities of interest through use of EA. These would be closer measures of the elusive yet critical human side of EA implementation.

If EA is evolving, it is reasonable to assume that EA performance metrics are evolving as well. As EA implementation makes progress, the usefulness of EA products should rise as well. To measure implementation in an emerging EA program, simple output measures may serve well as interim metrics, for example tracking instances where products from a central EA repository contributed to investment decisions. Other initial measures of progress could include how many existing solutions can be reused, or how many business functions can be evaluated with EA simulation models. According to Venkatapathi Puvvada, Chief Technology Officer at Unisys Global Public Sector, when EA produces a comprehensive map of an organization, "You can show results by how fast you can find information." (Perera, 2005)

CONCLUSIONS

Though EA is a legal mandate in the federal sector, it is too important and complex to rely only on a compliance-based approach to ensure successful implementation. There are many ways to measure success, but the first step is to know what success looks like. In the case of EA, organizational transformation is the eventual goal, but there are many options available to gauge success as implementation progresses.

Enterprise architects must transcend the IT realm to be successful. Though early results from successful EA implementation may be primarily in the realm of improvements to IT effectiveness and cost efficiency, to see real progress in business transformation enterprise architects must become bridge builders between the IT world and the business world. It could be said that the people who travel the bridge are


more important than the bridge itself, because EA is useless if it isn't used - and it won't be used until people feel it's worth the trip.

There is a significant difference between the theoretical concept of EA and the practical matter of its implementation. Though EA promotes enterprise-wide thinking and planning, it is obvious that EA implementation in large complex enterprises cannot be accomplished in all at once. A steady accumulation of small successes can get an EA program going in the right direction, and nurturing EA communities of interest provide bite-sized opportunities for making real progress.

Human nature and organizational dynamics appear to be at the very heart of EA implementation. Both are inherently resistant to change and uncertainty, but attracted to usefulness and manageability. Enterprise architects must not only understand the business needs of an organization, but must also become adept at finding and using the best approaches to the human side of EA.

Listening and learning are valuable activities in any organization, and these are perhaps the most important keys to success for the enterprise architect. These practices allow the architect to understand what an organization needs, what solutions are available, and most importantly, who can provide the right solutions. The final and most critical part of this sequence lies with the persons seeking and offering solutions, for they are the ones who must eagerly take ownership of EA. Without this capstone, EA artifacts may be little more than curious relics.

AUTHOR BIOGRAPHY

Douglas Findlay is a senior policy analyst at the FAA Air Traffic Organization. He began his aviation career in the U.S. Marines as an avionics technician and later as a helicopter aircrewman. His career has been centered on the National Airspace System since he joined the FAA in 1988. Since 1995, he has designed web applications for the Federal government as well as for non-profit organizations. Mr. Findlay is currently a student at the Information Resources Management College of National Defense University. He lives in Falls Church, Virginia.

REFERENCES

Boddie, S. (2005). Unpublished personal communication, March 25, 2005.

Best, J. (2006). Flavor of the Month. Berkeley: University of California Press. Retrieved December 5, 2005 from the UC Press website: http://www.ucpress.edu/books/pages/10506.html

Federal Aviation Administration. (2004). Safety Management System Manual, Version 1.1. May 21,2004.

Federal Aviation Administration (2005). Flight Plan 2005 - 2009. Retrieved November 28, 2005 from the FAA website: http://www.faa.gov/aboutlmedialFlighCPlan_rev 020905.pdf.

Koch, C. (2005). A New Blueprint for the Enterprise. Retrieved December 13, 2005 from the CIO Magazine website: http://www.cio.com/archive/030105/index.html.

Machiavelli, N. (1908). The Prince. (W. K Marriot, Trans.). (Original work published 1515). Retrieved December 23, 2005 from the Constitution Society website: http://www.constitution.org/mac/princeOO.htm.

Matloff, M. (1973). American Military History Volume 2: 1902 - 1996. Retrieved December 22, 2005 from the HyperWar website: http://www.ibiblio.org/hyperwar/AMH/AMH/AMH-23.html.

McGregor, D. (1960). The Human Side of Enterprise, New York City: McGraw-HilI. Perera, D. (2005, September 19). Hula Hoop, Rubik's Cube ... enterprise architecture? Retrieved December 13, 2005 from the Federal Computer Week website: http://www.fcw.com/article90841-09-19-05-Print.

Preston, E. (1998). FAA Historical Chronology. FAA Office of Public Affairs Publication, August 1998.

Shane, J. (2005). The ATO and Safety: Improving Our Safety Culture. Retrieved December 12, 2005 from the International Civil Aviation Organization website: http://www.icao.intlicao/en/ro/nacc/meetings/200 5/ATM_Safety/session4usa.pdf.

Tzu S. (no date). The Art of War. Retrieved December 23, 2005 from China the Beautiful website: http://www.chinapage.com/sunzie.html.


alEA JOURNAL

APPLYING PATTERN CONCEPTS TO ENTERPRISE ARCHITECTURE

Robert Cloutier and Dinesh Verma

ABSTRACT

The existence of patterns is almost universal, and their use is evident in many domains. The human mind seems to perceive patterns without conscious thought - we notice an individual's personal habits because they form patterns. Patterns are also used in a number of engineering disciplines - software engineering, requirements engineering and mechanical engineering to name a few. Some of these disciplines have used patterns for over 20 years. Today's enterprise systems have become extremely complex. It is difficult, if not impossible for a system architect to mentally juggle all of the details of a modern complex multi-functional and distributed system. Patterns may provide the enterprise architect an approach to managing this complexity. This article reviews some of the relevant research and application related to the use of patterns, reviews how other disciplines are using patterns, and discusses research that has been done on applying patterns to the practice of architecting complex system (enterprise) architectures. Examples of architecture patterns are presented and discussed, and a methodology and rationale for documenting architecture patterns is presented.

KEYWORDS

Patterns, enterprise architecture, systems architecture, architecture patterns, C2, command and control

INTRODUCTION

One goal of the enterprise architect is to develop and implement a complex system using a methodical and repeatable approach. This includes documenting the system architecture from a variety of views which take into consideration strategic business goals, business rules, existing and legacy systems interfacing with the system of interest, and the appropriate and applicable technologies.

A number of frameworks exist to provide an organizing structure for the enterprise architect. One such framework is the Zachman Framework, providing 30 different artifact types to assist the enterprise architect in capturing, planning and documenting the new architecture (Zachman, 1987). Another is the EA3 Cube (Bernard,2004).


Systems architects within the U.S. Department of Defense (000) have a similar tool, known as the 000 Architecture Framework, or DO OAF. This framework provides for 26 artifact types, representing different views and architectural information. The DODAF is helpful in methodically defining, planning, and documenting the architecture of a complex system. While there are differences, there are many parallels between the approaches suggested for enterprise architects and complex system architects. For instance, while the enterprise architect is concerned with business goals and business scope, the systems architect is concerned with the business goals of the customer (the entity paying for the complex system being architected and developed) and the scope of the system. The two frameworks provide for artifacts that model the system and

its constituent parts, the logical nodes in the system, and the infrastructure. These artifacts can be produced formally, using modeling tools and techniques such as IDEFO or UML, or they can be created using more informal schemas. The important point is that they are created and maintained. The intent of this short discussion is not to educate the reader, but to illustrate the similarities between enterprise architects and systems architects within the Systems Engineering community - there are more similarities than differences.

Because of those similarities, there are techniques that could be useful to architects from both practices. The purpose of this paper is to describe the research being performed to investigate the application of patterns to the practice of systems architecting. Architectural patterns may have pragmatic utility for practicing enterprise architects as well.

A SHORT HISTORY OF PATTERNS

The notion of patterns is almost universal. The human mind seems to perceive patterns without conscious thought. We notice an individual's personal habits because they form patterns. Music employs repeating patterns to make it easier to learn the tune. For example, three childhood songs have the same tune - Twinkle, Twinkle Little Star, Baa, Baa Black Sheep and The Alphabet Song - all derived from the same composition by Mozart.

In seventeenth century England, they made use of pattern books which contained rules of thumb to assist the general public in transacting business. These pattern books represented the documented experience accumulated over the first half of the 1600s in buying, selling, and leasing buildings. Figure 1 represents one example from Henry Phillips's "The Purchaser's Pattern" (Baer, 2003).

For the purposes of discussion in this article, a working definition of a pattern is offered as follows: A pattern is a model or facsimile of an actual thing or action, which provides some degree of representation (an abstraction) to enable the recreation of that entity over and over again.

Figure 1. Mid 17'h Century Patterns Book

In modern times, Christopher Alexander is credited as being the first to understand the value of patterns in the development of systems. Alexander studied architecture at Cambridge. Though formally trained in mathematics and physics, his domain of interest was the design and construction of homes, buildings, and communities. Throughout the 60's and 70's, he developed patterns for use by other architects with the objective of improving the art of urban design. He began to identify patterns for architecture, urban designing, and planning by looking at an architectural design and then abstracting that design into its basic parts which were common across other designs.

Thinking of this in the context of Zachman's Framework, Alexander was the planner. From his perspective, communities became systems to be decomposed into component parts. He described the component parts and their relationship to other component parts in terms of boundaries. Alexander's first publication on this notion was Notes on the Synthesis of Form (Alexander, 1964). He further developed these concepts in A Pattern Language (Alexander, 1977). Alexander believed one could reuse a pattern "tens of thousands of times" and not have any two designs look the same. Nor did he did see the patterns as remaining stagnant. He believed patterns could always be improved upon. "We may then gradually improve these patterns which we share, by testing them against experience ... " (Alexander, 1979).

The Alexandrian form of documenting patterns contains four components: 1) Name; 2) Context; 3) Problem; and 4) Solution (Alexander, 1977). When using this form, the Name of the pattern should be descriptive and should represent the


solution being proposed. Naming a pattern succinctly is critical for pattern reuse. If the pattern name is cryptic and without mnemonic value it becomes meaningless to those looking for a pattern to solve their particular problem, significantly reducing the value of documenting a pattern. The Context addresses the setting for the problem. This might include environment, the problem domain, or any other aspect that will help understand where the pattern is being applied. The Problem describes the challenge or issue which the pattern will be used to address. Finally, the Solution is a description on the application of the pattern - how it is used to solve the problem, and how it may be modified or adapted to accomplish the task. To demonstrate the application of the pattern concept, Alexander outlined multiple patterns for a farmhouse, as follows (Alexander, 1977):

• North South Axis

• West Facing Entrance

• Bedrooms in Front

• Garden to the South

• Half-Hipped End

• Two Floors • Hay Loft at the

Back

• Pitched Roof • Balcony Toward

the Garden

• Carved Ornaments

As one reads through the patterns used to design this farmhouse, a visual picture begins to develop in the mind's eye, creating a living picture of the farmhouse and the site on which it will rest; from nothing more than a written or spoken list.

Other simple, yet powerful patterns documented by Alexander include "House for a couple" and "House for a small family" (Alexander, 1977). The context for the pattern of a "House for a Couple" that is shown in Figure 2 was simply characterized as "In a small household shared by two, the most important problem which arises is the possibility that each may have too little opportunity for solitude or privacy".


Figure 2. House for a Couple

The "House for a Small Family" pattern (Figure 3) context was: "In a house for a small family, it is the relationship between children and adults which is most critical". The pattern was documented to address issues regarding children and their parents: small children like to be around their parents, most parents do not have a place large enough to have a dedicated nursery, and parents do not have the heart to keep the kids out of special areas. If these issues are not taken into consideration in the design of a small house, the house soon has the character of a children's room - toys and clutter everywhere.

Figure 3. House for a Small Family.

Why did Alexander commit a great deal of his professional life identifying patterns, writing books about patterns, and extending the concept of patterns beyond civil architecture? He was attempting to lower the cognitive load of design by exploring large design spaces on behalf of the architect (Alexander, 1964; Coplien, 1997). From Cop lien's perspective:

"patterns helped him to express design in terms of the relationships between the parts of a house and the rules to transform those relationships" (Coplien, 1997).

This is an important concept - in fact, if one were to take the previous sentence and replace the word "house" with "system," the same concept could apply to the notion of enterprise or system architecture patterns.

PATTERNS IN INFORMATION TECHNOLOGY

The information technology (IT) domain is beginning to embrace patterns. As an illustration, IBM® is using patterns in the ebusiness domain. IBM® has found that many customers have the same requirements, and these requirements have been abstracted into patterns. Their recipe steps for creating an effective, run-time architecture are (Sachdeva, 2004):

Step 1: Develop a high-level business description

Step 2: Develop a Solution Overview Diagram

Step 3: Identify Business Patterns

Step 4: Identify Integration Patterns

Step 5: Identify Composite Patterns

Step 6: Identify Application Patterns

Step 7: Integrate a package into a solution

Step 8: Identify Run-time Patterns

Step 9: Identify Run-Time and Product mappings

PATTERNS IN SOFTWARE DEVELOPMENT

In the late eighties, software designers began to apply architectural concepts (patterns) to object oriented software development. The first book on the subject of software patterns was published in 1995 by Gamma, Helm, Johnson, and Vlissides (Gamma, 1995). It detailed 23 patterns, categorized as creational, structural, or behavioral patterns. All of these patterns are still in use today by programmers.

Learning to define and document a pattern is not an easy task. Martin Fowler discusses the difficulty in defining a pattern (Fowler, 1997):

" ... we have had difficulty in defining the term pattern. We all think we can recognize a pattern when we see it, we think most of us would agree in most cases, but we cannot come up with a single definition."

He goes on to provide his own definition of a pattern as "an idea that has been useful in one practical context and will probably be useful in others."

A number of parallels can be drawn between the use of patterns in the software engineering community and the development of ontologies by ontology engineers (Devedzic, 1999). Ontologies provide skeletal knowledge and an infrastructure for integrating knowledge bases at the knowledge level, independent of particular implementations. According to Devedzic, software patterns enable the communication of knowledge in order to solve problems effectively. Software patterns are effective in transferring knowledge by describing solutions to similar problems through common ways and techniques, regardless of the project problem domains or implementation tools and languages. And, using software patterns early in the design reduces the number of changes that have to be made later in the lifecycle. He considers some software patterns to be "micro-architectures" that contribute to the overall software system architecture. That assertion is made because software patterns are used to weave parts of the overall software system architecture into a whole. There are others in the software engineering community that agree with this belief - using multiple patterns, similar in nature to a pattern language, to create an entire software architecture. This concept was first presented in "Patterns Generate Architecture" (Beck, 1994) (Hanmer, 2004).

DOCUMENTING SOFTWARE PATTERNS

Software patterns have been documented in a variety of ways, and there is no consensus in this regard. Again, according to Fowler:

'When people write patterns, they typically write them in some standardized format-as befits a reference. However, there's no agreement as to what sections are needed because evety author has his or her own ideas ... (Fowler, 2003)

A number of pattern documentation approaches have been developed by software engineers. Based on a literature search, Table 1 represents a survey of some of the most common pattern documenting conventions in use today, most of which come from the software domain.


Pattern Patterns for Architecture U.S Treasury A Pattern Language Ellectlve Use Archltecture Template Cases Patterns

GUidance for Pattern Writing

(RIsing, 2003) (Adolph, 2003) (TOGOF,2002) (TOGAF,2002) (Meszaros, 2004) Pattern Name Pattern Name Name Name Pattern Name· Aliases Aliases Problem Problem Problem Problem Problem·

Statement Metaphoric Implementation Story

Context Context Context Structure Context· Forces Forces affecting Forces Interactions Forces·

the Problem Consequences Indications

(svmptoms) Solution Solution Solution Solution· Resulting Resulting Assumptions Resulting Context Context Context Rationale Rationale Rationale Rationale· Known Uses Related Patterns Related Related Patterns

Patterns Sketch Picture Author(s) Acknowledaements Date Email References Kevwords Example Examples Examples Examples·

Known Uses Code Samples • - required, italics - optional

Table 1. A Survey of Pattern Documentation Schemas.

DISCOVERING PATTERNS

An experienced architect begins to notice that it is not unusual, as one abstracts a systems behavior or capabilities; it begins to look like other systems. That is certainly the case when one looks at transaction-based systems. The following example was originally developed to discuss requirement patterns and requirement management, but it can also be used to demonstrate the application of architecture patterns to a sales transaction based system (Kaffenberger, 2004). Let's look at an example of the application of a pattern to an information system.

This example begins with developing a DFD (Data Flow Diagram) for the first level of decomposition for a small bookstore in England.


The diagram in Figure 4 on the next page reflects the interactions with the customer, the shop processes, and the data stores. In fact, the individual that developed this example really created a hybrid Use Case/DFD. It is the first level of decomposition of "Customer wants to buy a book". The numbered circles represent the processes while the items that have horizontal bars above and below the titles represent some form of data storage - whether it is a customer database, a book inventory, or a collection of sales transactions. Finally, each arrow represents the flow of information. From this diagram, it is easy to trace the path from a customer ordering a book, checking the customer's credit, approving the order, checking the book availability, placing the order, and collecting the money for the book; as well as the paths for a number of other interactions.

As an architect looks closer, it becomes apparent that some of the actions can be made more generic (more abstract), and the initial example of buying a book can be abstracted to address the purchase of almost any product. Performing this abstraction, the architect may end up with a "customer purchase" pattern similar to the one shown in Figure 4.

The resulting pattern is generic enough to begin the design of a customer purchase application for almost any domain. The value is that the pattern has been proven over time, and therefore carries a reduced risk of implementation for any architect willing to adapt it into their enterprise architecture.

Figure 4. Book Purchase Diagram

To demonstrate the application of this pattern to a new domain, an architect could make changes to the nouns in the customer purchase pattern (Figure 5) to make it useful in a specific domain -whether it is the purchase of an automobile, a service, or even to register for college course. For example, minor modifications are necessary for this pattern to suggest an initial high level architecture for a class registration service.

Change this noun To this noun

Customer Student

Product Class

Order ReQistration

Discount Scholarship

Figure 5. Customer Purchase Pattern

In Figure 5, everywhere the word "customer" appears, the architect would replace it with the noun "student". Where the word "product" appears, "class" would be put in its place, and so forth. Additionally, the architect may want to extend the pattern by adding the ability to keep track of students in each class to system. Finally, it may not make sense to back order classes, so the architect may remove the "Back Order" and "Suppliers" functionality from the pattern. The use of such patterns at this level may significantly enhance the R&D efficiency associated with architecting, while also enhancing characteristics such as commonality, testability, and system maintenance.

CAPTURING IMPLICIT KNOWLEDGE WITH PATTERNS

Within industry and government, a growing number of practicing architects have acquired considerable architecture expertise via formal or informal mentoring, and work experience in the work environment. This corporate systems knowledge is captured in explicit ways through mediums such as handbooks, lessons learned repositories, templates and tools, methods and practices, and metrics and measures. A significant component of this corporate knowledge, however, is implicit and undocumented, and largely represented through the technical leaders within an organization. This implicit knowledge is useful to others only if it is shared in a manner that allows its application. The holder of that implicit knowledge


may become a bottleneck in applying systems experience on current or future projects (Hole, 2005). Patterns offer a formal method of documentation to capture aspects of such knowledge. If a pattern exists only in the form of implicit knowledge, it is not accessible by others and cannot be used by others without some form of repeated storytelling to convey the pattern to others by the holder of this knowledge.

While a pattern is reusable by the person who first recognizes it, the real power and value of a pattern is derived only if it can be packaged for use by others. Though a pattern can be transferred through verbal communications, such as storytelling, it is more accurately and reliably transferred through more formal forms of documentation.

POTENTIAL BENEFITS OF ARCHITECTURE PATTERNS

Numerous benefits will result from this growing interest in architecture patterns. One significant derived benefit of patterns, based on precedence in other disciplines, should be improved communications between the various stakeholders. Improved team communications between members of the architecture team and the design teams was the result of using patterns while developing open source software (Hashler, 2004).

Another benefit identified from the same study was that patterns facilitated application of sound architectural concepts and implementations. As the discipline of architecting assumes the challenge of developing increasingly complex systems, there is a need for a common lexicon between systems architects. Describing architectures in the context of known and understood patterns should foster better and more consistent understanding across the many stakeholder communities. Systems architecture patterns may also enable implementation of common design features across systems (reuse) leading to enhanced R&D efficiency, and lower ownership costs through reduced efforts with regard to system testing, integration, and maintenance.

In communities that have adopted the use of patterns, the patterns often become standardized through multiple implementations,


presentations at research and professional conferences, and publication in research journals. This standardization fosters reuse of designs and even code that might be generated from the architecture patterns. Such reuse can improve development efficiency and productivity (Coplien, 1997). Based on Coplien's study, one could argue that documenting current patterns may reduce the documentation costs and complexity for any organization that elects to pursue systems engineering patterns. Finally, architectural patterns may help control the complexity of architectures by standardizing on well known and practiced patterns.

ARCHITECTURE PATTERN RESEARCH

At this point, we have established that there are many technical disciplines using patterns to manage complexity and reduce risk. Research into the applicability and use of patterns has been underway within the systems architecting and engineering community (Cloutier, 2005; 2005b).

Once that research established there may be potential benefits supporting the use of patterns at this level, the next question to be asked was "does the systems architect need a different solution for documenting patterns?" This topic was discussed during a colloquia conducted at Stevens Institute of Technology in 2005 (Cloutier, 2005a). Two issues arose from that session that indicated that a unique systems architecture approach is necessary. The first issue is abstraction. The architecture of a system (whether it is an enterprise system within a business or a complex system to be marketed) requires a higher level of abstraction than that found in the software that may be a part of the system. Additionally, many systems include a combination of hardware, software and other resources which may result in pattern uniqueness. This abstraction may make it more difficult to use a simple approach to documenting patterns. The second issue that arose is related to the first - patterns need to address interfaces to non-software parts (if they exist) in the pattern description. This notion of interfaces has not been explicitly addressed in past software pattern discussions.

A survey was conducted in late 2005 to help identify requirements for a methodology for documenting architecture patterns. The survey

was provided to over 70 individuals that either has experience using explicit patterns (e.g. software patterns), indicated they use implicit patterns in their work, or has done serious research and thought on the use of patterns for systems engineering/systems architecting. The researcher received 28 useful responses, and a couple of responses where there was a significant amount of narrative and input provided, but the provided data was not consistent with the survey data, and therefore was not used in this analysis.

SURVEY RESPONSES

The demographics of the responses show a number of notable aspects. First, the responses came from around the world. Eight countries are represented in this data as shown Table 2.

c:::-Countries Totals Australia 1 Finland 2 Germany 1 Holland 5 Norway 1 Sweden 1 UK 1 USA 16

TOTAL 28

Table 2. Survey Response Distribution

The self-described roles of the respondents are shown in Table 3 Some responses characterized their roles with two descriptors -for instance, Director and Architect, which causes the data to look like there are more roles than responses.

Roles Totals Architect 13 Director 3 Educator 1 Research Fellow 1 SE 9 SWE 3

TOTAL 30

Table 3. Respondent's Role

The industries represented by the respondents are shown in Table 4. The largest industry represented is the aerospace industry. This is not surprising with aerospace representing large, complex systems engineering challenges. There are also ten other industries represented in this data.

Field Totals Aerospace/Defense 12 Automotive 1 Commercial IT 1 ConsultinglTool Vendor 2 Education 1 Government 2 Healthcare 1 High Tech Semi/Materials/Nano) 3

Mechotronics 1 Software 1 Telcom 3

TOTAL 28

Table 4. Industries Represented by Survey

Those responding to the survey comprised a very experienced group. While the level of experience ran from 2 years to 48 years, the cumulative years experience represented by the group totals 569 years. Of the 28 responses received, 22 had more than 15 years professional experience, and 18 of the responses had more than 20 years of professional experience. Table 5 provides a profile of the respondents experience levels.

Table 5. Respondents Experience Profile


DOCUMENTING ARCHITECTURE PATTERNS

The data demonstrated that systems engineers and architects are most interested in the rationale for the pattern followed by an example of how to apply the pattern, and known uses of the pattern. The researcher broke the data into three distribution groupings to determine the highest rated sections. The distribution provided for better visibility, facilitating a more clear understanding of which sections were deemed the most important, while also being able to identify which sections are deemed necessary to the majority of respondents though not necessarily having the same degree of importance.

There are several sections that seem to appear on all pattern documentation approaches. Since these sections were pervasive and logical, and they existed in all pattern templates found by the researcher, they were provided in the survey as a necessary given. Those sections are: pattern name, context of the problem, problem description, pattern solution.

Based on the analysis of the survey data, the results indicate that other sections necessary to document architecture patterns include:

• Aliases • Forces • Interfaces • Resulting • Related • Date

context patterns Documented • Known • Sketch • Author(s)

uses

• Email • Rationale • References • Keywords • Example

Another topic addressed by the researcher in the survey was to determine what form of graphic representation should be used in documenting patterns. Within the surveyed community, the two most common graphical notations are related with the two decomposition approaches (or methodologies) - functional decomposition and object decomposition. The following table represents the diagrams normally associated with the functional decomposition methodology, and the total number of survey responses that believed patterns should graphically represented with these types of diagrams (Table 6).

The second methodology originated in the software community and is referred to as object decomposition (sometimes referred to as logical


decomposition). Object decomposition is documented using the Unified Modeling Language (UML). UML is actually methodology agnostic, but it almost always used with an object oriented methodology. The survey asked about what UML diagrams would be most useful in documenting patterns and the result is shown in Table 7.

I Most Valuable Functional Totals Decomposition Diagrams

FFBD 16

Block diagram 11 DFD 9 N2 diagram 6

IDEFO 5 E-R diagram 4 other - FFDB wi Data Flow 1

other - Conops 1

Table 6 - Functional Diagrams for Patterns

Most .aluable UML Diagrams Totals

Use cases 15 Sequence diagram 13

Class diagrams 12 Activny diagram 12

Collaboration diagram 6

Composite structure 5 Object diagram 4 Parametric diagram 3

other - state diagram 3

Constraints diagram 2

other - Component diagram 1

lother - Deployment diagram 1

lother Block diagram 1

other - Domain Model 0

Table 7 - UML Diagrams for Patterns

Based on this data, it appears the most useful graphical diagrams for use in documenting architecture patterns are FFBD, Block Diagram, DFD, N2 and IDEFO for the functional decomposition. For the object decomposition approach, the most useful UML diagrams may be Use Cases, Sequence Diagrams, Class Diagrams, Activity Diagrams, Collaboration Diagrams and Composite Structure Diagrams.

EXAMPLE: THE C2 PATTERN transportation systems like the railroad or a trucking fleet with a little creativity.

The following example takes the command and control (C2) process, sometimes referred to as plan, detects, control and act. Though this pattern is normally associated with designing systems for the military, it is easily applied to the design of a police or fire organization for large cities like Los Angeles or New York. It could also be applied to a command and control system for

As in this case, the pattern documentation may include a model from a modeling tool such as Vitech Corporation's Core (used to generate these diagrams) or a UML modeling tool. The inclusion of a model file certainly will help "jump start" the new architecture. Table 8 lists the process elements for performing C2.

Pattern Name:

Aliases:

Keywords:

Problem Context:

Problem Description:

Forces:

Pattern Solution:

Model:

Interfaces:

Resulting Context:

Example:

Known Uses:

Related patterns:

References:

Pattern Rationale:

Author(s):

Perform C2, Perform Command and Control

None known

Command and control, Plan, Detect, Control, Act, C2.

Does not address "Prepare" precondition (though one might argue that prepare and plan go together) nor "Assess" post condition

In command and control (C2), the situation is typically managed in identifiable phases. And, the situation may move back and forth between the stages. Those stages are Plan/DetectlControl/Act

Terminology may vary from one domain to the next, and should be adapted in the application of the pattern

This pattern provides the basis for developing the command and control (C2) interfaces and information that moves through the stages of C2. It provides the AO Context and the first level of decomposition using IDEFO.

See next page

Information flows between the stages of this pattern, as well as feedback loops. Some information is generated only in a particular stage and then output in the form of reports. Names of information can be modified as required by specific domain application.

Further work is required to define the tasks to be performed within each stage, and the allocation of tasks to systems, hardware, software or people.

This pattern may be used in the modeling of a C2 system for military or paramilitary operations system (such as police or homeland defense) where there would be a planning phase, a detection of an situation or "bad guy", an identification and controlling or managing of the information, and a required action to perform the mission. May even be extended to motor vehicle fleet operations.

Command and Control applications

OODA (Observe, Orient, Decide, Act)

MCDP 6 Marine Corps Command and Control Handbook

This is a time tested doctrine used by the military, that may be applicable to other domains

Harry Johnson Ph.D., Ken Hartnett, Satya Moorthy, Robert Cloutier, 2006.

Table 8. Pattern Description: Perform C2


Doctrine Extern~j Guidance

Strateg

10~--------E~~~ Assessment (BOA) Coordination Data Mission Assessment Mission Status

External Data ---~ Orders Plans Raw Intel

Perform C2 (Pattern) t~~~f Mission Support Requests

Reports f-----. Req for Information

Environmental Data ---~

Resources

t~~~f Resource Assignments Sensor Data

Situational Data TaskinfL Tracks/Targets of Interest

Date: Author: Tuesday, January 17, 2006 Robert J. Cloutier

Number: Name: a Perform C2 (Pattern)

Figure 6. Context Level Pattern Description: Perform C2

At this level of the IDEFO diagram shown in Figure 6, the architect documenting the pattern identifies the inputs and outputs (left to right). The resources are drawn from the bottom. In this case, it may be people or equipment. The controlling factors are drawn from the top. Examples of controls may be strategies to be employed, guidance from the commander or police chief.

Customizations when implementing this pattern may be to change the term "TrackslTargets of Interest" to "suspect" for a police C2 system, or maybe "truck number" for a trucking fleet implementation. Sensor data may be humans in a stakeout, military satellite tracking (or quite frankly, satellite tracking in the form of a GPS


device on a car or trUCk). Examples of external data may be intelligence, or a tip from an informer which will have some impact on the operation.

Documenting an Architecture Pattern

~~~c====t~"~'""'""~"~.-'~=E======3=E3=======i=Ei=~~ Reports environmental Data Req for Information

Ext,m,' "''' ---+---->i iid""", Raw Int. l-H Plan

(Operations) i~~~~~~~~33EE~~~~EEE~iE i-I To,"" Orders Plans Resource AssIgnments

I----I-+-+-----+-+-+--+~ Sensor Data

(su=ce &. ~~~~~~~-----I--I--I---++. Tracks/rargets of Interest Tracking)

1-~1~1~",~"n"~~ ________ ~+-+-__ ~H. Situational Data

~

~!-j-=j~~~E~a~ eo,.ol ,:~,~, D~'''ff==t+ Coo"""',, "''' (0,,,,",,,,, ~ '"," '_".~" &Identificatlon) t'~ S"~'~h~""~ ""~tl-ll iI iii

H Mission Support Requests

Act (ExeaJte/ Prore<Ute Mission)

f----. MIssion Status

M',," , Support Requests

Resources

Figure 7. Detailed Pattern Description: Peliorm C2

There is a lot of data shown in the more detailed level IDEF-O Model illustrated in Figure 7, Each box represents a decomposition of the peliorm C2 top level function, Outputs are taken from one function and become inputs to another function.

Though an architect documenting a pattern of this magnitude could do a further decomposition

of each of these functions into lower level functions, the authors experience has shown that the detail begins to become too detailed, and less able to be abstracted.


A PROPOSED PATTERN HIERARCHY

Patterns can be applied at different levels of an architecture or system based on the appropriateness of the pattern and the existing maturation of the system being developed. For instance, within the software community, there are system patterns (sometimes referred to as architecture patterns by the software folks), design patterns and idioms. Figure 8 represents a pattern hierarchy proposed by van Zyl and Walker for software systems (van Zyl, 2004).

v..mZy! Pattern Hierarchy package MisctM..Orav.tngs {212}

SysterMrchitecturePallems

Figure 8. van Zyl Pattern Hierarchy

It is important to recognize that in their work, when they refer to the system, they are referring to the software system. Their work may be extendable to the broader system, or system of systems architecture. System level patterns may be applicable when representing the highest levels of a system to represent an entire system or a part of a system. They may also include structure and system boundaries. Based on precedence from other disciplines, use of patterns in systems engineering and architecting may provide the foundation for a more common lexicon leading to improved communications between the various stakeholders, while also enhancing the R&D efficiency on complex development programs. For instance, the Publisher-Subscriber pattern, the Layers pattern and the Client-Server pattern were all first published as software patterns (Buschmann, 1996). Now, most enterprise architects understand those patterns, and use them to describe systems - a common lexicon.

The pattern hierarchy proposed by van Zyl (2001) can be extended for broader application and increased relevance to larger systems.


Extending this hierarchy, Figure 9 on the next page shows the five types of system architecture patterns identified in this research (Cloutier, 2005). It also provides a necessary bridge to show the relationship between patterns that the Business process groups have been identifying for years and the software patterns we have already discussed. In this proposed taxonomy, system architecture patterns are broken into:

1. Structural patterns 2. System Requirements patterns 3. Systems Engineering Activities patterns 4. Systems Engineering Roles patterns 5. System Process patterns

Structural patterns provide a physical pattern to follow when designing a part of the architecture. System requirements patterns prescribe the format of a properly formed requirement, or a collection of requirements that can be reused to describe desired functionality. Activities patterns, also described as organizational process patterns, indicate how the process of architecting or systems engineering is performed. Finally, roles patterns help describe how the architecting role is performed.

WHEN TO NOT USE ARCHITECTURE PATTERNS

The discussion thus far has focused on the positive aspects of documenting and using patterns and the potential advantages of applying them within the system architecting discipline. For completeness, this discussion should also present the likely pitfalls associated with the application of patterns.

The first argument against the use of patterns relates to the notion of implicit structural constraints inherent in the use of patterns -particularly with highly independent and creative individuals, and the related impact on innovation. This concern is valid and must be balanced - the intent is to leverage and reuse existing solutions (albeit, abstract) when applicable, and to allow the necessary degrees of freedom to explore new and unique implementations when required and desired to ensure an atmosphere that encourages creativity. The second argument may be described as "so what?"

Pattern Hierarchy 1-15-2006

Organization Patterns BusinessPatterns

, .-----.

Structural

==;-

.

SystemArchPatterns

, , , , , ?

, , , , , , , , , , , , , ; \ SystemProcess

SysEngRoles ! I ;ELti~~1 ~"

SystemRqmnt

package Pattern Relationships {1/2)

MissionPatterns

SystemAnalysisPatterns SystemDesignPatterns SystemTestPatterns

---

SW _Arch Patterns SW _Analysis Patterns "'~~-~ -

~-~--~k--

SW _RqmntPatterns

---, - --

HWDesignPatterns

,

" HW _RqmntPatterns

~--->

OperationaLPatterns

" -----~

SW _Design Patterns

, , ,

.---. r--l

, , , ~

.

CreationalPatterns StructuralPatterns

SW _ TestPatterns

BehavoiralPatterns

Figure 9. A Proposed System Pattern Hierarchy.

Sometimes, when an expert architect looks at patterns, the reaction is - "so what, I knew that". The fact of the matter is that within their domain of expertise, patterns are of little use to experts. This attitude results in lack of inertia when it comes to adopting the use of patterns

- particularly in regard to the documentation and validation of patterns by these experts for use by others. Organizational motivation usually becomes necessary. From the perspective of preserving, sustaining, and evolving corporate knowledge, patterns are a


powerful medium for capturing aspects of implicit knowledge in a form that is pragmatic.

There are situations when it is inadvisable to use architecture patterns. These include:

• New or unique requirements (unprecedented systems) preclude the existence of a pattern

• Unique solution (unprecedented concepts) • When the pace of technological change

does not warrant the use of patterns

For designs that are proven and effective, and addressing problems common across multiple systems and domains, there should be a strong motivation to leverage the benefits that can accrue from the application of patterns.

SUMMARY AND CONCLUSIONS

Patterns are models, or abstractions of reality. Today's systems have become extremely complex. It is difficult, if not impossible, for a systems engineer to mentally juggle all the details of a modern complex system. As already demonstrated, patterns can exist at multiple levels. During the course of systems architecture, design and implementation, a project team may use systems architecture patterns, process patterns, design patterns, implementation patterns (for software code), machine patterns (to cut metal for cabinets), test patterns, and validation patterns. At each level of the architecture, the pattern should contain the appropriate level of detail for the stage in which it is applied. However, patterns are not silver bullets. But they can be a powerful tool in the architect's toolbox. They help solve difficult problems by leveraging existing knowledge, if this existing knowledge is documented in a manner that facilitates this process.

In communities that use patterns, the patterns often become standardized through use in designs and technical discussion, presentations at research and professional conferences, and publication in research journals. This standardization has fostered reuse of architectures, designs and even code.

As was shown in the C2 pattern, sufficient detail can be captured in the pattern to enable an architect less familiar with the process to


begin architecting a solution to a system with similar requirements. However, as the architect documenting the pattern "drills down" while documenting a complex pattern, a level of detail is reached whereupon the necessary detail begins to obfuscate the value of pattern abstraction. This is the point in which no further data should be added to the pattern An additional benefit to patterns at this level is the speed of knowledge transfer to train new systems engineers faster than working on multiple programs over several years. Patterns are one way to help minimize the possibility that details will not "fall through the cracks".

Continued research should be done on architecture patterns. It would be interesting to see if agent based modeling of the use of patterns may help in the quantification of the value of patterns in the architecting process.

AUTHOR BIOGRAPHIES

Rob Cloutier

Rob works for Lockheed-Martin Corporation in Moorestown, NJ where he is a Principle Systems Engineer in the System of Systems Architecture organization. He is responsible for developing architecture for complex systems. Rob is a Systems Engineering Doctoral Candidate and occasional guest lecturer at Stevens Institute of Technology in New Jersey. He is also developing an Object Oriented Architecture and Design course for Stevens Institute. Rob holds a BS from the United States Naval Academy and an MBA from Eastern University where he is an adjunct professor. He has over 20 years experience in systems engineering, software engineering, and project management in both commercial and defense industries.

Dinesh Verma Dinesh received his PhD and the MS in Industrial and Systems Engineering from Virginia Tech. He is currently serving as the Associate Dean for Outreach and Executive Education, and Professor in Systems Engineering at Stevens Institute of Technology. He concurrently serves as the Scientific Advisory to the Director of the Embedded Systems Institute in Eindhoven, Holland. Prior to this role, he served as

Technical Director at Lockheed Martin Undersea Systems, in Manassas, Virginia, in the area of adapted systems and supportability engineering processes, methods and tools for complex system development and integration.

Before joining Lockheed Martin, Verma worked as a Research Scientist at Virginia Tech and managed the University's Systems Engineering Design Laboratory. While at Virginia Tech and aiterwards, Verma continues to serve numerous companies in a consulting capacity, to include Eastman Kodak, Lockheed Martin Corporation, L3 Communications, United Defense, Raytheon, IBM Corporation, Sun Microsystems, SAIC, VOLVO Car Corporation (Sweden), NOKIA (Finland), RAMSE (Finland), TU Delft (Holland), Johnson Controls, Ericsson-SAAB Avionics (Sweden), and Motorola. He served as an Invited Lecturer from 1995 through 2000 at the University of Exeter, United Kingdom. His professional and research activities emphasize systems engineering and design with a focus on conceptual design evaluation, preliminary design and system architecture, design decision-making, life cycle costing, and supportability engineering. In addition to his publications, Verma has received one patent and has two pending in the areas of life-cycle costing and fuzzy logic techniques for evaluating design concepts. Dr. Verma has authored over 85 technical papers, book reviews, technical monographs, and coauthored two textbooks: Maintainability: A Key to Effective Serviceability and Maintenance Management (Wiley, 1995), and Economic Decision Analysis (Prentice Hall, 1998). He is a Fellow of the International Council on Systems Engineering (INCOSE), a senior member of SOLE, and was elected to Sigma Xi, the honorary research society of America.

REFERENCES

Adolph, S. Bramble, P. (2003). Patterns for Effective Use Cases. Boston: Addison Wesley.

Ambler, S. (2004). The Process Patterns Resource Page. Retrieved October 28, 2004 from http://www.ambysoit.com/processPatternsPag e.html

Alexander, Christopher. (1964). Notes on the Synthesis of Form. Cambridge: Harvard University Press.

Alexander, C. (1977). A Pattern Language. New York: Oxford University Press.

Alexander, Christopher. (1979). A Timeless Way of Building. New Your: Oxford University Press.

Baer, W. (2003). How 'Pattern Books' Fueled England's First Speculative Real Estate Market. Harvard Business School Working Knowledge eZine, 2003. Retrieved May 7, 2004 from http://hbsworkingknowledge.hbs.edu/tools/print _item.jhtml?id=3313&t=finance

Beck, K., Johnson, R. (1994). "Patterns Generate Architectures". Proceedings ObjectOriented Programming 8th European Conference, ECOOP '94 (Bologna, Italy, 1994) Springer-Verlag, pp. 139-149.

Bernard, S. (2005). An Introduction to Enterprise Architecture (2nd Edition). AuthorHouse. Bloomington, IN.

Buschmann, F., R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal. (1996). PatternOriented Software Architecture: A System of Patterns. West Sussex, England: John Wiley & Sons Ltd.

Cloutier, R. (2005). Application of Patterns to Systems Architecting. Proceedings and Presentation, 2005 Telelogic Americas User Group Conference, October 2005.

Cloutier, R. (2005a). Survey on the Use of Patterns in Systems Engineering and Architecting Research Colloquium. CSER 2005. March 23, 2005.

Cloutier, R. (2005b) Towards the Application of Patterns to Systems Engineering". CSER 2005. March 23-25, 2005.

Coplien, J. (1997). Idioms and Patterns as Architectural Literature". IEEE Software. Special Issue on Objects, Patterns, and Architectures. January 1997.


Devedzic, V. (1999) "Ontologies: borrowing from software patterns". Intelligence, Vol. 1 0, number 3, pages 14-24. ACM Press, 1999. Available at: http://doi.acm.org/10.1145/318964.318968

Fowler, M. (2003) "Patterns". IEEE Software. March/Aprii 2003.

Gamma, E., Helm, R., Johnson, J., Vlissides, J., (1995). Design Patterns: Elements of Reusable Object Oriented Software. MA: Addison-Wesley.

Hahsler, Michael. (2004). FreelOpen Source Software Development. Edited by Koch Stefan. Idea Group Publishing. Pages 103-124.

Hanmer, R. and K. Kocan (2004). "Documenting Architectures with Patterns" Bell Labs Technical Journal 9(1), 143-163, Wiley Periodicals, Inc., 2004.

Hole, Eirik. (2005) "Architectures as a Framework for Effective and Efficient Product Development in a Dynamic Business Environment". Proceedings of the 2005 Conference on Systems Engineering Research, March 2005.

Kaffenberger, R. (2004). "The Difference - On the Use of Pattern-Based Requirements". 14th Annual International Symposium Proceedings, INCOSE 2004.

Meszaros, G. and J. Doble. "A Pattern Language for Pattern Writing". Retrieved May 28, 2004 from (though available from numerous websites) http://webclass.cqu.edu.au/Patterns/Resource s/writers/languagel


Rising, L. (2003). Pattern Template. AG Communications Systems (A subsidiary of Lucent Technologies). Retrieved May 28, 2004 from http://www.agcs.com/supportv2/techpapers/pat terns/template.htm

Sachdeva, N. and Godlszmidt, G. (2004). "On demand business process life cycle, Part 2: Patterns for e-business recipe". IBM Developerworks Website. 24 Nov 2004. Retrieved June 5, 2005 from http://www-106.ibm.com/developerworks/library/wsodbp21

TOGAF. (2002). "Architecture Patterns". The Open Group Architecture Framework (TOGAF) Website. Retrieved May 27,2004 from http://www.opengroup.org/architecture/togaf8-doc/arch/p4/patterns/patterns.htm

van Zyl, J. and A. Walker (2004). "A Pattern Architecture: Using Patterns to Define Overall Systems Architecture". Retrieved October 22, 2004 from http://osprey.unisa.ac.za/saicsit2001/Electronic Ipaper37.pdf

Zachman, J. (1987). A Framework for Information Systems Architecture. IBM Systems Journal. Vol. 26, No.3, pp. 276-290.

alEA JOURNAL

DEPARTMENT OF THE INTERIOR: A PRACTICAL APPROACH TO ENTERPRISE ARCHITECTURE - PART 2

Colleen Coggins

ABSTRACT

This article describes the evolution of the Department of the Interior Enterprise Architecture (lEA) from an underdeveloped state focused primarily on technology architecture, to its current position as a recognized leader in agency enterprise architectures, selected as best among all OMB rated EA programs in July 2005 and April 2006. This article is the second of two parts -- Part I appeared in the previous issue of the JEA, and covered 001 background information, early shortcomings of the Department of Interior EA (lEA) effort, and subsequent improvements in lEA, including the development of key fundamentals. Part " presents both the "Major Changes" to the lEA and the milestones and approaches in the lEA effort. The final "Major Change" presents information on a methodology developed by the lEA team known as MBT, or the Methodology for Business Transformation. See http.//www.doi.gov/ocio/architecture/ for more information.

KEYWORDS

federal enterprise architecture, business transformation, reference model, repository

INTRODUCTION

To briefly recap the introductory information, from Part I of this article, on the Department of the Interior (DOl), the DOl is a cabinet-level federal agency with a very broad mission. It is made up of the Office of the Secretary, eight independent bureaus and a National Business Center. The DOl is a highly distributed organization headquartered in Washington DC with over 2,400 operating locations throughout the United States and its territories. It is the steward of 504 million acres of federal land, or roughly one-fifth of the land in the United States. DOl has a wide range of responsibilities and highly diverse services including generation of hydro-electric power, oversight of mineral resource extraction, education and trust responsibilities for American Indians and Alaska Natives, National Parks oversight, wildland fire management, and law enforcement.

Today, the DOl performs approximately sixty of the Federal Enterprise Architecture (FEA)

Business Reference Model's "Service to Citizens" sub-functions. This complex set of business responsibilities leads to an equally complex set of stakeholders and customers with vested political, environmental or economic interests. In addition, many of the DOl's mission and business functions are continuously monitored by special interest groups.

The next section of this case study reveals how these five "major changes" Establishing a Federated EA program, Establishment and Population of the DOl Enterprise Architecture Repository (DEAR), Introduction of Governance for DOl Information Technology, Enterprise Architecture, and Investment Decision Making, Aggressive Creation of the First Blueprints in Order to Demonstrate the Business Value of EA, and Development of the Methodology for Business Transformation have helped bring DOl EA to maturity, as well as a synopsis of each major change in the form of a "Lessons Learned" table at the end of each "major


change" discussion. In the last section, the future of the 001 EA program is discussed.

001 EA - MAJOR CHANGES

The identification and application of the four key fundamentals: (1) EA is about business transformation to improve performance; (2) EA is a service to the business; (3) Chief Architects are change agents; (4) EA is about Communication Communication Communication. As was discussed in Part I of this case study, to achieve true EA success, it was necessary to combine these fundamentals with the five Major Changes based on the concept of continuous improvement employed within an EA. Theses changes are presented below.

Major Change #1: The Establishment of a Federated Enterprise Architecture Program

An EA is frequently difficult to define: Is it a single architecture, or a federation of perhaps semi-autonomous architectures? Should it be built across functional lines, or oriented to the lines of business? Many organizations wrestle with this question of how to bound and organize their enterprise. In diverse, complex

Housing Assistance

FoogutriliOn

"'" So Campa tion

Business/Industry

O"'BO Finan S r Oversight Intell party Prolee Indus! r Income Stabilization

organizations such as 001, this consideration leads to the realization that there is a real need for a federated architecture program rather than a simple collection of organizationally based architecture programs.

001 is one of the most diverse Federal Agencies, delivering services in twelve (over 60%) of the Federal Business Reference Model Services to the Citizen lines of business.

Figure 1 below shows these twelve lines of business with an overlay showing the number of 001 Bureaus that deliver services to the citizens in each area. This not only shows the complexity and breadth of DOl's mission but highlights the potential for multi-Bureau and cross-cutting solutions that support the same business area. For instance, a study of the "Law Enforcement" service area within 001 resulted in the identification of multiple existing incident management systems across the Bureaus. This recognition led to a recommendation to retire these systems and replace them with a single incident management system that could be used by all Bureaus.

Water Resource

"'''''8 ConseN arine and Lan a ement

Recreali esource Management and Tourism

EnVirOnB"1tOring and For sli

Environ mediation

Pollution lion and Control

Energy

Energy Re;:o Mgmt. Energy Sup Energy Conserva redness Energy Produc

Disaster Monitoring and Prediction

DisaSaredness ,,' Disas Irand Restore

Education

Elementary, Secondary and

vocatl~n ucalion Cullu isloric Prese Cultural an Isloric Exhibition

Figure 1. Department of Interior - Lines of Business


~~~~~~~ ----------

Prior to Fiscal Year 2004, 001 and the Bureaus had achieved some architecture alignment, but many areas existed where a planned architecture did not exist at the Bureau level, or the architecture approaches and capabilities were not aligned with the rest of the Agency. In order to prevent the emergence of further uncoordinated architecture programs, the 001 specified policies and methods designed to produce a unified, federated architecture that incorporates all Bureau architectures. As a result, many elements of EA development have become standardized across the Bureaus. All Bureaus use the same Methodology for Business Transformation (see Major Change #5) to develop and implement their Modernization Blueprints. All Bureaus share the same toolset and metamodel for storing architecture-related information. All Bureaus participate in interBureau governance teams that make business, data, technology, and investment decisions. The result has been the development of a federated architecture for 001.

Currently, each Bureau Architecture Team builds and maintains its inventories of architecture information. Since the Bureaus all share the same toolset and metamodel, it is easy to synchronize data collection activities across the 001 enterprise. This is done by the Interior Architecture Working Group (IAWG), which is responsible for the consistency and quality of the 001 master data model. The result of these IAWG activities has been a consistent suite of information available to all Bureau architects. Since a standard metamodel is used and the data model is synchronized across the organization, each Bureau can use the same data collection templates, data quality reports, and data validation techniques. This information is maintained within Bureau-specific repositories that are integrated nightly into a DOl-wide repository. All repositories are centrally managed, maintained and updated, reducing the total cost of ownership while creating a standard data view across the Bureaus, the Agency, and the inter-organizational Lines of Business.

The 001 recognized early that the transition to the federated model should be achieved

~~--~~----

slowly in order to minimize confusion and potentially adverse impacts to ongoing business processes. Accordingly, lEA and the Bureau programs adopted an incremental approach to EA development, working through the 001 lines of business and creating Modernization Blueprints for each business segment within the enterprise. The standardized data, policies and methods mentioned above became a factor in the completion of these business transformation initiatives. To this date, four Modernization Blueprint initiatives have been completed using this method and five new business transformation initiatives are underway.

Many of the new Modernization Blueprints being worked by the lEA and Bureau EA teams are inter-Bureau in scope and results. These Modernization Blueprints will provide 001 with a roadmap for increasing business and technology performance within the enterprise. The common approaches and techniques for architecture planning will continue to result in inter-Bureau recommendations for business transformation and the continuous tightening of inter-Bureau relationships within 001.

The following table lists the most important lessons learned in establishing a federated EA program:

are enough in needs that architecture programs don't have to be re-thought for each organization: Each bureau has a different mission, yet the components (e.g., methodologies, frameworks, tools, standards, etc.) that comprise an architecture program have been successfully reused and federated into a architecture. Lesson #2: should be integrated horizontally and vertically. Each 001 Bureau has extremely different mission and business environments; yet, each has been able to federate into the

I lEA.


I

\

\

I I ) I .l

I \ (

i )

The alEA Chapter in the United Kingdom would like to announce:

ENTERPRISE ARCHITECTURE CONFERENCE - EUROPE 2006 12-14 June London, England

From Technology Simplification To Business Innovation

Enterprise Architecture has hitherto been regarded by many people as a tool for IT rationalization. While this delivers real value, the potential is far greater. Increasingly Enterprise Architecture is being seen as a uniquely powerful knowledge base and route map to guide business and IT decision-making and innovation. If well executed, it will enable the design of more efficient, flexible organizations, create more agile loosely coupled processes, and identify new forms of

value to be gained from IT.

This conference is the premier event in architecture globally, attracting speakers and delegates from around the world. Please join us as we engage practitioners from leading companies and thought leaders in the field, to uncover strategies

for success in delivering world-class systems, products and services.

• Idenflfy successful strategies for maximising the impact of Enterprise Architecture within your organisation

• Choose from 3 full day workshops and 4 conference tracks

• Learn from leading practitioners and gain fresh insight and inspiration

• Case studies are featured throughout the conference - learn what does and doesn't work

• Plenty of opportunity to network with other delegates and trade stories with them

In 2005 organisations including American Express, BA, Barclays, BBC, BP, British Council, DaimlerChrysler, Fujitsu, GCHQ, GSK, HBOS, HSBC, lNG, Motorola, Nordea, Norsk Hydro, Norwich Union, Ordnance Survey, Prudential, RAC, Scottish Power, Swiss Reinsurance Company, Tesco, Boeing, Vodafone, Volkswagen, Volvo, Waitrose attended our annual Enterprise Architecture Conference.

alEA Members Will Receive a 10% Discount on Registration

Register On-line at: http://www.irmuk.co.uk/eac2006/