Journal of ! Enterprise Architecture

May 2006 I Volume 2, Number 2

Feature

Architect's Spotlight: George Paras 8

Articles

Updating the Enterprise Architecture Planning Model 11 Steven Spewak and Michael Tiemann

Lessons from Classical Architecture 20 Alex Pavlak.

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

Applying Pattern Concepts to Enterprise Architecture 34 Robert Cloutier and Dinesh Verma

Case Study

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

A quarte rly p u b licatio n of th e Associatio n of Enterprise Architects An I nternational Forum for Enterprise Architec ture

a\EA www.aeajournal .org JO U RNA L Journal of Enterprise Architecture

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

Associate Editors

Beryl Bellman, PhD Andrew Blumenthal, MBA John Gotze, PhD California State University, Chief Enterprise Architect Department of Informatics Los Angeles U.S. Secret Service Copenhagen Business School

Patrick Bolton, MS Michelle Kaarst-Brown, PhD William Krauter, PhD . EA Practice Lead School of Information Studies Lockheed Martin BAE Systems, Inc. Syracuse University Corporation

Haiping Luo, PhD Stephen Marley, PhD Thomas Mowbray, PhD Senior Enterprise Architect Senior Enterprise Architect Senior Enterprise Architect Department of Veterans Affairs NASA Keane, Inc.

Kristian Hjort-Madsen, MS Matthew Newman, MS Felix Rausch, MS Danish Ministry of Professor, IRM College Executive Director Science, Innovation and Technology National Defense University Federal EA Certification Institute

Ann Reedy, PhD Kathie Sowell, MM Michael Tiemann, MSSM Senior Enterprise Architect Senior Enterprise Architect Senior Enterprise Architect Mitre Corporation Mitre Corporation 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 2 alEA International Committee News and Events 3 alEA Local Chapter Points of Contact 4

Architect's Toolbox 5 Architect's Spotlight: George Paras 8

Articles

Updating the Enterprise Architecture Planning Model 11 Steven Spewak and Michael Tiemann

Lessons from Classical Architecture 20 Alex Pavlak

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

Applying Pattern Concepts to Enterprise Architecture 34 Robert Cloutier and Dinesh Verma

Case Study

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

Scott Bernard, Editor

The May 2006 issue of JEA is our fourth issue We begin the May issue of JEA with "Architect and marks the completion of the first full "set" in the Spotlight" that features George Paras, of this quarterly publication. I continue to be Vice President of Strategy for Troux impressed with the quality and variety of Technologies, a long time mover and shaker in submissions we are getting from authors the EA community, and the Editor of around the world, and I thank each of the Architecture & Governance magazine authors who have contributed thus far. The (www.ArchitectureandGovernance.com). I met August 2006 issue will be somewhat unique in with George in March, at the EAC (EA that it will be devoted to EA standards. We will Conference) in Orlando, Florida. EAC is held resume the regular format of articles and case twice a year and is the longest running and studies on a variety of EA subjects in the perhaps largest ongoing EA event anywhere. November 2006 issue. The "Architect's Toolbox" feature is an analysis of Ala Win by our tool expert, David Rice. JEA will continually be in the hunt for high quality articles on EA that have not been The "Articles" section begins with a wonderful previously published. We are fortunate to now and unique contribution by Steven Spewak have a modest backlog of manuscripts that and Michael Tiemann on "Updating the EAP has put the "submission-to-print" delay at 6-9 Model." Mike and Steve had been months, so authors submitting manuscripts this collaborating on the EAP update when Steve spring and summer (that are accepted by our passed away in 2004, and we a fortunate that Board of Editors) will see the resulting article in Mike was able to finish the work and obtain the February or May 2007 issue. The line will permission from Steve's other business only get longer, so get your articles in soon. colleagues to allow the publication of this Manuscripts are submitted to the Editor at article, which not only makes the EAP [email protected] and the approach more relevant and current, but submission format and guidelines are available represents yet another contribution to the EA on alEA's website at www.aeajournal.org. community by one of the founders.

Please note that back issues of JEA are The next article is a very insightful piece by available for $5.00 plus shipping, order them Alex Pavlak on the lessons that the EA by contacting the Editor via email (see details community can learn from traditional on the inside cover). Also, the Board of architecture. This is Alex's second article in Editors decided in December to begin allowing JEA, and his cogent writing style and insightful advertising in JEA on a limited basis. I have analysis drew some of the highest marks to pushed back the start of an advertisement date from our Board of Editors. The third section to the August 2006 issue due to article by Douglas Findlay provides an various production, notification, and timing interesting look at how EA is being issues. As was mentioned in the last issue, implemented in one of the Federal Aviation this will be done tastefully in a way that and Administration's key business units. The last does not give a commercial feel to JEA. The article by Robert Cloutier and Dinesh Verma is reasons for allowing advertising are twofold: a highly original look at how patterns and the (1) advertising income will supplement recognition thereof are a foundational aspect member dues and help to keep the price of of EA. The featured Case Study is the second JEA as low as possible; and (2) to allow the of a two-part article on how the Department of vendors that support the EA community to be the Interior turned around a troubled EA more visible in a way that maintains JEA's program to become one of the leading neutrality on products and approaches. We architectures in government. will also provide page for members and other independent EA consultants to post a small I hope you enjoy this issue of JEA and I thank advertisement at a nominal fee. you for your support and readership.

International Executive Committee International Standards Committee • Chair: Haiping Luo • President: Scott Bernard haiping@aeajournal,org [email protected] • Vice President: Jaap Schekkerman The alEA International Committee on EA [email protected] Standards serves two related purposes: (1) • Secretary: Kristian Hjort-Madsen identify, develop, and promote international [email protected] standards on enterprise architecture; and (2) • Treasurer: Mike Hall build, manage, and expand an EA [email protected] knowledgebase in aIEA. The Committee is • Resources Coordinator: Tanaia Parker continuing to develop the Enterprise [email protected] Architecture Management Guide that provides a taxonomy of EA topics and candidate EA Since December, the International Committee standards. The Committee has established two has been busy working on the update of the subcommittees on EA tool interoperability and alEA website and the establishment of a new EA meta-model standardization. The linked blogging site. John Gotze (one of JEA's Committee welcomes EA community's Associate Editors), Mike Hall, and Tanaia involvement and contribution. Please contact Parker have been collaborating on these Dr. Haiping Luo at [email protected] if improvements, which will continue thru June. you would like to help with EA standards work. 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 2006 alEA International Conference "Library" tab, accessible only to members. October 2006 - Seoul, Korea Another addition to alEA services is a quarterly electronic newsletter to be sent via email. alEA will hold its first annual International Conference in late October in Seoul, Korea. Just as we did last quarter, alEA welcomes two The conference will feature presentations by new chapters; the New Zealand Chapter and local and global alEA members, industry the New York City Chapter. This makes practitioners, and government officials on EA seventeen chapters plus the "Global-at-Large issues of interest to the international Chapter." Also, alEA now has just over 400 community; including standards, taxonomies, members, with 18% growth seen in the last tools, and methodologies. Registration quarter alone. Please remember that information will be provided in the quarterly renewing your annual membership is done via email newsletter and the August issue of JEA. the alEA website at www.aeajournal.org. Mike Hall (the alEA Treasurer and Webmaster) has added functionality that now allows members 2006 alEA U.S. Conference to update their profiles at any time, including chapter affiliation. This helps members who September 2006 - Washington, DC joined before there was an alEA Chapter in alEA will hold its second annual U.S. their area. Conference meetings in September 2006 as part of a larger government and industry EA As a reminder, back issues are available for Conference at the Ronald Reagan Federal $5.00 USD plus shipping. Orders are placed Building in Washington DC. Details will follow via email with the editor at in the quarterly email newsletter and the [email protected]. August issue of JEA.

International United States

Australia Chapter Delaware Valley Chapter Keith Frampton Michael Robison e4591 [email protected] [email protected] Canada Chapter Dallas I Fort Worth, Texas Chapter Mike Giovinazzo William Krauter [email protected] [email protected]

Chile Chapter Mid-South California Chapter Alfredo Piquer: Kenneth Griesi [email protected] [email protected]

Denmark Chapter Midwest Chapter John Gotze Chuck Ohms [email protected] [email protected]

Global At-Large Chapter New York City Chapter Scoll Bernard Brian Clark [email protected] [email protected] Korea Chapter Seattle, Washington Chapter Hong SikKim Steve Farowich [email protected] [email protected]

New Zealand Chapter Syracuse, New York Chapter Mike Lowe Mike Hall [email protected] [email protected] South Africa Chapter Tennessee Valley Chapter Graham McLeod Jon McKinley [email protected] [email protected]

United Kingdom Chapter Washington DC Metro Chapter John Good Margaret James [email protected] [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.

David Rice

Review of KBSI's AI" Win® 7.0 implementation IDEF-O is nowhere near the When people refer to Enterprise Architecture standard specifications from IEEE and FIPS (EA) modeling tools they are typically referring for symbology and use. to expensive, behemoth tools that attempt to "do it all" and "be everything to everyone." A/0 Win is a very specialized tool that implements IDEF-O well. It does so in a data Considering the volume of data to be collected and rules oriented manner, so that the in many EA projects, and the myriad of forms architect can focus on the job at hand (data in which it is to be collected, a variety of EA collection and analysis) and not on the modeling and analysis tools are often needed. nuances of diagram drawing and remembering Just. as a mechanic's toolbox should have a all the method rules and constructs - the A/0 spanner for a variety of tasks, the toolbox Win tool effectively takes care of that. should also have specific precision tools if the architect is expected to be able to do quality Just to make this perfectly clear, given a set of work across the spectrum of EA activities. activities, related in a hierarchy the tool Sometimes, combining tool functionality is produces the necessary IDEF-O diagrams and called for and the productivity gains of a node trees; given a set of Inputs. Controls, precision tool often justify the investment in Outputs, and Mechanisms (ICOMs) the tool that tool and an interface to a larger EA tool. will produce a fully "drawn" IDEF-O diagram that is properly balanced and validated.

Tool Overview and Purpose The architect can use the traditional views of a A/0 Win is an IDEF-O activity modeling tool, Node Tree and Activity Diagram to input IDEF and one might call it a precision tool for o information, and A/0 Win makes this easy by specific types of EA work. A/0 Win is very auto-placing and auto-drawing the input (and relevant for those following the Department of auto-redrawing and balancing if a change in Defense Architecture Framework (DODAF) or order or hierarchy is made). A/0 Win also for use in many industries that need detailed provides a unique input mechanism called an activity models and where there is a desire to "Activity - ICOM Matrix." In this matrix the work with an activity modeling language that architect assigns 'Concepts' (what A/0 Win has a proven track record and is stable. calls a "yet unassigned ICOM") to an 'Activity' Doubtless the preceding statement will stir up via a matrix by clicking in a cell with the preferences over methodology among many appropriate modeling letter selected: I, C, 0, or architects, and those favoring Object-Oriented M. This attaches the 'Concept' to the 'Activity.' (00) approaches to activity modeling that use The rules engine knows what is attached to the Unified Modeling Language (i.e., Use what in real time and prevents the architect Cases, Event-Trace Diagrams, and Activity from assigning ICOMs in a structure that would Sequence Diagrams) will also have their day in violate IDEF-O rules. You can change levels of a future issue's Architect's Toolbox. the model within the matrix as well, and when you do change levels you find that diagram It suffices to say that in the DoD EA space consistency balancing has happened IDEF-O activity models are the preferred form automatically and the ICOMS are ready for use for completing the OV-5 artifact. That being at the new level. Auto-balancing, rule said, it is also true that the built-in enforcement, and automatic drawing and implementations of IDEF-O in several of the placement are the "magic" the make the use of larger EA tools (e.g., System Architec(TM, and Win A/0 for creating and editing an IDEF-O MetisTM) can be difficult to use and even some model so fast and easy. 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

© Journal of Enterprise Architecture - May 2006 5 Installation on Your PC to the Matrix, and fill in the ICOM information Talk about easy, A/0 Win is essentially a and then change screen windows to the desktop PC-based activity modeling and Diagram view and then see the complete analysis tool, and the installation is actually diagram drawn. Most do not believe it at first, easier than many commercial desktop and then remark about how much time they applications I have worked with. Installing A/0 wasted in doing I DEF-O with other tools. Win takes only a minute or two and is up and running - no glitches noted in my experience. Version Control There really is none in A/0 Win. It is a file Setup based tool so backup your files. 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 Customizability that is essentially a file on your hard drive, but There is a facility to add some user-defined something that is significant to note is that attributes to the Activities, ICOMs, etc., but as what you are actually setting up is a shared far as the types of customizations we have in space for IDEF-O models. You can have tools like Metis and System Architect, this tool multiple models in one file and they can share is nowhere close. common Activities and Concepts, ICOMs, and Sources across these models. Integration Capability IDEF-O has a standard interchange language Overall Architecture called IDL (not to be confused with CORBA In the modeling tool space there are two IDL). A/0 Win supports this language to a classes of tool. Tools that aid in your thinking degree but since it auto-places and routes and analysis process and tools that presume diagrams, it does not store its coordinates so you have done that and need to document the user attempts to use IDL to transport models to results. Most modeling tools fall in the latter other IDEF-O tools resulted in data but not the category. The structure and purpose of A/0 diagrams being transported. Win seems to be for the former. Other interface mechanisms exist, however, A/0 Win's architecture is that of a rules engine such as SVG for diagram rendering, and XML at the core - knowledgeable of the rules of Visio Interface for import and export (a IDEF-O, both of the allowable relationships of proprietary but easily readable text file format). 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 Available Integrations a small amount of flexibility here for building There is a commercial bi-directional integration purposes, but flags the diagram as FEO (For with System Architect. Exposition Only) which is the standard IDEF-O notion for a diagram that does not meet standards. Analysis Capability A/0 Win has extensive Activity Based Costing On top of this rule base are four basic capability as well as integration with KBSI's interfaces for building the IDEF-O model; a other costing tools: EasyABC Plus™ or Node List, a Node Tree, an Activity Diagram, EasyABC Ouick™. and an Activity-ICOM Matrix. These interfaces are interlinked via the data inherent to the model. A change to the model in anyone Reporting Capability interface is immediately reflected in the others Built-in reports are not customizable, but are because essentially they are all co-related in selectable in content,. There is no reporting changing the data. About the most fascinating language such as SOL. I strongly favor thing you can show to someone that is used to building the model in this tool and transporting "drawing" an IDEF-O diagram is to build the the data elsewhere for analysis. That being "Activity Diagonal" in the Activity Model, switch said; the reports for IDEF-O that exist are good

© Journal of Enterprise Architecture - May 2006 6 and should be used if they fit the need. They eighties. Certain common Windows™ notions are neat, clean, and well suited to the purpose are not present, for instance there is no COM of reporting the data in the standard form. interface, a feature found in most Windows tools these days. But what they do well they do extremely well and better than the "Multi Overall Impressions Tool" type tools on the market - and that is a Afro Win is just plain pleasant to use for IDEF good thing for those of us who need it. o model creation and editing. I find it so fast and easy that I would have no reservation about taking it into a facilitated architecture Knowledge Based Systems, Inc. session or one-an-one meeting and doing data KBSI is a privately held company. It has been gathering right in the tool... how many tools in business since the mid-eighties and is can you say that about? Editing an existing largely an R&D shop, but also has had IDEF-O model that was created in another tool, commercially available tools for most of its (particularly one where editing models, existence. Afro Win is one of its most mature changing activity levels, and rebalancing tools and the company founder and President ICOMs is especially hard), is also relatively (Dr. Richard Mayer) was part of the ICAM easy in Afro Win. It is worth investing in an project in which the IDEF methods were interface between Afro Win and larger EA tools developed. KBSI looks to me to be a stable to do this type of model importing and company with a successful track record. KBSI manipulation. can be reached at:

The reporting and analysis functions of Afro Knowledge Based Systems, Inc. Win leave something to be desired, and I favor 1408 University Drive moving IDEF-O model data out of the tool once East College Station, TX 77840 the model is created for those purposes. Phone: 979.260.5274 Fax: 979.260.1965 There are simply stronger reporting tools and www.kbsLcom 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 Tool Cost: way of model analysis. The per-license cost of the Afro Win tool is currently $2,000.00. Annual maintenance is One comment on version and adoption of $400.00. 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 Contact David at [email protected]

George Paras: Vice President of Strategy, Troux Technologies

This issue's "Architect in the Spotlight" is misperceptions about the role of EA by George Paras, Vice President of Strategy for delivering fully across its potential is the Troux Technologies™, who acquired essential element to the success of the Computas and their popular Metis™ EA tool in discipline. early 2005, and is also Editor-in-Chief of Architecture and Governance Magazine. Mr. JEA: What do you see as being the most Paras has more than 25 years of expertise in pressing issue(s) for enterprise architects who EA management processes, organizational would like to make EA a career? effectiveness, governance and communications strategies. He has coached G. Paras: While enterprise architects must and mentored hundreds of private and public possess a broad range of hard and soft skills, sector IT leaders through the launch and one skill stands out in my mind as critical to iterative refinement of their EA programs. Mr. long-term success. The ability to think, Paras has helped establish current thinking on c?n?eptuallze and ~nalyze systemically EA discipline best practices and methods distingUishes an enterprise architect from other through his thought leadership, research, architects. Possessing, or developing, this skill analysis, and evangelism of EA concepts as gives the enterprise architect the ability to Chairman and featured speaker for the traverse all the abstraction levels of the Enterprise Architecture Conference. Prior to enterprise. Doing so provides clarity on where joining Troux in 2005, Mr. Paras was Vice and when to target value activities, sustaining President of the Enterprise Planning and both an EA practice and an individual career. Architecture Strategies group at META GroupTM. JEA: You have been coordinating and/or hosting major EA conferences for over a JEA: Mr. Paras, thank you for agreeing to be decade... perhaps longer than any other EA interviewed as the featured architect for this thought leader. What are some of the insights issue of JEA. Your work in the IT industry, that you've gained into the profession of EA with META Group, and now with Troux through these gatherings, and what direction Technologies gives you a uniquely informed do you think EA is going in? view of changes in the landscape of EA G. Paras: The EA profession continues to practice. In that light, what do see as being attract a steady stream of fresh talent, from all the most important issue that EA faces today industries, that is a real pleasure to see. Many as a growing area of professional practice? of these "newbies" come to EA after successful G. Paras: The continued evolution of EA is careers in other IT and management entirely dependent on its acceptance as a disciplines, contributing their own perspectives. legitimate management discipline. This is no Likewise, established professionals are only small task. Too often viewed as a sub getting better. I see the same architects year specialty within IT, I often see "architecture" after year at EAC. It is very clear that each receive too much emphasis while the year they move to a new, higher level. Many "enterprise" aspect receives too little. To fulfill have become speakers and they share their the promise of EA, the discipline must operate knowledge freely. to transform the enterprise from its current To your second question, I think that EA is state to its strategic future, approaching the going in two directions. First, practitioners are problem from the context of the enterprise as getting very good at the mechanics of system. It must do so by considering all delivering EA models, creating repositories perspectives on EA, from business strategy supporting development teams, and running and capabilities through services, processes, an EA program to produce value. Second, I information and technology. Overcoming think a smaller subset of practicing enterprise

© Journal of Enterprise Architecture - May 2006 8 architects are taking it to the next level and entirety of the enterprise. EA identifies combining EA with IT Governance. These strategic alignment, creates implementation groups are moving closer to the business's principles and rules, and creates reference strategy function, the place I think EA will models as target designs. Even though ERP eventually reside. vendors may solve some of the more hairy problems such as integration middleware, consistent data model, etc. they too will benefit JEA: Service-Oriented Architecture (SOA) has from stable and efficient infrastructure, well gained a good deal of attention in the past defined interfaces between application models, three years. How do you see SOA relating to a consistent corporate approach to information EA? and end-to-end views of business strategies, G. Paras: I think the vast majority of the capabilities, requirements, processes, and market, the analyst firms, the consultants, etc. services. have SOA mostly wrong. They focus too much attention on the promises of the technology of JEA: Troux Technologies produces one of the SOA, to deliver reuse and provide software most popular EA tools; "Metis." How do you development efficiencies. Don't misunderstand advise clients about using an EA tool as part of me, SOA shows promise as a way to help their EA program, and what "expectation solve many problems, but I think what's most management" might you want to conduct with important about SOA isn't the technology, but potential customers? is instead the way· it drives us to look at ourselves and the business. The philosophy of G. Paras: Understand what you want to do, a services approach forces us to think about and why. Before selecting a tool infrastructure, fundamental building blocks, such as business it is critical that the EA group has an services, and how they relate together in the appreciation for the work that goes in and the context of a larger system, the enterprise. value that comes out. One of the most Think about this portfolio of services, the important concepts to grasp is that good characteristics they must have, the rules to decisions require good information, and that combine and recombine them for agility, and many constituencies wind up needing the identify how they deliver value to the same information to solve their separate enterprise, from my perspective that's what EA problems. In the absence of a stable, has always been about. SOA is a very persistent, repository, many EA groups powerful concept we can use to think about recreate information with each new question. organizing and analyzing an enterprise, plus it For that reason, my advice to new EA teams is has the advantage of being directly to consider a tool environment with an "implementable". Furthermore, we now have a enterprise repository relatively early in their hype curve to attach to and use to EA's evolution, if for no other reason than to take advantage, provided we can push through the advantage of that leverage at the earliest noise and confusion surrounding the concept. possible point.

JEA: ERP vendors have jumped on the SOA JEA: Your role at Troux is to develop bandwagon, but seem to be slow to embrace corporate strategy for the company's EA EA. Is this a correct perception? Can EA help services and products. What can you share to make ERP implementations more with us about plans for the next year or two? successful? G. Paras: I believe that there are three critical G. Paras: I think that is definitely a correct elements to success at EA. The first is perception. Read back to my prior answer "transformation" - the enterprise architect must about SOA hype to partially understand the be able to answer the "why" questions of the race to SOA-enable applications, valid business and chart a course to achieve technical reasons notwithstanding. On the EA enterprise transformation goals. The second is front, EA will help ERP implementations as "information" - EA must support and inform all much as any other application implementation. decisions in the context of that transformation Even a full-blown, "all-in" move towards ERP objective in the form of a single, consistent, up by any company cannot hope to include the to-date, version of the truth. The last element

© Journal of Enterprise Architecture - May 2006 9 is "value" - EA must provide value early and products and services do, and will continue to, often, to multiple constituents. Value, of support the growing needs of the enterprise course, is ultimately in the context of the architect across all these dimensions. enterprise transformation objectives. Troux

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 Due Date February November 1 May February 1 August May 1 November 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)

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 EAP model accomplishes this to an even greater degree by virtue of these revisions. The Enterprise Architecture Planning (EAP) methodology, based on its 1992 publication Models are essential to EA, and just as the date and widespread adoption, could be famous Dutch artist M.C. Escher found ways argued to be one of the foundational works to draw images that provided new and in the common body of knowledge of the sometimes provocative views of otherwise practice of Enterprise Architecture (EA). ordinary worlds and the objects in them. To This being said, the EAP methodology and do this, Enterprise Architects must be able supporting model have become somewhat to: dated and require refreshment to capture key aspects of current EA practices and to • See the big-picture (forest) from the ensure that EAP remains a viable approach pixels (trees) for EA implementation. For example, many • Notice patterns and trends where things current practitioners agree that EA is a are going continuing program, not an all-or-nothing • Detect the inconsistencies and short-term project, and the updated EAP consistencies model emphasizes this point. The purpose of models are to help people visualize • View multiple perspectives of the whole otherwise abstract concepts and and its pieces relationships, and hopefully the updated • Separate the idiosyncrasies from the synchronies

© Journal of Enterprise Architecture - May 2006 11 • Distinguish what from how, who, when, This is a good point in the article to mention where and why that one of the reasons we changed the EAP Wedding Cake model was to insure • Articulate the blueprints so that others that as a part of the institutionalization of the not only see and understand them, but EA program that governance is effectively embrace them as well established. We recognize that without it, the migration or transition plans created are just un-validated projects. Only through THE NEED TO UPDATE EAP effective governance do they become a real portfolio of approved transition plan projects. Let me (Tiemann) tell a short story that This aspect is perhaps the most important of captures the essential reasons for updating all of the reasons for changing the EAP EAP. Several years ago the authors were Wedding Cake model and its descriptions. speaking with a colleague, William "Bill" Rummer about the need to update EAP, and The remainder of this article focuses on he said "It's a beautiful little process that is changes to the EAP Wedding Cake model, well organized and simple to understand. Do in that this is perhaps the most well known you really think it needs to be changed?" I and recognizable element of the overall EAP replied emphatically, "Yes and here's why ... methodology... a methodology that is we have learned much about how and why comprehensive in its ability to support the EA works or doesn't work since EAP was first establishment, implementation, and ongoing published, and the fact is that things are maintenance of an EA program in the public changing so fast and so many specialties or private sector. have grown up in and around the practice and profession of EA that to not change EAP would undermine the continued viability of the CHANGES TO THE EAP MODEL approach." As things got going, Steve contributed his own changes. For those who are familiar with the original EAP Wedding Cake model, you should be What happened next was a series of follow able to easily spot the changes. For those on discussions and work sessions between to whom the model is new, the changes are the authors that resulted in a number of in the "Business Knowledge," "Repository subtle but important changes to the EAP Management," and "Program Transition and approach and supporting general model Follow-on Design" areas, each of which (sometimes called the 'Wedding Cake" EA replace a previous model part. model). The simplicity of the approach was preserved in recognition that EAP uniquely In the original EAP method, each area in the enables Enterprise Architects to implement model corresponds to a set of well-defined an EA program and jump-start it by steps in a very organized and ordered EA capturing the primitive artifact information process, as is shown in Figure 1 on the next that is required to quickly and effectively page. Updates to the EAP model are shown populate the top two rows of the Zachman in Figures 2 and 3, also on the next page. EA Framework (Zachman, 1992). Generally speaking, the model works such A review of a number of EA projects that that the process flows from top to bottom had used the EAP methodology revealed and from left to right. Planning initiation that another implementation phase was (shown at the top) is preparation for the needed, where solutions and systems architecture process and not actually part of components are detailed, planned, the EAP implementation steps. EA planning designed, and implemented. This phase should be viewed as a project activity, involves considerably more than a transition usually estimated to take from six to eight plan, rather it is a programmatic months and that usually results in a final go institutionalization of EA and a directed or no-go presentation to a decision-maker development process that continuously uses who would support the EA's implementation. and relies on the EA for direction and correctness.

Planning Initiation

Current Business Systems & Modeling Technology

Data Applications Technology Architecture Architecture Architecture

Implementation / Migration Plans

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

PLANNING INITIATION

M P A R N o A J G E E M C E T N T

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

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 EAP operating environment. Other concerns based architecture projects, that rarely did included the lack of coverage for the senior executives not approve the transition knowledge base or repository management plans. This is because the team doing the for EA information. This is an important EAP implementation usually did its topic that is stressed in EAP courses, but homework, ensured executive level was not very evident in the original model or involvement, and presented an EA plan that EAP book. This is a major change in how was well documented and aligned to the EA is done and increasingly sophisticated business. Executive management had tools and repositories are helping Enterprise worked alongside the EA team for the Architects manage and get value from EA duration of the process, and indeed was programs. presented with options making many decisions over the course of the project. As we learned more about the business Therefore, it would be unlikely for them to area of the EAP model, we know now that reject a recommendation to transition to a the business information defined within the future architecture they had helped to define EA needs to be more than just a simplified and document. Lessons learned from many description of the higher order functions. EAP projects supports early definition of the What is required today is a full set of success criteria that would ensure, if met, business artifacts, describing the business the plan would be approved and the EA knowledge base that integrates the strategic succeed. This criterion is usually initiatives and vision, through the principles established in the Planning Initiation step. and business rules, right down into the processes, tasks and activities. In fact, with However, treating EAP in a project-centric Service Oriented Architectures, these tasks approach could cause the EA process to be and activities must also be translated into viewed as a one-time event, instead an patterns and ultimately become business ongoing program that is an important part of services. So the term "business model" is how an enterprise develops, manages, and too limiting. changes its business and technology

© Journal of Enterprise Architecture - May 2006 14 When I wanted to call this part of the model As EA has evolved and the process has the Business Architecture, Steve felt the become more stringent in requirements for term "architecture" was still too static and details, it has increasingly become limiting in the aforementioned context and necessary to decide on a tool that has more part of the EAP process, so he said "lets just functional capabilities to capture details and call it Business Knowledge." I thought about to graphically represent them in a myriad of it and decided that it made sense given all of articulated views: the various facets that make up the Business Knowledge base. I saw that • Identify, select, and obtain approval of "architecture" could be misconstrued only as time requirements for team members' a limited set of high level functional participation. Team members refer to definitions leaving out the critical details like, the representatives from the business business rules and explicitly defined and units (or staff from the program areas) documented processes, tasks and activities. that will be on the EAP team As EA progresses and evolves, tying into • Identify success factors, obstacles, other popular EA approaches (e.g., Service acceptance criteria, and use these to Oriented Architecture, Model Driven conduct an assessment to determine Architecture) the need for robustness in organizational readiness to do the EAP Business Knowledge will grow.

As a result of our redefining several of the Each of these steps can be further broken elements of the EAP Wedding Cake model, into sub-steps, and there are, of course, a we decided that it was important to get these defined set of artifacts, documents, or changes out to the EA practitioners, and deliverables that are created. consequently we began writing a pamphlet entitled "Using Enterprise Architecture Values & Principles - These stated "Values Planning in Government" (AT&T/PIEAI, and Principles" are basis for starting an EA. 2004). The pamphlet described the They create the basis for all future decisions revisions to the Wedding Cake model in the involving the EA and what's defined within it. context of how EAP could be applied in the Ratified, well-formed principles shape the government, with special emphasis on how foundation for architectural decisions. The it related to and supported the Federal acceptance of those decisions and Enterprise Architecture Reference Models, continuing the on-going management of the which is currently used in EA programs in implementation plan, as well as, the the federal government. The following institutionalization of the EA program are in discussion is an overview of the information a major way resultant from completing this on EAP updates that was presented in the step. pamphlet. • Define supporting values on which to base the effective governance of THE NEW EAP MODEL information and technology that determine proper actions and decisions Planning Initiation - This is the preplanning phase that is critical to setting all of the • Define and approve EA Principles things in place to be able to use an EAP approach to creating an EA. The main Business Knowledge - This is often referred outcomes from the following activities are a to as a business model and sometimes as detailed project work plan and commitment the business architecture. Completing this of resources: step provides the core that inter-relates business strategies to the current and future • Define the "enterprise" and ultimately information technology (IT) architectures the scope of the EAP (and the EA) and implementation plans: • Establish an EA future vision • Install and customize (as needed) a • Identify and relate all strategic goals basic toolset. This used to mean very (Business and IT) to the EA basic tools

© Joumal of Enterprise Architecture - May 2006 15 • Compile a knowledge base about • Facilitate identifying opportunities for enterprise functions, sub-functions, business improvement, strategic goals, processes, activities (and sometimes and current system issues tasks), the information used, the performance measures and metrics, business rules and opportunities for Technology Architecture - This phase is process improvement fitting sometimes hundreds of potential and current technologies (components) to enable different capabilities that the enterprise will Current Systems & Technology - The require, to implement the architecture: outcome of this step is an inventory of application systems, components and • Identify and categorize the capabilities services, data schemas, interfaces and that are required technology platforms that provide a baseline for transition, modernization and or • Establish a standards profile and a migration plans and for utilization in technical reference model operational IT management: • Select various technologies and/or technology strategies to implement • Define and document current (as-is) • Validate the sufficiency of selected applications systems (components and technologies services) and supporting technology platforms to the level of detail required and defined in the Planning Initiation Implementation & Migration Plan (also called step a Transition Plan) - This plan is resultant from the analysis of the gap between the • Use the baseline to establish EA metrics baseline and target architectures. As an in terms of an ultimate return on outcome of this step, the organization will be investment, based on cost savings and ready to begin transition to the future (to-be) avoidance from economies and architecture through an organized and elimination of unnecessary redundancy prioritized plan: and duplication and other similar results • Make judgments about including or Data Architecture - The outcome of this step excluding current systems is a common business language that • Determine sequence for implementing enables improved and consistent applications, components and services communication across the enterprise: • Schedule resources and times for implementing projects • Define major kinds of data to form basic vocabulary for business language • Analyze net cost-benefit and ROI to feed business cases • Assign critical attributes • Develop master project plan for a program transition period after EAP Applications Architecture - As a result of this step, identifying the systems required to support the business, the team will be Programmatic Transition & Follow-on equipped to address operational capabilities Design - After completing the EAP, and characteristics in applications and management receives final reports, components (and services) that are required deliverables, electronic databases, files and to manage and utilize data and information: presentation of results, but then, needs to begin the transition into an EA Program. • Define sets of capabilities to manage The EA Program is a continuing function or data set of activities that not only ensures the updating and upkeep of the EA and the • Develop the (create, read, update, or transition plan, but also integrates with the delete-CRUD) relationship to the data governance and budget decision processes. Ultimately, it also integrates the IT operations and the systems, services and

© Journal of Enterprise Architecture - May 2006 16 components design, development and work breakdown structure (WBS), specific implementation steps as well. Additional deliverables and in some cases a activities that could fall within this phase are: performance metric approach like Earned Value Management or at least completion • Institutionalize use of architectures and criterion. The specific things covered are: procedures to keep architectures current • Oversee required EA reporting and • Develop a detailed project management funding mechanisms plan (that will eventually morph into a • Ensure that IT designs, upgrades, and continuing annualized EA Program implementations are continuously Management Plan) synchronized with architectures • Develop a Work Breakdown Structure • Update EA policies, standards, that identifies specific deliverables guidance, and procedures aligned to specific completion objectives • Recommend acquisition of new • Provide periodic reports or briefings on technologies. status and completion of the EA • Establish positions and training programs for new skill sets to support Repository Management - As EA methods EA work and governance and programs have evolved, it is becoming • Prepare for implementing architectural increasingly important that the correct blueprints establishing linkage to modeling tools and a very efficient System Development Life Cycle (SDLC) repository, both with appropriate or other implementation approaches and configuration management and appropriate or strategies, including the Model Driven security administration are in place to Architecture and/or Service Oriented support the EA and its various uses. This Architecture has become a niche area within EA that is both specialized in some ways (working and used EA Modeling Tools) and common to Additionally, in the new model there are now other systems and supporting knowledge two areas "outside" of the model's management capabilities for projects and components that are key to the programs (operating and managing a portal implementation of EA. These are the or repository system). Some of the specific "Project Management" and "Repository areas of requirement are: Management" elements. These elements of the model are shown on either side, • The identification of a tool and or because they tend to be important aspects repository to support the EA of the overall processes of defining and doing of the EA, throughout. When I • The acquisition of the toolset and lor suggested to Steve that we should use the repository and its implementation with second area to emphasize the repository configuration management and proper management function, which just like Project security and systems operations Management, was also required and management important throughout the process, he • The training of the EA team and others thought it was a great idea. It emphasized, to access and use the tools and the he said, as he taught in his EAP classes, repository that the building of the EA knowledgebase • The continuous updating (and (managed in the form of a repository) is versioning) of the EA artifacts and important. The key facets of each of these documentation into the repository aspects of the process, as we revised them, are Project Management and Repository Management. CONCLUSION

Project Management - Any activity of any The revised EAP Wedding Cake model is an scope these days in the enterprise will be important part of the refreshment of the EAP managed as a project that has a schedule, a approach. This refreshment helps to

© Journal of Enterprise Architecture - May 2006 17 strengthen and reconnect EAP to the helps our community of enterprise architects continually evolving stream of EA to continue to use and benefit from the EAP methodologies that are in use globally. In methodology that helped set much of the the Foreword to the original 1992 EAP book, initial common body of knowledge for EA John Zachman stated that his EA process in place. Lastly, I have been in Framework identifies what to define, but the touch with Stefan DeVocht and Gary EAP process was the first published and Matyas, both of whom were good friends practical approach to tackling how to and business partners of Steve. They develop and document this information in reviewed this article and support its Zachman's top two rows. In our update to publication. It is my hope that at some point the EAP model, we have presented several in the future that we (Stefan, Gary and I) can significant changes that reflect updates in provide a follow-on article that revises the how and when to do EA that we felt were entire detailed set of EAP processes and needed to advance and refresh the originally materials, so that this approach remains defined process. This will help make EAP relevant in all aspects. more current and hopefully still very useful in understanding how to do EA in the public It should also be noted that "Enterprise and private sectors. Architecture Planning" (EAP) and the 'Wedding Cake" are registered trademarks of the Enterprise Architecture Institute, now AUTHOR MIKE TIEMANN'S NOTE doing business as Partners in Enterprise Architecture Institute (PIEAI), and are used While this article was drafted by me, the with permission. material was created collaboratively with Steve Spewak before his death in 2004. Therefore, it seemed fitting that we both be AUTHOR BIOGRAPHIES listed as co-authors, especially since EAP is his very original and unique creation. Steve Dr. Steven Spewak continues to be was a really smart guy who was as talented recognized internationally as one of the as he was witty and fun. He used to come principal founders of the discipline of over to my house and I would have to pry Enterprise Architecture, who developed a him loose from the baby grand piano to go number of practices that are common to do work, like our discussions that lead to this many EA approaches, including the first article. He could play the rock opera methodology, multi-dimensional model, and "Tommy" by heart. the concept of principals that EA implementation should be based on. Dr. The characteristics of an enterprise architect Spewak's seminal book "EA Planning: A listed at the beginning of this article are from Blueprint for Data, Applications, and an inscription he wrote in an M.C. Escher Technology" (1992) not only popularized the collection book, which he gave me as a term 'Enterprise Architecture,' but also present when I came to work with him at presented the myriad of concepts and AT&T Global Services in the 2002-2004 practices in an easy to understand manner timeframe. We both liked Escher and that helped many architects implement EA appreciated the analogies to our work. programs in the public and private sector. Dr. Spewak passed away in March 2004. All of us who call ourselves Enterprise Architects are indebted to Steve and his Mike Tiemann is a senior IT management thought leadership in creating and teaching consultant with Booz [ Allen [ Hamilton, EAP to so many people over the years. specializing in Enterprise Architecture. He is EAP influenced a number of other EA a graduate of Texas A&M University, where approaches including the Federal EA he earned a bachelor's degree in Framework (Federal CIO Council, 1999) and architecture, he also holds a MS in Systems the EA3 Cube Framework (Bernard, 2005). Management from the University of It is my hope that this article not only shows Southern California. Prior to joining Booz how Steve was thinking about updates to Allen, he was the EA Practice Director with EAP, but also refreshes his legacy and AT&T Government Solutions and completed

© Journal of Enterprise Architecture - May 2006 18 a distinguished career in the federal Bernard, S. (2005). An Introduction to government, including the position of Chief Enterprise Architecture (2"d Edition). Architect for the Department of Energy. He Authorhouse, Bloomington, IL. was DOE's representative to the Federal CIO Council's Architecture and Spewak, S. (1992). Enterprise Architecture Infrastructure Committee and was the Planning: Developing a Blueprint for Data, founding Chair of the Federal Architecture Applications, and Technology. John Wiley & Working Group. Mr. Tiemann, who currently Sons, New York, NY. chairs the Governance Subcommittee of the Industry Advisory Council's Enterprise Zachman, J. (1987). A Framework for Architecture Shared Interest Group, has Information Systems Architecture. IBM written and lectured widely on various Systems Journal. Vol. 26, No.3, pgs 276- aspects of EA. 290. Zachman, J. (2002). The Zachman REFERENCES Framework for Enterprise Architecture. Zachman International (www.zifa.com). AT&T / PIEAI (2004). Using Enterprise Architecture Planning in Government, Version 2.1. Published Monograph.

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 There is confusion over basic questions such as: What is the purpose of EA? What is the Classical architecture reflects thousands of difference between architecture and years of history and involves several mature engineering? What comes first, the to-be of the disciplines. The definitions, models and as-is? Is the to-be stable or variable? processes are well established and reflect a good deal of experience and wisdom. The intellectual basis for this article is traditional systems architecture (Rechtin, 1991). This In contrast, EA is an evolving discipline and article shows that EA closely corresponds to today's practice reflects its information systems classical architecture as reflected through origins. There is a tendency to look at EA from Rechtin. There is little need for new terms and the perspective of information technology (IT). special processes. This is particularly true if we

© Journal of Enterprise Architecture - May 2006 20 follow tradition and split EA, as currently & Champy 2003). Huge productivity gains come practiced, into an architectural stage and an from eliminating steps that are made engineering stage. unnecessary by information systems. The correspondences between EA and system I've concluded that both business process and architecture works well because the enterprise information systems need to be viewed as itself is a system; by Rechtin's definition a having equal importance when creating to-be complex assembly that performs a function structure of the enterprise. greater than the simple sum of the parts. Note that this definition is broader than the EA convention of defining a system as an EA RELATIONSHIPS information system. Other views of classical architecture such as It is appropriate to begin by defining terms. Alexander's patterns (Alexander 1964) are also Since terms are most useful if they are defined illuminating. However, at the current state of EA in the context of their use, every effort has been development Rechtin's system perspective is made to keep these terms consistent with most useful in addressing basic questions. classical architecture. Creating non-traditional definitions causes considerable confusion.

• Architecture 1: the structure of components THE IMPORTANCE OF PROCESSES and their relationships • Architecture 2: the practice of creating I begin with a most important message from architecture. Starts with a general need, private sector case studies: the big performance produces an actionable specification gains come from reengineered business processes, that is, new processes made feasible • Engineering: starts with a specification, by IT. Simply automating existing processes is deduces the design of a product/process usually disappointing. that optimally satisfies the specification • Business Process: an activity that creates For example, in the mid-1980's Ford™ an output by adding value to an input. The automated its accounts payable system and processes can be administrative or mission reduced that department's size from 500 to 400 specific people. At the same time Mazda™ was • Enterprise: an organizational unit defined by performing the same task with 5 people. The a clear purpose difference is that Mazda employed new processes that took advantage of IT. Ford was • Enterprise Architecture (EA): the automating processes that evolved under a architecture of the enterprise, the structure paper-based system (Hammer & Champy, of the relationship between business 2003). processes and information systems • System: any organized assembly of Case after case reinforces this same lesson. resources and procedures united and Wal-Mart™ spends an extraordinary effort regulated by interaction or interdependence clarifying essential value-added processes and to accomplish a set of specific functions. eliminating unnecessary busy work. Over the (DoDAF, 2003,) ,.-...... - past ten years modern corporations have evolved from functional organizational structures The purpose of an organization is typically into flat process-based structures that rely expressed in mission/vision statements. The heavily on process teams. organization's senior managers then create a strategy and a strategic plan to achieve this Automating existing processes with information purpose. This business strategy defines the technology is analogous to "paving old cow scope of the enterprise, as is illustrated in Figure 1 paths," improving productivity by 10-30%. On on the next page. the other hand, IT-enabled reengineering can improve productivity by 500 - 1000% (Hammer

© Journal of Enterprise Architecture - May 2006 21 Private sector experience suggests that EA Business should place processes and information systems at a level of equal importance. Business Strategy Strategy requirements can be satisfied in a number of different ways. There is more than + one set of business processes that can execute Enterprise the business strategy, and some of these processes would be easier to automate than Architecture others. Likewise, there is more than one t information systems configuration that can t. automate anyone of the business process "- ~ option. This paper posits that a primary purpose Business Information of EA is to understand this relationship and develop appropriate combinations of business Processes Systems processes and information systems. Figure 1. EA relationships

IT ALIGNMENT wants a "dream house." As the client is often Business unclear about exactly what is a dream house, Early efforts to control IT Strategy there is more than one feasible solution. Only cost aligned IT investments the client can decide which is satisfactory. The with business needs. The ~ architect's challenge is to create feasible resulting relationships are structures that have the potential to satisfy the illustrated in Figure 2. Business needs of a specific client. Existing business Processes processes are presented The solution approach is hypothesis testing. as requirements for the + The architect explores the range of feasible development of information Information solutions. For the homeowner client, the systems. A good definition architect prepares models, sketches, rough cost Systems of this relationship is estimates, and presents alternatives to the client Enterprise Wide for selection. The architect's presentation Information Systems Figure 2. Information contains no more detail than necessary to clarify Architecture (EWISA). f;ystems architecture the fundamental choice. relationshi~s The client then chooses a concept. Each EWISA relationships reflect the IT origins of EA. alternative concept has a different mix of cost, Looking up at the enterprise from the performance, schedule and risk. Each perspective of IT, one expects the organization alternative is feasible. Client satisfaction is a to provide requirements. EWISA achieves value choice. There is no optimum, no objective efficiency gains through commonality and basis for choosing one or another. Anyone of standardization but does not realize the large the alternatives is a feasible solution. As is gains resulting from IT-enabled reengineering of shown in Figure 3, the basic development model business processes. While EWISA is a rational is a waterfall, variations of which are presented intermediate development stage, it is necessary in most systems engineering textbooks. for EA to evolve beyond EWISA GENERAL NEED ~ PRELIMINARY CREATE SPEC THE CLASSIC DEVELOPMENT WATERFALL ALTERNATIVES ~ . ..,.. ~=" FINAL Classical architecture can be described as a CLlENT~ SPEC CHOICE ~ dJ" problem solving approach for ill-defined ENGINEERING ~ problems; problems that have more than one DESIGN ~ feasible solution because the goal is defined in BUILD general terms. The archetype is a client who Figure 3. Basic Systems Development Model

© Journal of Enterprise Architecture - May 2006 22 In military systems client choice is a "concept Managing the architectural stage is substantially decision" that kicks off system development different than managing engineering design. (0001 5000.2, 2003). Selecting architecture, the Engineering design tasks can be partitioned and client choice, is a major milestone that changes employ thousands of workers. In contrast, the character of the project. creating to-be alternatives requires a unified vision, a holistic view of the whole concept. This Prior to client choice, the project is all about is the province of small teams. The best way to alternatives, potentials and possibilities, create to-be architectures is to construct special fundamental structure, form, balancing, and expert teams (Pavlak, 2005). needs. Client choice, the selection of architecture, results in a unique concept Skill sets are another reason for separating the definition, a structure, a preliminary specification architectural stage from engineering design. The that begins an engineering effort. Engineering architectural stage requires inductive reasoning; begins with the preliminary specification and is think outside the box. The engineering design all about the design and optimization of a stage requires deductive analysis, attention to product that can be built. The end result of detail. At high skill levels, these two skill sets are engineering design is a final specification. generally incompatible and the different stages are likely to need different people.

nterprise --1-'

GENERAL Transition 4 To-be - plan NEED i=,==~:::::- HarchitecturE - H- 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 execute a strategic plan. The problem has more development waterfall (Figure 4) should follow than one feasible set of business processes and the same sequence as the basic development more than one feasible information system. The waterfall. For EA, the general need is the architectural challenge is to determine what business strategy; there is more than one way to structure the client finds to be most satisfactory.

© Journal of Enterprise Architecture - May 2006 23 standards" in classical architecture. The As in basic development, the architect explores framework is not the structure of the enterprise the range of structural options. Typically there but a method for expressing the structure. will be a small number of fundamental design drivers that dominate the analysis. The architect In classical architecture, the client chooses characterizes each approach to illuminate the architecture on the basis of sketches and fundamental choices. This is a high level models of the building and its important features. characterization. The level of detail should be For client choice, the architect will focus on what sufficient to specify each so there is no is important to the client and clarify distinctions confusion between alternatives. This between alternative structures. Too much detail specification includes requirements, rough is counterproductive as it obscures fundamental estimates of cost, performance, schedule, and distinctions. At this stage there is no need for risk. Too much detail during the architectural details such as wiring diagrams. stage obscures the client's fundamental choices. As in basic development, client choice is a major This paper suggests a "thin" EA development project milestone. The selected concept has a framework (see Figure 4), as the analog to "to-be" architecture defined in sufficient detail to classic architecture sketches. Thin Framework initiate engineering design. includes only those framework elements necessary to characterize fundamental structure Client choice initiates the high manpower - to distinguish between options and support engineering design stage. By selecting a to-be rough estimates. architecture, the client is buying into the project. The client is committing to certain levels of cost, Using the Zachman Framework, Thin performance, schedule, and risk. Framework to-be architectures would consist of a complete description of Scope, and partial high-level descriptions of the Business and WHO IS THE CLIENT? Information Systems models. The Technology Model, Detailed Representation and Functional In our archetype, the homeowner, the person System contain more detail than necessary to with the checkbook, makes the client choice. For describe fundamental structure. EA, the client is the person or the group responsible for achieving the purpose that This article also suggests that a "Fat defines the enterprise. Framework" is the EA analog to detailed engineering design description. The "Fat For certain situations such as a large politically Framework;" is a set of framework elements with sensitive organization, the client can be sufficient detail to document the design. (Since constructed for the purpose of selecting the to the design has architecture, documenting the be. In this case the client could consist of major design also documents the arChitecture.) stakeholders. Encouraging such a group to reach a consensus requires some attention. ENGINEERING DESIGN STAGE

FRAMEWORKS In classical architecture, client choice produces a specification that initiates engineering design. Various frameworks have been developed to For a new home, engineering design consists of provide a common basis for describing code compliant detailed drawings and a list of enterprise architectures. The Zachman materials for builder quote. For a new bridge or Framework consists of data artifacts organized skyscraper, engineering design consists of in a way that helps the architect think about detailed structural analysis, authorized working structure in a disciplined manner (O'Rourke, drawings, detailed drawings, schedules and 2003). Another well-developed framework is the materials specification. Department of Defense Architecture Framework (DODAF 2004). As in classical architecture, the enterprise engineering design stage begins with a The view posited in this article is that preliminary specification, the client selected to frameworks are analogous to "drafting be architecture. The purpose of engineering

design is to prepare a detailed description of the In contrast, engineering design does change to-be enterprise and a transition plan that and evolve with changing requirements and migrates from the as-is to the to-be. Based on improved technology. During its life cycle, an this engineering design, the client can purchase aircraft like the U.S. Air Force's B-52 bomber information systems and begin to migrate to new has undergone endless engineering design business processes. upgrades to engines, avionics, sensors, and weapons. However, its basic form - airframe, As is shown in Figure 4, the Transition Plan payload, range - has been stable. This paper migrates between an as-is and to-be enterprise posits that this stable underlying form is the states (not architecture). The transition that architecture of the aircraft. Indeed a "robust" needs to occur is to migrate from one enterprise architecture can be defined as one that can design state to another. An enterprise design tolerate substantial engineering design changes description contains more information (e.g., without changing its basic form. interface specifications) than an architectural description of fundamental structure. It is not While classical architecture suggests that the to clear how to migrate from one architectural state be enterprise architecture should be defined in a to another without including more information way that it is stable during its life cycle, a more than necessary to characterize fundamental compelling reason to do so is that a stable to-be structure. has great value to the client. A stable to-be architecture provides the basis for long-term The risk associated with an EA project is highly investments. The client can make commitments contingent on the quality of the transition plan. with confidence that the whole structure will not With a distant to-be architecture as a goal, a be scrapped in a few years. simple gap analysis may not be sufficient. The gap may be too large for simple transformations. Still another reason for a stable to-be is that it It is not necessary to proceed in one fell swoop. provides a target for aligning current decisions, Indeed, the first stage in most engineering for engineering the enterprise. The to-be design design programs is critical item development. is likely to be implemented in stages, one sub For EA, this could include pilot programs to system now, one later. The stable to-be verify business process models and high-risk architecture is the glue that ties it all together. aspects of the information system. A transition plan can proceed in a sequence of steps with stable intermediate stages. At these CREATING THE TO-BE ARCHITECTURE intermediate milestones, the client can judge progress and change emphasis or even Knowing what we know about the business terminate the project. Intermediate milestones today and information technology available substantially reduce the risk of migrating to a to today, what should the enterprise look like? be enterprise that is substantially different than What is the high value concept, the fundamental the as-is enterprise. structure?

Classical architecture suggests that EA should TO-BE ARCHITECTURE AS A STABLE GOAL begin with the to-be architecture. It starts with purpose, the enterprise business strategy (see In most classical architecture domains, once the Figure 1). An architecture team explores client chooses an alternative, the selected alternative structures from the perspectives of architecture does not change during the project key stakeholders and IT. The team focuses on life cycle. Homes, bridges, buildings, weapon system drivers, those functions that primarily systems, chemical plants - once the client determine performance. Synthesis, the creation chooses a concept, the development waterfall process, is accomplished through aggregation, proceeds into engineering design and there is partitioning and balancing (Rechtin, 1991). no feedback. (spiral development occurs within engineering design.) There are exceptions of Patterns and reference models are useful in course but these exceptions tend to be costly, a organizing this. The product for each alternative failed architecture. is characterized by high level partitioning allocated to business process and information systems. The result is a small set of balanced

© Journal of Enterprise Architecture - May 2006 25 alternatives available for client choice. article posits that the primary structural question - the purpose of EA - is to determine the Alternatives result from the fact that there are relationship between business processes and generally more than one feasible model of the information systems. business and more than one feasible model of Well-defined problems can be solved by logically the information system scope is common across deducing a solution. This is engineering, which all alternatives. Several salient points: begins with a specification. With EA, the relationship between business process and 1. The purpose of to-be alternatives is to information systems is not well defined. There is provide the client with the basis for a value more than one feasible solution. When the choice. problem is not well defined, the classical 2. Client choices should be fundamental. approach is to split the project into two Beware of too many options and too much sequential phases, an architectural phase detail that obscures fundamental structure. followed by an engineering phase. This is the 3. Ideally, the to-be time frame should be far basic development waterfall. The transition enough in the future so that structure is between the phases two is a to-be architecture, independent of legacy systems. Legacy generally chosen by a client from a finite set of alternatives. systems are accommodated in the transition plan. If the project is split into architectural and 4. In most cases, the number of fundamental engineering stages, the concept of EA feasible fundamental combinations of frameworks needs to be clarified. The business processes and information system suggestion made in this article is to think about options will be small. Thin and Fat Frameworks. A Fat Framework is 5. The to-be design can be a radical departure the usual fully populated description that from the as-is enterprise yet still be low risk. presents the result of a complete engineering Risk is mainly a function of the transition design. The Thin Framework contains only plan. enough information to characterize fundamental 6. The IT aspect of the to-be architecture is a structure: the to-be architecture. logical structure, technology free. In the Zachman model, a Thin Framework 7. Client choice results in a stable to-be consists only of Scope and architecture that initiates engineering high level descriptions of the Business design. Model and Information Systems Model. 8. Client choice also means client buy-in. Classical architecture suggests that the to-be EA The architecture team must have experience should be stable. Since it represents and judgment, the ability to differentiate between fundamental structure, it should not change with what is absolutely essential from what is merely evolving requirements and new technology (the important. In addition, EA involves the synthesis design changes, but not the architecture). A of two deep disciplines: business process and stable to-be has value to the enterprise because information systems. Experts in these it provides a stable basis for long-term disciplines have vastly different cultures and investment and a distant target for current values. Communication would benefit from decisions. facilitation. The creation of to-be EA is not a high cost effort but is critically dependent on quality of Creating the to-be architecture involves execution. exploring the relationships between business models and information systems models:

SUMMARY Knowing what we know about the business today, and information technology available The private sector clearly teaches us that the today, what should the enterprise look like? greatest productivity gains comes not from What is the high value concept, the fundamental automating existing business processes but structure? through eliminating processes that are made unnecessary by information systems. This

Dr. Alex Pavlak (PhD, ME, PEl is an engineer DoDI 5000.2, "Operation of the Defense and independent consultant. He has led several Acquisition System," 2003, (available online at: major projects that involved creating systems http://www.dtic.mil/whs/directives/ architecture. This includes a 1985 project that corres/pdf2li50002p.pdf). synthesized the architecture of an unprecedented submarine sonar system. He DoDAF, "The Department of Defense offers training workshops, guest lectures, Architectural Framework," v1.0 Deskbook, 2004, coaching and consulting services for Special (available online at http://www.defenselink. Expert Teams, problem-solving, advanced mil/nii/doc/DoDAF_v1_VolumeJpdf). teamwork, and creating architecture. For the past thirteen years, he has been investigating Hammer, M., Champy, J. (2003), Reengineering the limits of expert problem solving teams. the Corporation; A Manifesto for Business Under grants from NSF and NIMH, Dr. Pavlak Revolution" Harper Collins Publishers, Inc., New has setup scientific expert teams addressing York, NY, 2003, p. 35. fundamental problems in basic science. Prior to 1992, Dr. Pavlak spent 25 years managing a O'Rourke, C., Fishman, N., Selkow, W., wide variety of research and development Enterprise Architecture Using the Zachman projects. He can be reached at Framework, Course Technology, Boston, MA, [email protected]. A more detailed biography 2003. and significant publications can be found online at http://mywebpages.comcast.netlthales/ Pavlak, A., "Simplifying the Creation of EA with Expert Teams," Journal of Enterprise Architecture, 1:1, August 2005, pp. 29-35. REFERENCES Rechtin, E., Systems Architecting: Creating and Alexander, Christopher, Notes on the Synthesis building Complex Systems, Prentice Hall, of Form, Harvard University Press, Cambridge, Englewood Cliffs, NJ, 1991. MA,1964.

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 The Department of Defense Architecture Framework (DODAF) addresses this human As a relative newcomer to the field of side. According to a May 9, 2003 memo from the management science, Enterprise Architecture Department's Chief Information Officer (CIO) on (EA) is a maturing discipline (Boddie, 2005). Net-Centric Data Strategy, one of the key steps Enterprise Architecture is a byproduct of the to successful implementation is to leverage the Information Age, and it joins a long list of fairly successes of existing Communities of Interest recent initiatives in management science. (COl). This implies that there is already some Sometimes disparagingly called the "flavor of the type of EA-like activity in existence, even if by month," many of these initiatives undergo a another name and that there may be EA painful yet mercifully short lifecycle of emerging, products available as well. There is other surging, and purging (Best, 2006). If for no evidence to support the notion of EA products other reason than this, aspiring enterprise predating EA itself. Ira Grossman, who chairs architects must focus more on the human side of the Chief Architects Forum, says that EA, rather than on enabling technologies. architectures already exists in organizations, and that EA seeks " ... to make it more efficient "If enterprise architecture doesn't produce and interoperable." (Perera, 2005) results, then it simply is going to be the next thing that gets blown away." - Dick Burk, OMB The Federal Aviation Administration's (FAA) Air Office of E-Government and Information Traffic Organization (ATO) resembles DoD in Technology (Perera, 2005). several important ways. As a tactically-oriented service organization, it continuously conducts large-scale operations in a highly dynamic

© Journal of Enterprise Architecture - May 2006 28 environment. Upgrades to its information traffic control computer system was technology (IT) infrastructure, as well as commissioned in New York. The NAS has been changes to IT-intensive processes, must not managed by a number of oversight and disrupt ongoing operations that effect safety of development programs, which now includes the flight in U.S. and international airspace. The bulk NAS Architecture Program, that have weighed of the FAA's "tactical decisions" occur as events costs and benefits of infrastructure investment unfold in the theatre of operations, far from the since 1965 (Preston, 1998). Though it has insular world of headquarters management. evolved significantly over the years, cultural From my prior experiences as a U.S. Marine and norms affecting the development and approval my current work with the FAA, I've observed that of investments in IT resources that support NAS both of 000 and FAA have particularly strong operations are well established throughout all cultures, especially in terms of being mission levels of the ATO organization. oriented. If EA is to succeed in the ATO, it must There are significant differences as well. The complement and enhance existing cultural military has relatively clear lines of authority, and norms, rather than displace and disrupt the time obeying orders is a fact of life. II's unrealistic, tested approach to developing and approving however, to expect military discipline to be a critical operational services and core business cornerstone of the culture of a civilian agency. processes. Like 000, the ATO must make full While the ATO has lines of authority too, I've and effective use of its communities of interest observed them to be somewhat diluted in so the people of ATO claim ownership of EA, comparison to 000, relying more heavily on rather than consider it to be the latest external consensus-driven decisions. Though being mandate in a long and painful string of less than mission-oriented is part of the culture of both successful (and unwanted) government organizations, it's well understood that military management initiatives. 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 FIRST STEPS world adversely impacts the FAA's most critical performance measures (FAA, 2005). Though many things must occur for EA implementation to be considered a success, FAA Chief Operations Officer Russ Chew has none of these will matter without an effective been strengthening ATO's safety culture since communication strategy to lead the way. In my he joined the FAA in 2003. For example, he discussions with numerous academics and created a safety program that impacts all practitioners who work in the field of information proposed changes that affects operations in the resources management, it is a commonly National Air Space (NAS), and these proposed accepted fact that cultural change is far more changes must now undergo a formal "Safety difficult to institute than technological change. Risk Management Evaluation" prior to approval According to Con Kenney, Chief Enterprise (FAA, 2004; Shane, 2005). The result is that Architect for the FAA, "It's easy to change change proposals require more time and technology, but you spend most of your time resources go through the preparation and changing culture." (Kenney, 2005). approval process, which may serve to promote stability within the NAS architecture for the sake "Nothing is more difficult to introduce than a new of maintaining established levels of safety, but order. Because the innovator has for enemies may also make needed changes more difficult to all those who would have done well under the implement, thereby reducing agility and driving old conditions and lukewarm defenders in those up operating costs beyond what is needed to who may do well under the new." - Nicolo maintain requisite margins of safety. Machiavelli, 1515

The FAA has long been involved in finding and CIO Magazine reported that Bill Godfrey, the managing IT solutions, and the ATO (including CIO of Dow Jones, first tried implementing EA its forerunner organizations) has a long history with a fully empowered Chief Architect. This of managing its own IT infrastructure. The effort failed largely due to uncooperative business of air traffic control has depended upon business units that perceived EA as an obstacle computers since 1963, when the world's first air to getting the technology they wanted. The

© Journal of Enterprise Architecture - May 2006 29 second EA attempt at Dow Jones, using a NEXT STEPS federation of architects from its business units, failed as well - this time due to business units We can apply a hybrid central/federated EA co-opting their architects to get what they implementation approach to ATO with minimal wanted in the first place. Their third EA attempt, adjustment to its existing NAS Architecture ongoing at the time the article was written, program by giving the FAA's Chief Enterprise appeared to be making headway by combining Architect a place on the NAS Configuration the best features of the two previous tries. This Control Board (CCB), the decision-making body consisted of a federated approach led by a for proposed changes to the NAS. The Chief strong central figure, resulting in what Mr. Architect could report directly to the CIO and, as Godfrey called an "Architecture Zoning Board" a full CCB member, could significantly influence (Koch, 2005). IT spending decisions.

Anyone who has faced a Community Zoning But from a practical standpoint, the FAA Chief Board would know that getting approval for Enterprise Architect would spend most of his proposed changes can be a daunting task. time working closely with system developers, Overcoming resistance to change with a who'd act as a de facto federation of architects, perceived obstacle to change is a risky for each program area within the NAS proposition at best. Enterprise Architects that Architecture program. The greatest risks to are members of review boards would be wise to successful implementation appear to lie in the avoid being perceived as "Dr. No" so they don't human side of organizations. For this reason alienate the very people they need for ongoing the Chief Enterprise Architect should spend the EA program support. bulk of his energy in working with and understanding the needs of the federated By refocusing from the bureaucratic side of EA architects. And this particular approach to its human side, there are better opportunities coincides with Mr. Kenney's philosophy that, to be exploited. In my discussions with Mr. rather than express and promote his Kenney, he described his role as Chief professional opinions, it's more effective to study Enterprise Architect as one of being a "hero and learn from others. builder." His preferred methodology consists of listening and learning. As an example, instead of This studious learning approach is a practical preaching EA to the NAS Architecture's application of the premise that people are communities of interest, he gathers information basically honest, motivated, and willing to work. on existing and developing solutions. "I'd much Commonly known for decades as the Theory Y rather have them come to me totally frustrated approach, it may be the best choice for EA with the non-NAS [administrative] side [of their implementation. Theory X, which conversely organizations], desperately looking for help. proposes that people must be compelled to Then I just connect them to someone else who's work, may seem like a preferred approach for got a potentially useful solution for them." In some ideological EA purists. Douglas McGregor finding and linking these people together, Mr. states in his seminal book "The Human Side of Kenney is virtually connecting the dots so his Enterprise," both of these approaches may be federation of NAS architects can willingly take self-fulfilling prophesies, giving both ownership of EA (Kenney, 2005). perspectives considerable validity (McGregor, 1960). Yet given a choice between willing On a related note, Mr. Kenney is particularly ownership versus reluctant compliance, seeking conscientious about how not to work with out ideas and building heroes seems like the communities of practice. In a cautionary tale better option. alluding to DoD's Net-Centricity approach, he says he avoids the temptation to co-opt them, which could compromise their natural BUILDING ON SUCCESS entrepreneurial nature (Kenney, 2005). 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

© Journal of Enterprise Architecture - May 2006 30 is a risk of trying to do too much too soon, as for them to handle the challenge of well as the risk of producing nothing of tangible changes that they must inevitably face." near-term value to the organization. With this in mind, the work of understanding the human element of EA should flow into a somewhat MEASURING SUCCESS political approach to implementation: Architects should work to cultivate communities of What is success? To measure it, one must first stakeholders that have bought into EA rather be able to identify it. EA may be a way to better than attempt to force-feed the entire manage IT resources and align them to an organization. The very notion of EA is organization's mission. However, EA is also enterprise-wide, and it inherently motivates EA about managing change, and the most profound disciples to think big. EA is more than theory, organizational change is transformation. A and needs more than debate. Successful EA bureaucratic organization uses standardized implementation starts with winning the small yet business processes, and bureaucracies typically strategic battles in the real world, building and deal with change by trying to eliminate it. But combining a progressive string of successes. change is not only a fact of life in the information When it comes to EA implementation, progress age, its pace is accelerating. So it would be is far more beneficial than perfection. wise to implement processes that are designed to accommodate change rather than pursue an It is not enough to focus on tallying up increasingly futile attempt to eradicate it. This is communities of interest. Quite simply, there may one of the most powerful aspects of EA: a way be too many COls to be able engage them all at to institutionalize effective change management. once. Applying the military principle of force concentration, especially where its outcome is a Though EA is inherently a holistic approach to foregone conclusion, it is better to choose only the business of an organization, it is not enough battles you're sure to win (Tzu, n.d.). In large to rely on the overall performance measures of and complex undertakings like EA, entrenched an organization. These are certainly most pockets of resistance should be bypassed in important, but these measures are influenced by favor of small yet strategic objectives (Matloff, many factors more significant to organizational 1973). outcomes than EA. As a prime example, the number of commercial air carrier fatalities is a An organization is a group of individuals, and primary FAA performance metric, where a single culture is an aggregate pattern of individual catastrophic event would easily eclipse EA behaviors. As Mr. Kenney described in a success. Other examples are less extreme, but November 2005 briefing to FAA executives: all measurable outcomes at the strategic level in the FAA are influenced by multiple outputs '~n organization is a complex, adaptive (FAA, 2005). system that does not simply follow rules. People in organizations learn from Mr. Chew stresses the need to improve value to experience, and adapt their behavior to a the FAA's customers, and unit cost is possibly dynamic environment.... organizations the highest level metric that EA could can respond in unpredictable ways to predominantly affect. Though this metric has yet attempts to change their behavior." to be adequately developed for performance measurement purposes, its creation and use is It is therefore prudent, when strategizing the inevitable. human side of EA implementation, to understand both group dynamics and human EA can also benefit from performance metrics nature. Interestingly, Mr. Kenney also said in his that align with its intended outcomes. Direct 2005 briefing that measurements could be derived from external mandates, such as Office of Management and "EA itself must encourage changes in Budget (OMB) Circulars A-11 and A-130. One organizational behavior." So it is not sure, if not overly coarse, measurement would enough for people to change as a way of be how successful an agency is at staying within accommodating EA. For genuine its IT budget. Additionally, new agency EA success, people must accept EA as a way program grading criteria from both OMB and the U.S. Government Accountability Office (GAO)

© Journal of Enterprise Architecture - May 2006 31 provide as a revealing and useful set of EA more important than the bridge itself, because program measures. EA is useless if it isn't used - and it won't be used until people feel it's worth the trip. There are other approaches worth considering. If a more immediate goal of EA implementation There is a significant difference between the is to identify and engage communities of theoretical concept of EA and the practical interest, perhaps an index that conveys quality matter of its implementation. Though EA and quantity of cal participation would be promotes enterprise-wide thinking and planning, useful. Using a systems-thinking approach, it is obvious that EA implementation in large another measure could be to track the number complex enterprises cannot be accomplished in and strength of the bridges built between the all at once. A steady accumulation of small communities of interest through use of EA. successes can get an EA program going in the These would be closer measures of the elusive right direction, and nurturing EA communities of yet critical human side of EA implementation. interest provide bite-sized opportunities for making real progress. If EA is evolving, it is reasonable to assume that EA performance metrics are evolving as well. As Human nature and organizational dynamics EA implementation makes progress, the appear to be at the very heart of EA usefulness of EA products should rise as well. implementation. Both are inherently resistant to To measure implementation in an emerging EA change and uncertainty, but attracted to program, simple output measures may serve usefulness and manageability. Enterprise well as interim metrics, for example tracking architects must not only understand the instances where products from a central EA business needs of an organization, but must repository contributed to investment decisions. also become adept at finding and using the best Other initial measures of progress could include approaches to the human side of EA. how many existing solutions can be reused, or how many business functions can be evaluated Listening and learning are valuable activities in with EA simulation models. According to any organization, and these are perhaps the Venkatapathi Puvvada, Chief Technology Officer most important keys to success for the at Unisys Global Public Sector, when EA enterprise architect. These practices allow the produces a comprehensive map of an architect to understand what an organization organization, "You can show results by how fast needs, what solutions are available, and most you can find information." (Perera, 2005) importantly, who can provide the right solutions. The final and most critical part of this sequence lies with the persons seeking and offering CONCLUSIONS solutions, for they are the ones who must eagerly take ownership of EA. Without this Though EA is a legal mandate in the federal capstone, EA artifacts may be little more than sector, it is too important and complex to rely curious relics. only on a compliance-based approach to ensure successful implementation. There are many ways to measure success, but the first step is to AUTHOR BIOGRAPHY know what success looks like. In the case of EA, organizational transformation is the eventual Douglas Findlay is a senior policy analyst at the goal, but there are many options available to FAA Air Traffic Organization. He began his gauge success as implementation progresses. aviation career in the U.S. Marines as an avionics technician and later as a helicopter Enterprise architects must transcend the IT aircrewman. His career has been centered on realm to be successful. Though early results the National Airspace System since he joined from successful EA implementation may be the FAA in 1988. Since 1995, he has designed primarily in the realm of improvements to IT web applications for the Federal government as effectiveness and cost efficiency, to see real well as for non-profit organizations. Mr. Findlay progress in business transformation enterprise is currently a student at the Information architects must become bridge builders between Resources Management College of National the IT world and the business world. It could be Defense University. He lives in Falls Church, said that the people who travel the bridge are Virginia.

© Journal of Enterprise Architecture - May 2006 32 REFERENCES Matloff, M. (1973). American Military History Volume 2: 1902 - 1996. Retrieved December Boddie, S. (2005). Unpublished personal 22, 2005 from the HyperWar website: communication, March 25, 2005. http://www.ibiblio.org/hyperwar/AMH/AMH/AMH- 23.html. Best, J. (2006). Flavor of the Month. Berkeley: University of California Press. Retrieved McGregor, D. (1960). The Human Side of December 5, 2005 from the UC Press website: Enterprise, New York City: McGraw-HilI. http://www.ucpress.edu/books/pages/10506.html Perera, D. (2005, September 19). Hula Hoop, Rubik's Cube ... enterprise architecture? Federal Aviation Administration. (2004). Safety Retrieved December 13, 2005 from the Federal Management System Manual, Version 1.1. May Computer Week website: 21,2004. http://www.fcw.com/article90841-09-19-05-Print.

Federal Aviation Administration (2005). Flight Preston, E. (1998). FAA Historical Chronology. Plan 2005 - 2009. Retrieved November 28, FAA Office of Public Affairs Publication, August 2005 from the FAA website: 1998. http://www.faa.gov/aboutlmedialFlighCPlan_rev 020905.pdf. Shane, J. (2005). The ATO and Safety: Improving Our Safety Culture. Retrieved Koch, C. (2005). A New Blueprint for the December 12, 2005 from the International Civil Enterprise. Retrieved December 13, 2005 from Aviation Organization website: the CIO Magazine website: http://www.icao.intlicao/en/ro/nacc/meetings/200 http://www.cio.com/archive/030105/index.html. 5/ATM_Safety/session4usa.pdf.

Machiavelli, N. (1908). The Prince. (W. K Tzu S. (no date). The Art of War. Retrieved Marriot, Trans.). (Original work published 1515). December 23, 2005 from China the Beautiful Retrieved December 23, 2005 from the website: http://www.chinapage.com/sunzi Constitution Society website: e.html. http://www.constitution.org/mac/princeOO.htm.

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 Systems architects within the U.S. Department One goal of the enterprise architect is to develop of Defense (000) have a similar tool, known as and implement a complex system using a the 000 Architecture Framework, or DO OAF. methodical and repeatable approach. This This framework provides for 26 artifact types, includes documenting the system architecture representing different views and architectural from a variety of views which take into information. The DODAF is helpful in consideration strategic business goals, business methodically defining, planning, and rules, existing and legacy systems interfacing documenting the architecture of a complex with the system of interest, and the appropriate system. While there are differences, there are and applicable technologies. many parallels between the approaches suggested for enterprise architects and complex A number of frameworks exist to provide an system architects. For instance, while the organizing structure for the enterprise architect. enterprise architect is concerned with business One such framework is the Zachman goals and business scope, the systems architect Framework, providing 30 different artifact types is concerned with the business goals of the to assist the enterprise architect in capturing, customer (the entity paying for the complex planning and documenting the new architecture system being architected and developed) and 3 (Zachman, 1987). Another is the EA Cube the scope of the system. The two frameworks (Bernard,2004). provide for artifacts that model the system and

© Journal of Enterprise Architecture - May 2006 34 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 Figure 1. Mid 17'h Century Patterns Book techniques that could be useful to architects from both practices. The purpose of this paper is to describe the research being performed to In modern times, Christopher Alexander is investigate the application of patterns to the credited as being the first to understand the practice of systems architecting. Architectural value of patterns in the development of systems. patterns may have pragmatic utility for practicing Alexander studied architecture at Cambridge. enterprise architects as well. Though formally trained in mathematics and physics, his domain of interest was the design and construction of homes, buildings, and A SHORT HISTORY OF PATTERNS communities. Throughout the 60's and 70's, he developed patterns for use by other architects The notion of patterns is almost universal. The with the objective of improving the art of urban human mind seems to perceive patterns without design. He began to identify patterns for conscious thought. We notice an individual's architecture, urban designing, and planning by personal habits because they form patterns. looking at an architectural design and then Music employs repeating patterns to make it abstracting that design into its basic parts which easier to learn the tune. For example, three were common across other designs. childhood songs have the same tune - Twinkle, Twinkle Little Star, Baa, Baa Black Sheep and Thinking of this in the context of Zachman's The Alphabet Song - all derived from the same Framework, Alexander was the planner. From composition by Mozart. his perspective, communities became systems to be decomposed into component parts. He In seventeenth century England, they made use described the component parts and their of pattern books which contained rules of thumb relationship to other component parts in terms of to assist the general public in transacting boundaries. Alexander's first publication on this business. These pattern books represented the notion was Notes on the Synthesis of Form documented experience accumulated over the (Alexander, 1964). He further developed these first half of the 1600s in buying, selling, and concepts in A Pattern Language (Alexander, leasing buildings. Figure 1 represents one 1977). Alexander believed one could reuse a example from Henry Phillips's "The Purchaser's pattern "tens of thousands of times" and not Pattern" (Baer, 2003). have any two designs look the same. Nor did he did see the patterns as remaining stagnant. He For the purposes of discussion in this article, a believed patterns could always be improved working definition of a pattern is offered as upon. "We may then gradually improve these follows: A pattern is a model or facsimile of an patterns which we share, by testing them actual thing or action, which provides some against experience ... " (Alexander, 1979). degree of representation (an abstraction) to enable the recreation of that entity over and over The Alexandrian form of documenting patterns again. 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

© Journal of Enterprise Architecture - May 2006 35 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 Figure 2. House for a Couple solve the problem, and how it may be modified or adapted to accomplish the task. To The "House for a Small Family" pattern (Figure demonstrate the application of the pattern 3) context was: "In a house for a small family, it concept, Alexander outlined multiple patterns for is the relationship between children and adults a farmhouse, as follows (Alexander, 1977): which is most critical". The pattern was documented to address issues regarding • North South Axis • Two Floors children and their parents: small children like to be around their parents, most parents do not • West Facing • Hay Loft at the Entrance Back have a place large enough to have a dedicated nursery, and parents do not have the heart to • Bedrooms in Front • Pitched Roof keep the kids out of special areas. If these • Garden to the • Balcony Toward issues are not taken into consideration in the South the Garden design of a small house, the house soon has the • Half-Hipped End • Carved Ornaments character of a children's room - toys and clutter everywhere. 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 Figure 3. House for a Small Family. characterized as "In a small household shared by two, the most important problem which arises Why did Alexander commit a great deal of his is the possibility that each may have too little professional life identifying patterns, writing opportunity for solitude or privacy". 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).

© Journal of Enterprise Architecture - May 2006 36 This is an important concept - in fact, if one He goes on to provide his own definition of a were to take the previous sentence and replace pattern as "an idea that has been useful in one the word "house" with "system," the same practical context and will probably be useful in concept could apply to the notion of enterprise others." or system architecture patterns. A number of parallels can be drawn between the use of patterns in the software engineering PATTERNS IN INFORMATION TECHNOLOGY community and the development of ontologies by ontology engineers (Devedzic, 1999). The information technology (IT) domain is Ontologies provide skeletal knowledge and an beginning to embrace patterns. As an infrastructure for integrating knowledge bases at illustration, IBM® is using patterns in the e the knowledge level, independent of particular business domain. IBM® has found that many implementations. According to Devedzic, customers have the same requirements, and software patterns enable the communication of these requirements have been abstracted into knowledge in order to solve problems effectively. patterns. Their recipe steps for creating an Software patterns are effective in transferring effective, run-time architecture are (Sachdeva, knowledge by describing solutions to similar 2004): problems through common ways and techniques, regardless of the project problem Step 1: Develop a high-level business domains or implementation tools and languages. description And, using software patterns early in the design Step 2: Develop a Solution Overview Diagram reduces the number of changes that have to be Step 3: Identify Business Patterns made later in the lifecycle. He considers some software patterns to be "micro-architectures" that Step Identify Integration Patterns 4: contribute to the overall software system Step 5: Identify Composite Patterns architecture. That assertion is made because Step 6: Identify Application Patterns software patterns are used to weave parts of the Step 7: Integrate a package into a solution overall software system architecture into a whole. There are others in the software Step 8: Identify Run-time Patterns engineering community that agree with this Step 9: Identify Run-Time and Product belief - using multiple patterns, similar in nature mappings to a pattern language, to create an entire software architecture. This concept was first presented in "Patterns Generate Architecture" PATTERNS IN SOFTWARE DEVELOPMENT (Beck, 1994) (Hanmer, 2004).

In the late eighties, software designers began to apply architectural concepts (patterns) to object DOCUMENTING SOFTWARE PATTERNS oriented software development. The first book on the subject of software patterns was Software patterns have been documented in a published in 1995 by Gamma, Helm, Johnson, variety of ways, and there is no consensus in and Vlissides (Gamma, 1995). It detailed 23 this regard. Again, according to Fowler: patterns, categorized as creational, structural, or behavioral patterns. All of these patterns are still 'When people write patterns, they typically in use today by programmers. write them in some standardized format-as befits a reference. However, there's no Learning to define and document a pattern is not agreement as to what sections are needed an easy task. Martin Fowler discusses the because evety author has his or her own difficulty in defining a pattern (Fowler, 1997): ideas ... (Fowler, 2003)

"... we have had difficulty in defining the term A number of pattern documentation approaches pattern. We all think we can recognize a have been developed by software engineers. pattern when we see it, we think most of us Based on a literature search, Table 1 represents would agree in most cases, but we cannot a survey of some of the most common pattern come up with a single definition." documenting conventions in use today, most of which come from the software domain.

© Journal of Enterprise Architecture - May 2006 37 Patterns for U.S Treasury Pattern Architecture A Pattern Language Ellectlve Use Archltecture Template Patterns for Pattern Writing Cases GUidance (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 The diagram in Figure 4 on the next page reflects the interactions with the customer, the An experienced architect begins to notice that it shop processes, and the data stores. In fact, is not unusual, as one abstracts a systems the individual that developed this example really behavior or capabilities; it begins to look like created a hybrid Use Case/DFD. It is the first other systems. That is certainly the case when level of decomposition of "Customer wants to one looks at transaction-based systems. The buy a book". The numbered circles represent following example was originally developed to the processes while the items that have discuss requirement patterns and requirement horizontal bars above and below the titles management, but it can also be used to represent some form of data storage - whether demonstrate the application of architecture it is a customer database, a book inventory, or a patterns to a sales transaction based system collection of sales transactions. Finally, each (Kaffenberger, 2004). Let's look at an example arrow represents the flow of information. From of the application of a pattern to an information this diagram, it is easy to trace the path from a system. customer ordering a book, checking the customer's credit, approving the order, checking This example begins with developing a DFD the book availability, placing the order, and (Data Flow Diagram) for the first level of collecting the money for the book; as well as the decomposition for a small bookstore in England. paths for a number of other interactions.

© Journal of Enterprise Architecture - May 2006 38 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 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, Figure 4. Book Purchase Diagram testability, and system maintenance.

To demonstrate the application of this pattern to a new domain, an architect could make changes CAPTURING IMPLICIT KNOWLEDGE WITH to the nouns in the customer purchase pattern PATTERNS (Figure 5) to make it useful in a specific domain - whether it is the purchase of an automobile, a Within industry and government, a growing service, or even to register for college course. number of practicing architects have acquired For example, minor modifications are necessary considerable architecture expertise via formal or for this pattern to suggest an initial high level informal mentoring, and work experience in the architecture for a class registration service. work environment. This corporate systems knowledge is captured in explicit ways through mediums such as handbooks, lessons learned Change this noun To this noun repositories, templates and tools, methods and Customer Student practices, and metrics and measures. A significant component of this corporate Product Class knowledge, however, is implicit and Order ReQistration undocumented, and largely represented through Discount Scholarship 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

© Journal of Enterprise Architecture - May 2006 39 may become a bottleneck in applying systems presentations at research and professional experience on current or future projects (Hole, conferences, and publication in research 2005). Patterns offer a formal method of journals. This standardization fosters reuse of documentation to capture aspects of such designs and even code that might be generated knowledge. If a pattern exists only in the form of from the architecture patterns. Such reuse can implicit knowledge, it is not accessible by others improve development efficiency and productivity and cannot be used by others without some (Coplien, 1997). Based on Coplien's study, one form of repeated storytelling to convey the could argue that documenting current patterns pattern to others by the holder of this may reduce the documentation costs and knowledge. complexity for any organization that elects to pursue systems engineering patterns. Finally, While a pattern is reusable by the person who architectural patterns may help control the first recognizes it, the real power and value of a complexity of architectures by standardizing on pattern is derived only if it can be packaged for well known and practiced patterns. use by others. Though a pattern can be transferred through verbal communications, such as storytelling, it is more accurately and ARCHITECTURE PATTERN RESEARCH reliably transferred through more formal forms of documentation. At this point, we have established that there are many technical disciplines using patterns to manage complexity and reduce risk. Research POTENTIAL BENEFITS OF ARCHITECTURE into the applicability and use of patterns has PATTERNS been underway within the systems architecting and engineering community (Cloutier, 2005; Numerous benefits will result from this growing 2005b). interest in architecture patterns. One significant derived benefit of patterns, based on Once that research established there may be precedence in other disciplines, should be potential benefits supporting the use of patterns improved communications between the various at this level, the next question to be asked was stakeholders. Improved team communications "does the systems architect need a different between members of the architecture team and solution for documenting patterns?" This topic the design teams was the result of using was discussed during a colloquia conducted at patterns while developing open source software Stevens Institute of Technology in 2005 (Hashler, 2004). (Cloutier, 2005a). Two issues arose from that session that indicated that a unique systems Another benefit identified from the same study architecture approach is necessary. The first was that patterns facilitated application of sound issue is abstraction. The architecture of a architectural concepts and implementations. As system (whether it is an enterprise system within the discipline of architecting assumes the a business or a complex system to be marketed) challenge of developing increasingly complex requires a higher level of abstraction than that systems, there is a need for a common lexicon found in the software that may be a part of the between systems architects. Describing system. Additionally, many systems include a architectures in the context of known and combination of hardware, software and other understood patterns should foster better and resources which may result in pattern more consistent understanding across the many uniqueness. This abstraction may make it more stakeholder communities. Systems architecture difficult to use a simple approach to patterns may also enable implementation of documenting patterns. The second issue that common design features across systems (reuse) arose is related to the first - patterns need to leading to enhanced R&D efficiency, and lower address interfaces to non-software parts (if they ownership costs through reduced efforts with exist) in the pattern description. This notion of regard to system testing, integration, and interfaces has not been explicitly addressed in maintenance. past software pattern discussions.

In communities that have adopted the use of A survey was conducted in late 2005 to help patterns, the patterns often become identify requirements for a methodology for standardized through multiple implementations, documenting architecture patterns. The survey

© Journal of Enterprise Architecture - May 2006 40 was provided to over 70 individuals that either The industries represented by the respondents has experience using explicit patterns (e.g. are shown in Table 4. The largest industry software patterns), indicated they use implicit represented is the aerospace industry. This is patterns in their work, or has done serious not surprising with aerospace representing research and thought on the use of patterns for large, complex systems engineering challenges. systems engineering/systems architecting. The There are also ten other industries represented researcher received 28 useful responses, and a in this data. couple of responses where there was a significant amount of narrative and input Field Totals provided, but the provided data was not Aerospace/Defense 12 consistent with the survey data, and therefore Automotive 1 was not used in this analysis. Commercial IT 1 ConsultinglTool Vendor 2 SURVEY RESPONSES Education 1 Government 2 The demographics of the responses show a Healthcare 1 number of notable aspects. First, the responses High Tech came from around the world. Eight countries Semi/Materials/Nano) 3 are represented in this data as shown Table 2. Mechotronics 1 c:::- Countries Totals Software 1 Australia 1 Telcom 3 Finland 2 TOTAL 28 Germany 1 Table 4. Industries Represented by Survey Holland 5 Norway 1 Sweden 1 Those responding to the survey comprised a very experienced group. While the level of UK 1 experience ran from 2 years to 48 years, the USA 16 cumulative years experience represented by the TOTAL 28 group totals 569 years. Of the 28 responses received, 22 had more than 15 years Table 2. Survey Response Distribution professional experience, and 18 of the responses had more than 20 years of The self-described roles of the respondents are professional experience. Table 5 provides a shown in Table 3 Some responses profile of the respondents experience levels. 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 Table 5. Respondents Experience Profile

© Journal of Enterprise Architecture - May 2006 41 DOCUMENTING ARCHITECTURE PATTERNS decomposition). Object decomposition is documented using the Unified Modeling The data demonstrated that systems engineers Language (UML). UML is actually methodology and architects are most interested in the agnostic, but it almost always used with an rationale for the pattern followed by an example object oriented methodology. The survey asked of how to apply the pattern, and known uses of about what UML diagrams would be most useful the pattern. The researcher broke the data into in documenting patterns and the result is shown three distribution groupings to determine the in Table 7. highest rated sections. The distribution provided for better visibility, facilitating a more clear Most Valuable Functional Totals understanding of which sections were deemed I Decomposition Diagrams the most important, while also being able to FFBD 16 identify which sections are deemed necessary to Block diagram the majority of respondents though not 11 necessarily having the same degree of DFD 9 importance. N2 diagram 6 IDEFO 5 There are several sections that seem to appear E-R diagram 4 on all pattern documentation approaches. Since other - FFDB wi Data Flow 1 these sections were pervasive and logical, and other - Conops 1 they existed in all pattern templates found by the researcher, they were provided in the survey as Table 6 - Functional Diagrams for Patterns a necessary given. Those sections are: pattern name, context of the problem, problem description, pattern solution. Most .aluable UML Diagrams Totals Use cases 15 Based on the analysis of the survey data, the Sequence diagram results indicate that other sections necessary to 13 document architecture patterns include: Class diagrams 12 Activny diagram 12 • Aliases • Forces • Interfaces Collaboration diagram 6 • Resulting • Related • Date Composite structure 5 context patterns Documented Object diagram 4 • Known • Sketch • Author(s) Parametric diagram 3 uses other - state diagram 3 • Email • Rationale • References Constraints diagram 2 • Keywords • Example other - Component diagram 1 lother - Deployment diagram 1 Another topic addressed by the researcher in lother Block diagram 1 the survey was to determine what form of graphic representation should be used in other - Domain Model 0 documenting patterns. Within the surveyed community, the two most common graphical Table 7 - UML Diagrams for Patterns notations are related with the two decomposition approaches (or methodologies) - functional Based on this data, it appears the most useful decomposition and object decomposition. The graphical diagrams for use in documenting following table represents the diagrams normally architecture patterns are FFBD, Block Diagram, associated with the functional decomposition DFD, N2 and IDEFO for the functional methodology, and the total number of survey decomposition. For the object decomposition responses that believed patterns should approach, the most useful UML diagrams may graphically represented with these types of be Use Cases, Sequence Diagrams, Class diagrams (Table 6). Diagrams, Activity Diagrams, Collaboration Diagrams and Composite Structure Diagrams. The second methodology originated in the software community and is referred to as object decomposition (sometimes referred to as logical

© Journal of Enterprise Architecture - May 2006 42 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 As in this case, the pattern documentation may plan, detects, control and act. Though this include a model from a modeling tool such as pattern is normally associated with designing Vitech Corporation's Core (used to generate systems for the military, it is easily applied to the these diagrams) or a UML modeling tool. The design of a police or fire organization for large inclusion of a model file certainly will help "jump cities like Los Angeles or New York. It could also start" the new architecture. Table 8 lists the be applied to a command and control system for process elements for performing C2.

Pattern Name: Perform C2, Perform Command and Control Aliases: None known Keywords: Command and control, Plan, Detect, Control, Act, C2. Does not address "Prepare" precondition (though one might argue that prepare Problem Context: and plan go together) nor "Assess" post condition In command and control (C2), the situation is typically managed in identifiable Problem phases. And, the situation may move back and forth between the stages. Those Description: stages are Plan/DetectlControl/Act Terminology may vary from one domain to the next, and should be adapted in Forces: the application of the pattern This pattern provides the basis for developing the command and control (C2) Pattern Solution: interfaces and information that moves through the stages of C2. It provides the AO Context and the first level of decomposition using IDEFO. Model: 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 Interfaces: form of reports. Names of information can be modified as required by specific domain application. Resulting Further work is required to define the tasks to be performed within each stage, Context: 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 Example: 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. Known Uses: Command and Control applications Related patterns: OODA (Observe, Orient, Decide, Act) References: MCDP 6 Marine Corps Command and Control Handbook Pattern This is a time tested doctrine used by the military, that may be applicable to Rationale: other domains Author(s): Harry Johnson Ph.D., Ken Hartnett, Satya Moorthy, Robert Cloutier, 2006.

Table 8. Pattern Description: Perform C2

Assessment (BOA) 0~------E~~~ Coordination Data Mission Assessment 1 Mission Status External Data ---~ ~~~f OrdersMission Support Requests Plans Raw Intel Perform C2 (Pattern) t Reports f-----. Req for Information Environmental Data ---~ ~~~f SensorResource Data Assignments Situational Data TaskinfL t Tracks/Targets of Interest

Resources

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 device on a car or trUCk). Examples of external Figure 6, the architect documenting the pattern data may be intelligence, or a tip from an identifies the inputs and outputs (left to right). informer which will have some impact on the The resources are drawn from the bottom. In operation. 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

Reports environmental Data ~~~c====t~"~'""'""~"~.-'~=E======3=E3======i=Ei=~~ Req for Information Ext,m,' "''' ---+---->i d""", Raw Int. l-H Plan ii i-I To,"" Orders (Operations) i~~~~~~~~33EE~~~~EEE~iE 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~ (0,,,,",,,,,eo,.ol ,:~,~,~ '","'_".~" D~'''ff==t+ Coo"""',, "''' &Identificatlon) t'~S"~'~h~""~ ""~tl-ll iI iii ~ H Mission Support Requests

Act (ExeaJte/ f----. MIssion Status Prore

Resources

Figure 7. Detailed Pattern Description: Peliorm C2

There is a lot of data shown in the more detailed of each of these functions into lower level level IDEF-O Model illustrated in Figure 7, Each functions, the authors experience has shown box represents a decomposition of the peliorm that the detail begins to become too detailed, C2 top level function, Outputs are taken from and less able to be abstracted. one function and become inputs to another function.

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

© Journal of Enterprise Architecture - May 2006 45 A PROPOSED PATTERN HIERARCHY Extending this hierarchy, Figure 9 on the next page shows the five types of system architecture Patterns can be applied at different levels of an patterns identified in this research (Cloutier, architecture or system based on the 2005). It also provides a necessary bridge to appropriateness of the pattern and the existing show the relationship between patterns that the maturation of the system being developed. For Business process groups have been identifying instance, within the software community, there for years and the software patterns we have are system patterns (sometimes referred to as already discussed. In this proposed taxonomy, architecture patterns by the software folks), system architecture patterns are broken into: design patterns and idioms. Figure 8 represents a pattern hierarchy proposed by van Zyl and 1. Structural patterns Walker for software systems (van Zyl, 2004). 2. System Requirements patterns 3. Systems Engineering Activities patterns v..mZy! Pattern Hierarchy package MisctM..Orav.tngs {212} 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 SysterMrchitecturePallems 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 Figure 8. van Zyl Pattern Hierarchy how the architecting role is performed.

It is important to recognize that in their work, when they refer to the system, they are referring WHEN TO NOT USE to the software system. Their work may be ARCHITECTURE PATTERNS extendable to the broader system, or system of systems architecture. System level patterns The discussion thus far has focused on the may be applicable when representing the positive aspects of documenting and using highest levels of a system to represent an entire patterns and the potential advantages of system or a part of a system. They may also applying them within the system architecting include structure and system boundaries. discipline. For completeness, this discussion Based on precedence from other disciplines, should also present the likely pitfalls associated use of patterns in systems engineering and with the application of patterns. architecting may provide the foundation for a more common lexicon leading to improved The first argument against the use of patterns communications between the various relates to the notion of implicit structural stakeholders, while also enhancing the R&D constraints inherent in the use of patterns - efficiency on complex development programs. particularly with highly independent and creative For instance, the Publisher-Subscriber pattern, individuals, and the related impact on the Layers pattern and the Client-Server pattern innovation. This concern is valid and must be were all first published as software patterns balanced - the intent is to leverage and reuse (Buschmann, 1996). Now, most enterprise existing solutions (albeit, abstract) when architects understand those patterns, and use applicable, and to allow the necessary degrees them to describe systems - a common lexicon. of freedom to explore new and unique implementations when required and desired to The pattern hierarchy proposed by van Zyl ensure an atmosphere that encourages (2001) can be extended for broader application creativity. The second argument may be and increased relevance to larger systems. described as "so what?"

Organization Patterns BusinessPatterns MissionPatterns .

SystemArchPatterns , , .-----. , , , , ,, , , , , ,, Structural ,, , , ; \ SystemProcess ==;- ? SysEngRoles ! I ;ELti~~1 ~"

SystemRqmnt

SystemAnalysisPatterns SystemDesignPatterns SystemTestPatterns --- ~--->

SW _Arch Patterns SW _Analysis Patterns HWDesignPatterns OperationaLPatterns "'~~-~- , ~-~--~k-- " SW _RqmntPatterns HW _RqmntPatterns , ------" -----~ SW _Design Patterns SW _ TestPatterns , , , , , , ~ .---. r--l . CreationalPatterns StructuralPatterns BehavoiralPatterns

Figure 9. A Proposed System Pattern Hierarchy.

Sometimes, when an expert architect looks at - particularly in regard to the documentation patterns, the reaction is - "so what, I knew and validation of patterns by these experts for that". The fact of the matter is that within their use by others. Organizational motivation domain of expertise, patterns are of little use to usually becomes necessary. From the experts. This attitude results in lack of inertia perspective of preserving, sustaining, and when it comes to adopting the use of patterns evolving corporate knowledge, patterns are a

© Journal of Enterprise Architecture - May 2006 47 powerful medium for capturing aspects of begin architecting a solution to a system with implicit knowledge in a form that is pragmatic. similar requirements. However, as the architect documenting the pattern "drills down" while There are situations when it is inadvisable to documenting a complex pattern, a level of use architecture patterns. These include: detail is reached whereupon the necessary detail begins to obfuscate the value of pattern • New or unique requirements abstraction. This is the point in which no (unprecedented systems) preclude the further data should be added to the pattern An existence of a pattern additional benefit to patterns at this level is the • Unique solution (unprecedented concepts) speed of knowledge transfer to train new • When the pace of technological change systems engineers faster than working on does not warrant the use of patterns multiple programs over several years. Patterns are one way to help minimize the possibility For designs that are proven and effective, and that details will not "fall through the cracks". addressing problems common across multiple systems and domains, there should be a Continued research should be done on strong motivation to leverage the benefits that architecture patterns. It would be interesting to can accrue from the application of patterns. see if agent based modeling of the use of patterns may help in the quantification of the value of patterns in the architecting process. SUMMARY AND CONCLUSIONS

Patterns are models, or abstractions of reality. Today's systems have become extremely AUTHOR BIOGRAPHIES complex. It is difficult, if not impossible, for a systems engineer to mentally juggle all the Rob Cloutier details of a modern complex system. As already demonstrated, patterns can exist at Rob works for Lockheed-Martin Corporation in multiple levels. During the course of systems Moorestown, NJ where he is a Principle architecture, design and implementation, a Systems Engineer in the System of Systems project team may use systems architecture Architecture organization. He is responsible for patterns, process patterns, design patterns, developing architecture for complex systems. implementation patterns (for software code), Rob is a Systems Engineering Doctoral machine patterns (to cut metal for cabinets), Candidate and occasional guest lecturer at test patterns, and validation patterns. At each Stevens Institute of Technology in New Jersey. level of the architecture, the pattern should He is also developing an Object Oriented contain the appropriate level of detail for the Architecture and Design course for Stevens stage in which it is applied. However, patterns Institute. Rob holds a BS from the United are not silver bullets. But they can be a States Naval Academy and an MBA from powerful tool in the architect's toolbox. They Eastern University where he is an adjunct help solve difficult problems by leveraging professor. He has over 20 years experience in existing knowledge, if this existing knowledge systems engineering, software engineering, is documented in a manner that facilitates this and project management in both commercial process. and defense industries.

In communities that use patterns, the patterns Dinesh Verma often become standardized through use in Dinesh received his PhD and the MS in designs and technical discussion, Industrial and Systems Engineering from presentations at research and professional Virginia Tech. He is currently serving as the conferences, and publication in research Associate Dean for Outreach and Executive journals. This standardization has fostered Education, and Professor in Systems reuse of architectures, designs and even code. Engineering at Stevens Institute of Technology. He concurrently serves as the As was shown in the C2 pattern, sufficient Scientific Advisory to the Director of the detail can be captured in the pattern to enable Embedded Systems Institute in Eindhoven, an architect less familiar with the process to Holland. Prior to this role, he served as

© Journal of Enterprise Architecture - May 2006 48 Technical Director at Lockheed Martin Alexander, Christopher. (1964). Notes on the Undersea Systems, in Manassas, Virginia, in Synthesis of Form. Cambridge: Harvard the area of adapted systems and supportability University Press. engineering processes, methods and tools for complex system development and integration. Alexander, C. (1977). A Pattern Language. New York: Oxford University Press. Before joining Lockheed Martin, Verma worked as a Research Scientist at Virginia Tech and Alexander, Christopher. (1979). A Timeless managed the University's Systems Way of Building. New Your: Oxford University Engineering Design Laboratory. While at Press. Virginia Tech and aiterwards, Verma continues to serve numerous companies in a consulting Baer, W. (2003). How 'Pattern Books' Fueled capacity, to include Eastman Kodak, Lockheed England's First Speculative Real Estate Martin Corporation, L3 Communications, Market. Harvard Business School Working United Defense, Raytheon, IBM Corporation, Knowledge eZine, 2003. Retrieved May 7, Sun Microsystems, SAIC, VOLVO Car 2004 from Corporation (Sweden), NOKIA (Finland), http://hbsworkingknowledge.hbs.edu/tools/print RAMSE (Finland), TU Delft (Holland), Johnson _item.jhtml?id=3313&t=finance Controls, Ericsson-SAAB Avionics (Sweden), and Motorola. He served as an Invited Beck, K., Johnson, R. (1994). "Patterns Lecturer from 1995 through 2000 at the Generate Architectures". Proceedings Object University of Exeter, United Kingdom. His Oriented Programming 8th European professional and research activities emphasize Conference, ECOOP '94 (Bologna, Italy, 1994) systems engineering and design with a focus Springer-Verlag, pp. 139-149. on conceptual design evaluation, preliminary design and system architecture, design Bernard, S. (2005). An Introduction to decision-making, life cycle costing, and Enterprise Architecture (2 nd Edition). supportability engineering. In addition to his AuthorHouse. Bloomington, IN. publications, Verma has received one patent and has two pending in the areas of life-cycle Buschmann, F., R. Meunier, H. Rohnert, P. costing and fuzzy logic techniques for Sommerlad, and M. Stal. (1996). Pattern evaluating design concepts. Dr. Verma has Oriented Software Architecture: A System of authored over 85 technical papers, book Patterns. West Sussex, England: John Wiley & reviews, technical monographs, and co Sons Ltd. authored two textbooks: Maintainability: A Key to Effective Serviceability and Maintenance Cloutier, R. (2005). Application of Patterns to Management (Wiley, 1995), and Economic Systems Architecting. Proceedings and Decision Analysis (Prentice Hall, 1998). He is Presentation, 2005 Telelogic Americas User a Fellow of the International Council on Group Conference, October 2005. Systems Engineering (INCOSE), a senior member of SOLE, and was elected to Sigma Cloutier, R. (2005a). Survey on the Use of Xi, the honorary research society of America. Patterns in Systems Engineering and Architecting Research Colloquium. CSER 2005. March 23, 2005.

REFERENCES Cloutier, R. (2005b) Towards the Application of Patterns to Systems Engineering". CSER Adolph, S. Bramble, P. (2003). Patterns for 2005. March 23-25, 2005. Effective Use Cases. Boston: Addison Wesley. Coplien, J. (1997). Idioms and Patterns as Architectural Literature". IEEE Software. Ambler, S. (2004). The Process Patterns Special Issue on Objects, Patterns, and Resource Page. Retrieved October 28, 2004 Architectures. January 1997. from http://www.ambysoit.com/processPatternsPag e.html

© Journal of Enterprise Architecture - May 2006 49 Devedzic, V. (1999) "Ontologies: borrowing Rising, L. (2003). Pattern Template. AG from software patterns". Intelligence, Vol. 1 0, Communications Systems (A subsidiary of number 3, pages 14-24. ACM Press, 1999. Lucent Technologies). Retrieved May 28, 2004 Available at: from http://doi.acm.org/10.1145/318964.318968 http://www.agcs.com/supportv2/techpapers/pat terns/template.htm Fowler, M. (2003) "Patterns". IEEE Software. March/Aprii 2003. Sachdeva, N. and Godlszmidt, G. (2004). "On demand business process life cycle, Part 2: Gamma, E., Helm, R., Johnson, J., Vlissides, Patterns for e-business recipe". IBM J., (1995). Design Patterns: Elements of Developerworks Website. 24 Nov 2004. Reusable Object Oriented Software. MA: Retrieved June 5, 2005 from Addison-Wesley. http://www- 106.ibm.com/developerworks/library/ws Hahsler, Michael. (2004). FreelOpen Source odbp21 Software Development. Edited by Koch Stefan. Idea Group Publishing. Pages 103- TOGAF. (2002). "Architecture Patterns". The 124. Open Group Architecture Framework (TOGAF) Website. Retrieved May 27,2004 from Hanmer, R. and K. Kocan (2004). http://www.opengroup.org/architecture/togaf8- "Documenting Architectures with Patterns" Bell doc/arch/p4/patterns/patterns.htm Labs Technical Journal 9(1), 143-163, Wiley Periodicals, Inc., 2004. van Zyl, J. and A. Walker (2004). "A Pattern Architecture: Using Patterns to Define Overall Hole, Eirik. (2005) "Architectures as a Systems Architecture". Retrieved October 22, Framework for Effective and Efficient Product 2004 from Development in a Dynamic Business http://osprey.unisa.ac.za/saicsit2001/Electronic Environment". Proceedings of the 2005 Ipaper37.pdf Conference on Systems Engineering Research, March 2005. Zachman, J. (1987). A Framework for Information Systems Architecture. IBM Kaffenberger, R. (2004). "The Difference - On Systems Journal. Vol. 26, No.3, pp. 276-290. 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

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 Business Reference Model's "Service to Citizens" sub-functions. This complex set of To briefly recap the introductory information, business responsibilities leads to an equally from Part I of this article, on the Department of complex set of stakeholders and customers with the Interior (DOl), the DOl is a cabinet-level vested political, environmental or economic federal agency with a very broad mission. It is interests. In addition, many of the DOl's mission made up of the Office of the Secretary, eight and business functions are continuously independent bureaus and a National Business monitored by special interest groups. Center. The DOl is a highly distributed organization headquartered in Washington DC The next section of this case study reveals how with over 2,400 operating locations throughout these five "major changes" Establishing a the United States and its territories. It is the Federated EA program, Establishment and steward of 504 million acres of federal land, or Population of the DOl Enterprise Architecture roughly one-fifth of the land in the United States. Repository (DEAR), Introduction of Governance DOl has a wide range of responsibilities and for DOl Information Technology, Enterprise highly diverse services including generation of Architecture, and Investment Decision Making, hydro-electric power, oversight of mineral Aggressive Creation of the First Blueprints in resource extraction, education and trust Order to Demonstrate the Business Value of EA, responsibilities for American Indians and Alaska and Development of the Methodology for Natives, National Parks oversight, wildland fire Business Transformation have helped bring management, and law enforcement. DOl EA to maturity, as well as a synopsis of each major change in the form of a "Lessons Today, the DOl performs approximately sixty of Learned" table at the end of each "major the Federal Enterprise Architecture (FEA)

© Journal of Enterprise Architecture - May 2006 51 change" discussion. In the last section, the organizations such as 001, this consideration future of the 001 EA program is discussed. leads to the realization that there is a real need for a federated architecture program rather than a simple collection of organizationally based 001 EA - MAJOR CHANGES architecture programs.

The identification and application of the four key 001 is one of the most diverse Federal fundamentals: (1) EA is about business Agencies, delivering services in twelve (over transformation to improve performance; (2) EA 60%) of the Federal Business Reference Model is a service to the business; (3) Chief Architects Services to the Citizen lines of business. are change agents; (4) EA is about Communication Communication Figure 1 below shows these twelve lines of Communication. As was discussed in Part I of business with an overlay showing the number of this case study, to achieve true EA success, it 001 Bureaus that deliver services to the citizens was necessary to combine these fundamentals in each area. This not only shows the complexity with the five Major Changes based on the and breadth of DOl's mission but highlights the concept of continuous improvement employed potential for multi-Bureau and cross-cutting within an EA. Theses changes are presented solutions that support the same business area. below. For instance, a study of the "Law Enforcement" service area within 001 resulted in the Major Change #1: The Establishment of a identification of multiple existing incident Federated Enterprise Architecture Program management systems across the Bureaus. This An EA is frequently difficult to define: Is it a recognition led to a recommendation to retire single architecture, or a federation of perhaps these systems and replace them with a single semi-autonomous architectures? Should it be incident management system that could be used built across functional lines, or oriented to the by all Bureaus. lines of business? Many organizations wrestle with this question of how to bound and organize their enterprise. In diverse, complex

Water Resource

ConseN arine and Lan a ement "'''''8Recreali esource Management and Tourism

Disaster Monitoring and Prediction DisaSaredness g ,,' EnVirOnB"1tOrin Disas Irand and For sli Restore Environ mediation Pollution lion and Control Education

Housing Assistance Energy Elementary, Secondary and FoogutriliOn Business/Industry Energy Re;:oMgmt. vocatl~nucalion Finan S r Oversight Energy Sup Cullu isloric "'"So O"'BOIntell party Energy Prese Campa tion Prolee Conserva redness Indus! r Income Energy Produc Cultural an Isloric Stabilization Exhibition

Figure 1. Department of Interior - Lines of Business

Prior to Fiscal Year 2004, 001 and the slowly in order to minimize confusion and Bureaus had achieved some architecture potentially adverse impacts to ongoing alignment, but many areas existed where a business processes. Accordingly, lEA and planned architecture did not exist at the the Bureau programs adopted an Bureau level, or the architecture approaches incremental approach to EA development, and capabilities were not aligned with the working through the 001 lines of business rest of the Agency. In order to prevent the and creating Modernization Blueprints for emergence of further uncoordinated each business segment within the architecture programs, the 001 specified enterprise. The standardized data, policies policies and methods designed to produce a and methods mentioned above became a unified, federated architecture that factor in the completion of these business incorporates all Bureau architectures. As a transformation initiatives. To this date, four result, many elements of EA development Modernization Blueprint initiatives have have become standardized across the been completed using this method and five Bureaus. All Bureaus use the same new business transformation initiatives are Methodology for Business Transformation underway. (see Major Change #5) to develop and implement their Modernization Blueprints. All Many of the new Modernization Blueprints Bureaus share the same toolset and being worked by the lEA and Bureau EA metamodel for storing architecture-related teams are inter-Bureau in scope and results. information. All Bureaus participate in inter These Modernization Blueprints will provide Bureau governance teams that make 001 with a roadmap for increasing business business, data, technology, and investment and technology performance within the decisions. The result has been the enterprise. The common approaches and development of a federated architecture for techniques for architecture planning will 001. continue to result in inter-Bureau recommendations for business Currently, each Bureau Architecture Team transformation and the continuous tightening builds and maintains its inventories of of inter-Bureau relationships within 001. architecture information. Since the Bureaus all share the same toolset and metamodel, it The following table lists the most important is easy to synchronize data collection lessons learned in establishing a federated activities across the 001 enterprise. This is EA program: done by the Interior Architecture Working Group (IAWG), which is responsible for the consistency and quality of the 001 master are data model. The result of these IAWG enough in needs that activities has been a consistent suite of architecture programs don't have to be information available to all Bureau re-thought for each organization: Each architects. Since a standard metamodel is bureau has a different mission, yet the used and the data model is synchronized components (e.g., methodologies, across the organization, each Bureau can frameworks, tools, standards, etc.) that use the same data collection templates, data comprise an architecture program have quality reports, and data validation been successfully reused and federated techniques. This information is maintained into a architecture. within Bureau-specific repositories that are Lesson #2: should be integrated nightly into a DOl-wide repository. All repositories are centrally managed, integrated horizontally and vertically. Each 001 Bureau has extremely different maintained and updated, reducing the total mission and business environments; yet, cost of ownership while creating a standard each has been able to federate into the data view across the Bureaus, the Agency, I lEA. and the inter-organizational Lines of Business.

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

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 I 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

I • Case studies are featured throughout the conference - learn what does and doesn't work I ) • Plenty of opportunity to network with other delegates and trade stories with them I In 2005 organisations including American Express, BA, Barclays, BBC, BP, British Council, DaimlerChrysler, Fujitsu, .l 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/ I

\ ( i )