A Comparison of the Top Four Enterprise-Architecture Methodologies

Summary: Twenty years ago, a new field was born that soon came to be known as enterprise architecture. This paper covers a broad introduction to the field of enterprise architecture. Although the history of the field goes back 20 years, the field is still evolvingand rapidly so. ( ! printed pages" Contents #$ecutive %ummary &ntroduction A 'rief (istory of #nterprise Architecture )ase %tudy The *achman +ramework for #nterprise Architectures The ,pen -roup Architecture +ramework (T,-A+" +ederal #nterprise Architecture (+#A" -artner )omparison )onclusion -lossary .eferences

Executive Summary
Twenty years ago, a new field was born that soon came to be known as enterprise architecture. The field initially began to address two problems/

System complexity,rgani0ations were spending more and more money building &T systems1 and Poor usiness alignment,rgani0ations were finding it more and more difficult to keep those increasingly e$pensive &T systems aligned with business need.

The bottom line/ more cost, less value. These problems, first recogni0ed 20 years ago, have today reached a crisis point. The cost and comple$ity of &T systems have e$ponentially increased, while the chances of deriving real value from those systems have dramatically decreased. Today2s bottom line/ even more cost, even less value. 3arge organi0ations can no longer afford to ignore these problems. The field of enterprise architecture that 20 years ago seemed 4uaintly 4ui$otic today seems powerfully prophetic. 5any enterprise6architectural methodologies have come and gone in the last 20 years. At this point, perhaps 70 percent of the field use one of these four methodologies/

The *achman +ramework for #nterprise ArchitecturesAlthough self6 described as a framework, is actually more accurately defined as a taxonomy The ,pen -roup Architectural +ramework (T,-A+"Although called a framework, is actually more accurately defined as a process The +ederal #nterprise Architecture)an be viewed as either an implemented enterprise architecture or a proscriptive methodology for creating an enterprise architecture The -artner 5ethodology)an be best described as an enterprise architectural practice

This white paper discusses these four approaches to enterprise architecture. &t does so within the conte$t of a fictional company that is facing some very nonfictional operations problems. These problems include/

&T systems that have become unmanageably comple$ and increasingly costly to maintain. &T systems that are hindering the organi0ation2s ability to respond to current, and future, market conditions in a timely and cost6effective manner. 5ission6critical information that is consistently out6of6date and9or :ust plain wrong. A culture of distrust between the business and technology sides of the organi0ation.

(ow should this company choose from among these four very different approaches to enterprise architecture; This white paper traces the :ourney the company is likely to face in using any one of these methodologies. <hen e$amining each of these methodologies in depth, one is struck by the fact that none of these approaches is really complete. #ach has strengths in some areas and weaknesses in others. +or many enterprises, none of these methodologies will therefore be a complete solution. +or such organi0ations, this white paper proposes another approach, one that might be called a blended methodology. )hoose bits and pieces from each of these methodologies, and modify and merge them according to the specific needs of your organi0ation. This white paper gives an approach to creating such a blended methodology that is a best fit for your organi0ation2s needs. 'ut even a blended methodology will only be as good as an organi0ation2s commitment to making changes. This commitment must be driven by the highest level of the organi0ation. The good news is that, with a real commitment to change and a tailored methodology for guiding that change, the 206year6old promise of enterprise architecture is within reach. That promise hasn2t changed/ reducing &T cost and comple$ity, while increasing business value and effectivenessor, to put it even more simply, improving your competitiveness in an increasingly competitive world.

!ntroduction
The year 200= marks the 206year anniversary of enterprise architecture. &n that time, a number of enterprise6architectural methodologies have come and gone. Today, four dominate the field/ the *achman +ramework for #nterprise Architectures, The ,pen -roup Architecture +ramework (T,-A+", the +ederal #nterprise Architecture (+#A", and -artner (formerly, the 5eta +ramework". %hould you care about a field that is 20 years old; &t depends. This field was inaugurated to address two ma:or problems in information technology (&T" that were then already becoming apparent. The first problem was managing the increasing comple$ity of information6technology systems. The second problem was the increasing difficulty in delivering real business value with those systems. As you can imagine, these problems are related. The more comple$ a system, the less likely it is that it will deliver ma$imum business value. As you better manage comple$ity, you improve your chances of delivering real business value. %o, should you care about this field; &t depends on how you feel about positively affecting your organi0ation2s bottom line. &f managing system comple$ity and delivering business value are key priorities for you, you should care about enterprise6 architecture methodologies. &f you are focused on maintaining, or rebuilding, &T2s credibility in your organi0ation, or if you strive to promote the use of &T to maintain a competitive position in your industry, you should continue reading this white paper. &f these issues don2t concern you, these methodologies have little to offer. As systems become more comple$, they generally re4uire more planning. &t is easy to see this in buildings. <hen (enry >avid Thoreau built his little cabin on <alden ?ond (shown in +igure 8", he embraced simplicity and needed no architects. &f you are building @ew Aork )ity (shown in +igure 2", simplicity is out of the 4uestion, and you will need many architects.

Figure "# Thoreau$s ca in at %alden Pond& as dra'n y Thoreau$s sister& Sophia Thoreau

Figure (# )e' *or+ City The relationship between comple$ity and planning for buildings and cities is similar for information systems. &f you are building a simple, single6user, nondistributed system, you might need no architects at all. &f you are building an enterprise6wide, mission critical, highly distributed system, you might need a database architect, a solutions architect, an infrastructure architect, a business architect, and an enterprise architect. This paper is about the methodologies needed to develop the overall architectural vision for an organi0ation. This is the responsibility of the enterprise architect. This is the architect who speciali0es in the broadest possible view of architecture within the enterprise. This is the architect2s architect, the architect who is responsible for coordinating the work of all of the other architects. >o you need such an architect; &t all depends on what you are building/ Thoreau2s cabin or @ew Aork )ity. 'uilding a large, comple$, enterprise6wide information system without an enterprise architect is like trying to build a city without a city planner. )an you build a city without a city planner; ?robably. <ould you want to live in such a city; ?robably not. ,f course, hiring a city planner does not guarantee a livable city1 it merely improves your chances. %imilarly, having an enterprise architect does not guarantee a successful enterprise architecture. There are many e$amples of failed enterprise architectures in the world today, and all of them had enterprise architects (probably do0ensB". Architectural methodologies can help, but they go only so far. &2ll discuss some of the reasons for these failures, and how to avoid them, also in this paper. 'efore & get too far into comparing the methodologies that make up the enterprise architect2s toolkit, & need to define some terms. This is especially important in an article that is comparing methodologies, because the different methodologies sometimes use similar terms to mean different things. +or e$ample, we have two methodologies that describe themselves as enterprise6 architectural frameworks/ the *achman +ramework for #nterprise Architectures and

The ,pen -roup Architectural +ramework (T,-A+". Aet these two methodologies share little in common other than the words enterprise, architecture, and framework. %o, & will start by defining the terms as & will use them in this white paper. Those definitions marked with an asterisk (D" are taken mostly from &###68C=862000 E08F, whose definitions & use where they e$ist and make sense. architect,ne whose responsibility is the design of an architecture and the creation of an architectural description architectural artifactA specific document, report, analysis, model, or other tangible that contributes to an architectural description architectural descriptionDA collection of products (artifacts" to document an architecture architectural frame'or+A skeletal structure that defines suggested architectural artifacts, describes how those artifacts are related to each other, and provides generic definitions for what those artifacts might look like architectural methodologyA generic term that can describe any structured approach to solving some or all of the problems related to architecture architectural processA defined series of actions directed to the goal of producing either an architecture or an architectural description architectural taxonomyA methodology for organi0ing and categori0ing architectural artifacts architectureDThe fundamental organi0ation of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution enterprise architectureAn architecture in which the system in 4uestion is the whole enterprise, especially the business processes, technologies, and information systems of the enterprise @ow that we have a common understanding of these key terms, & can take you through the history of enterprise6architecture methodologies, discuss the problems these methodologies are trying to solve, and compare the top four methodologies in terms of their approach and their relationship to each other.

A ,rief -istory of Enterprise Architecture

The field of enterprise architecture essentially started in 87G=, with the publication in the IBM Systems Journal of an article titled HA +ramework for &nformation %ystems Architecture,H by I.A. *achman. &n that paper, *achman laid out both the challenge and the vision of enterprise architectures that would guide the field for the ne$t 20

years. The challenge was to manage the comple$ity of increasingly distributed systems. As *achman said/ The cost involved and the success of the business depending increasingly on its information systems re4uire a disciplined approach to the management of those systems. E02F *achman2s vision was that business value and agility could best be reali0ed by a holistic approach to systems architecture that e$plicitly looked at every important issue from every important perspective. (is multiperspective approach to architecting systems is what *achman originally described as an information systems architectural framework and soon renamed to be an enterprise-architecture framework. *achman was a ma:or influence on one of the earliest attempts by a branch of the K.%. -overnment, the >epartment of >efense, to create an enterprise architecture. This attempt was known as the Technical Architecture +ramework for &nformation 5anagement (TA+&5" E0 F and was introduced in 877C. The promise of enterprise architectures, such as TA+&5, to better align technical pro:ects with business need was noticed by no less a body than the K.%. )ongress. 5ost likely influenced by the promised benefits of TA+&5, )ongress in 877! passed a bill known as the )linger6)ohen Act of 877! E0CF, also known as the &nformation Technology 5anagement .eform Act, which mandated that all federal agencies take steps to improve the effectiveness of their &T investments. A )&, )ouncil, consisting of )&,s from all ma:or governmental bodies, was created to oversee this effort. &n April 877G, the )&, )ouncil began work on its first ma:or pro:ect, the +ederal #nterprise Architecture +ramework (+#A+". Lersion 8.8 E0JF of this framework was released in %eptember of 8777. This document contained some innovate ideas, such as Hsegmented architecturesHthat is, architectural focus on segmented subsets of the larger enterprise. ,ver time, responsibility for federal enterprise architecture moved from the )&, )ouncil to the ,ffice of 5anagement and 'udget (,5'". &n 2002, the ,5' evolved and renamed the +#A+ methodology as the +ederal #nterprise Architecture (+#A". & will describe +#A in greater detail, in the section dedicated to it. >espite the very significant enterprise6architectural activity in the +ederal -overnment (one could argue that no organi0ation has spent more money attempting to develop an enterprise architecture than the K.%. -overnment", progress has been slow and success stories are overshadowed by higher6profile failures. &n 200C, a full eight years after the )linger6)ohen Act mandated the use of effective &T planning processes, the -eneral Accounting ,ffice (-A," reported the following/ ,nly 20 of 7! agencies e$amined had established at least the foundation for effective architecture management. +urther, while 22 agencies increased in maturity since 2008, 2C agencies decreased in maturity and C= agencies remained the same. E0!F %ince Ianuary of 200J, the -eneral Accounting ,ffice (-A,, not to be confused with the ,5'" has severely chastised a number of K.%. agencies for failures in their !

adoption or use of enterprise architecture. A few e$amples include the +'& E0=F, the >epartment of >efense E0GF, the >epartment of (omeland %ecurity E07F, and @A%A E80F. &n 877G, four years after TA+&5 (remember TA+&5;" was introduced and two years after it became codified as )linger6)ohen, TA+&5 was officially retired by the >epartment of >efense. The work done on TA+&5 was turned over to The ,pen -roup. They morphed it into a new standard that is today known as The ,pen -roup Architectural +ramework better known by its acronym, T,-A+. & will discuss the T,-A+ work in the section dedicated to that topic. &n 200J, about the same time that ,5' was becoming the dominant #A force in the public sector, another organi0ation was taking steps to become a dominant force in the private sector. This group was -artner. 'y 200J, -artner was already one of the most influential organi0ations speciali0ing in )&,6level consulting. (owever, in the specific area of enterprise architecture, the best known &T research and advisory group was not -artner, but 5eta -roup. -artner had struggled to build an enterprise6architecture practice, but never achieved the status of the 5eta -roup. &n 200J, -artner decided that if they couldn2t compete with 5eta -roup, they would do the ne$t best thing/ They would buy it. +ollowing the purchase of 5eta -roup, -artner95eta spent a year looking at what each company brought to the table as far as enterprise6architecture e$perience and methodologies. The two companies discussed how best to reconcile their often 4uite different approaches. &n the end, a fairly simple algorithm was applied/ &f 5eta -roup liked it, it was in1 if 5eta -roup didn2t like it, it was out. -artner liked architectural frameworks. The 5eta -roup liked architectural process. %o, frameworks were out1 processes were in. &2ll discuss this -artner95eta process in detail, in the section devoted to -artner. +igure summari0es this history with an enterprise6architecture timeline. This brings us up to date in the history of enterprise architecture. @ow, let2s look more closely at today2s main methodologies and introduce a case study that will be used in this white paper.

Figure .# Enterprise-architecture timeline

Case Study
%o that we can compare and contrast the four ma:or approaches to enterprise architectures, & am going to illustrate how each would approach a similar scenario. This fictitious scenario is a composite of several enterprises with which & have worked over the past several years. %o, while it is fictitious, it is very realistic. &2ll first describe the scenario. 5edA5ore is a chain of drug stores. &t started as a regional chain in 87!0. &n 877J, it developed an innovative software system that enabled it to run drug stores very efficiently. &t called this system 5edA5anage, or 5A5. 5A5 incorporated some innovate business ideas, such as patient6relationship management, inventory management, automated insurance billing, and even utility optimi0ation. 5A5 consisted of three programs/ 5A59%tore, which ran on a small computer at a drug store1 5A59<arehouse, which ran on a server in a regional warehouse1 and 5A59(ome, which ran on a large server at the home office. These three programs communicated through files that were transferred from one location (for e$ample, a store" to another (for e$ample, a regional warehouse". <hen reliable communications lines e$isted, file transfers could occur through +T?. The system was also fle$ible enough to accommodate transfers through courier, where necessary. 'y 2000, 5edA5ore was doing 4uite wellin part, because of the cost6cutting moves enabled by the 5A5 system. 5edA5ore decided to begin e$pansion. To do this, it purchased three regional chains. <ith these purchases, 5edA5ore e$tended its reach through the southeast 4uadrant of the K.%. 'y 2002, it was clear that the same software systems that had initially fueled 5edA5ore2s success were now hampering its future. %ome of the problems 5edA5ore was running into were the following/

5A59%tore re4uired regional speciali0ations. +or e$ample, different insurance plans needed to be supported in different regions, and these all re4uired changes to the 5A59%tore module. The regional warehouses that had been ac4uired through ac4uisition each had different ways of receiving orders from the retail stores and different procedures from ordering supplies from the wholesalers. #ach of these differences re4uired changes to the 5A59<arehouse module. The file6transfer approach to information sharing that had worked so well when 5edA5ore consisted of 0 drugstores, one regional warehouse, and one home office were turning out to be difficult to coordinate among 200 drugstores, four regional warehouses, two geographic offices, and one home office. +iles were often delivered late, sometimes not at all, and occasionally multiple times. This made it difficult for the home office to access reliable, up6 to6date financial information, especially in the areas of sales and inventory.

&t was clear to 5edA5ore management that the 5A5 system needed many enhancements. (owever, upgrading this system was difficult. #ach of the three modules (store, warehouse, and home office" was huge, inefficient, and cumbersome, and each included functionality for everything that each entity might need. The modules had grown to over 8 million lines of code each. &t was difficult to change one function without affecting others. All of the functions accessed a single database, and changes to one record definition could ripple through the system in an unpredictable fashion. )hanging even a single line of code re4uired a rebuild of the entire multimillion6line module. 5edA5anage had become 5edA@ightmare. >ebugging was difficult. %oftware builds were torturous. &nstalling new systems was hugely disruptive. These technical problems soon created internal conflicts within the home office of 5edA5ore. The business side of 5edA5ore wanted to ac4uire two more regional chains, but &T was still struggling to bring the e$isting ac4uisitions online. This resulted in a rapidly growing divide between the business and the technical sides of 5edA5ore. The business side saw &T as reducing business agility. The technical side saw the business side as making impossible demands and blamed it for refusing to consult &T before entering into ac4uisition discussions. The distrust had reached such a point that, by 200J, the )&, was no longer considered part of the e$ecutive team of 5edA5ore. The business side distrusted &T and tried to circumvent it at every opportunity. The technical side built its &T systems with little input from the business folks. %everal large and e$pensive &T initiatives were ignored by the business side and were eventually abandoned. 'y 200!, 5edA5ore was in crisis. &t clearly needed to revamp its technical systems to make them easier to speciali0e for regional re4uirements. This was going to be an e$pensive proposition, and 5edA5ore couldn2t afford for the effort to fail. Iust as importantly, 5edA5ore also had to rebuild its internal relationships. The constant bickering and distrust between business and &T was affecting morale, 7

efficiency, and profitability. A company that only five years earlier was an industry leader in profitabilityin large part, because of its innovative use of &Twas now struggling to stay out of the redin large part, because of the infle$ibility of those same &T systems. )ath, the )#, of 5edA5ore, desperately needed a solution. At a )#, conference, she heard how many of her peers were using enterprise architectures to build stronger partnerships between their technical and business groups and deliver more cost6 effective &T systems that enabled business agility. )ath decided that this approach merited further investigation. %he asked &rma, her )&,, to prepare a recommendation on the use of an enterprise architecture within 5edA5ore. &rma was impressed with the approach, but recogni0ed that any such initiative needed to be driven from the top and needed to involve the business side from the start. ,n &rma2s recommendation, )ath called a meeting with 'ret, the Lice6?resident of 'usiness, and &rma. )ath announced that she had decided to create a common enterprise architecture for 5edA5ore that would unite its technical and business people. This common enterprise architecture would be named 5edA5ore6#nterprise Architecture, or 5A56#A. After it was completed, 5A56#A would drive all new &T investment and ensure that every dollar invested in &T was delivering the ma$imum value to the business. )ath knew that 5A56#A was a bet6the6company decision for 5edA5ore. The 5A56#A vision had to work. )ath was depending on 'ret (the business side" and &rma (the &T side" to make it work. %o, that is the problem. @ow, let2s see how each of the #A approaches might provide a solution for 5edA5ore.

The /achman Frame'or+ for Enterprise Architectures

The first thing we need to understand about the *achman +ramework is that it isn2t a frameworkat least, by my definition of a framework. According to the American (eritage >ictionary, a framework is defined as/ A structure for supporting or enclosing something else, especially a skeletal support used as the basis for something being constructed1 An e$ternal work platform1 a scaffold1 A fundamental structure, as for a written work1 A set of assumptions, concepts, values, and practices that constitutes a way of viewing reality. E88F. A taxonomy, on the other hand, is defined as/ The classification of organisms in an ordered system that indicates natural relationships1 The science, laws, or principles of classification1 systematics1 >ivision into ordered groups or categories E82F

80

The *achman H+rameworkH is actually a ta$onomy for organi0ing architectural artifacts (in other words, design documents, specifications, and models" that takes into account both who the artifact targets (for e$ample, business owner and builder" and what particular issue (for e$ample, data and functionality" is being addressed. As Iohn *achman retrospectively described his work/ The E#nterprise ArchitectureF +ramework as it applies to #nterprises is simply a logical structure for classifying and organi0ing the descriptive representations of an #nterprise that are significant to the management of the #nterprise, as well as to the development of the #nterprise2s systems. E8 F 5any proponents of the *achman +ramework see it as cross6disciplinary, with influence e$tending far beyond &T. ,ne popular book on *achman, for e$ample, says/ ...in due course, you will discover that the +ramework e$ists in everything you do, not only &T pro:ects. <hen you thoroughly understand the +ramework, you can become more effective in everything you do. This means everything. This statement is not made lightly. E8CF Iohn *achman himself told me, in an interview that & recently conducted with him/ ...the +ramework schema has been around for thousands of years and & am sure it will be around for a few more thousands of years. <hat changes is our understanding of it and how to use it for #nterprise engineering and manufacturing. E8JF *achman originally e$plained his &T ta$onomy using the building industry as an analogy. &n that industry, architectural artifacts are implicitly organi0ed using a two6 dimensional organi0ation. ,ne dimension is the various Hplayers in the game.H +or a physical building, some of these players are the owner (who is paying for the pro:ect", the builder (who is coordinating the overall construction", and a 0oning board (who is ensuring that construction follows local building regulations". A building architect prepares different artifacts for each of these players. #very player demands complete information, but what constitutes completeness differs for the different players. The owner is interested in a complete description of the functionality and aesthetics of the building. The builder is interested in a complete description of the materials and construction process. The owner doesn2t care about the placement of studs in the walls. The builder doesn2t care how the bedroom windows line up with the morning sun. As *achman said in his original article/ ...each of the architectural representations differs from the others in essence, not merely in level of detail. E8!F The second dimension for architectural artifact organi0ation is the descriptive focus of the artifact/ the what, how, where, who, when, and why of the pro:ect. This dimension is independent of the first. 'oth the builder and the owner need to know what, but the

88

owner2s need to know what is different from the builder2s need to know what. <hat what is what depends on who is asking the 4uestion. &n his first paper and *achman2s subse4uent elaboration in 8772 E8=F, *achman proposed that there are si$ descriptive foci (data, function, network, people, time, and motivation" and si$ player perspectives (planner, owner, designer, builder, subcontractor, and enterprise." These two dimensions can be arranged in a grid, as shown in +igure C. +rom the business owner2s perspective, HdataH means business entities. This can include information about the entities themselves, such as customers and products, or information about relationships between those entities, such as demographic groups and inventories. &f you are talking to a business owner about data, this is the language you should use. +rom the perspective of the person implementing the database, HdataH does not mean business entities, but rows and columns organi0ed into tables and linked together by mathematical :oins and pro:ections. &f you are talking to a database designer about data, don2t talk about customer demographic groups, but talk about third6normal relational tables. &t2s not that one of these perspectives is better than the other or more detailed than the other or of a higher priority than the other. Both of these perspectives on data are critical to a holistic understanding of the system2s architecture. As *achman said/ <e are having difficulties communicating with one another about information systems architecture, because a set of architectural representations e$ists, instead of a single architecture. ,ne is not right and another wrong. The architectures are different. They are additive and complementary. There are reasons for electing to e$pend the resources for developing each architectural representation. And there are risks associated with not developing any one of the architectural representations. E8GF & discussed the historical importance of the *achman +ramework in the history section. (ere, & will discuss the actual framework itself and how it could be used to help build 5A56#A, the problem proposed in the case6study section. As & mentioned earlier, the *achman +ramework consists of si$ functional foci, each considered from the perspective of a ma:or player. The *achman +ramework as it is portrayed today is shown in +igure C.

82

Figure 0# /achman grid As you can see from +igure C, there are ! intersecting cells in a *achman gridone for each meeting point between a player2s perspective (for e$ample, business owner" and a descriptive focus (for e$ample, data.". As we move hori0ontally (for e$ample, left to right" in the grid, we see different descriptions of the systemall from the same player2s perspective. As we move vertically in the grid (for e$ample, top to bottom", we see a single focus, but change the player from whose perspective we are viewing that focus. There are three suggestions of the *achman grid that can help 5edA5ore in the development of 5A56#A. The first suggestion of the *achman ta$onomy is that every architectural artifact should live in one and only one cell. There should be no ambiguity about where a particular artifact lives. &f it is not clear in which cell a particular artifact lives, there is most likely a problem with the artifact itself. As 5edA5ore begins accumulating artifacts in the development of 5A56#A, it can use the *achman grid to clarify the focus of each of these artifacts. +or e$ample, artifacts relating to a service6oriented architecture live mostly in the third row (designer2s perspective". They generally will not be of interest to the business owner ('ret, in the 5edA5ore case study". The second suggestion of the *achman ta$onomy is that an architecture can be considered a complete architecture only when every cell in that architecture is complete. A cell is complete when it contains sufficient artifacts to fully define the system for one specific player looking at one specific descriptive focus.

<hen every cell is populated with appropriate artifacts, there is a sufficient amount of detail to fully describe the system from the perspective of every player (what we might today call a stakeholder" looking at the system from every possible angle (descriptive focus". %o, 5edA5ore can use the *achman grid to ensure that appropriate discussions are occurring between all of the important stakeholders of 5A56#A. The third suggestion of the *achman grid is that cells in columns should be related to each other. )onsider, for e$ample, the data column (the first column" of the *achman grid. +rom the business owner2s ('ret2s" perspective, data is information about the business. +rom the database administrator2s perspective, data is rows and columns in the database. <hile the business owner thinks about data 4uite differently from the database administrator, there should be some relationship between these perspectives. %omebody should be able to follow 'ret2s business re4uirements and show that the database design is, in fact, being driven by those re4uirements. &f 'ret has re4uirements that are not traceable down to the database design, we must ask if the business needs will be met by this architecture. ,n the other hand, it there are database6design elements that do not trace back to business re4uirements, we might ask if we have included unnecessary design at the database level. %o, we can see five ways in which the *achman grid can help in the development of 5A56#A. &t can help/ 8. #nsure that every stakeholder2s perspective has been considered for every descriptive focal point. 2. &mprove the 5A56#A artifacts themselves by sharpening each of their focus points to one particular concern for one particular audience. . #nsure that all of 'ret2s business re4uirements can be traced down to some technical implementation. C. )onvince 'ret that &rma2s technical team isn2t planning on building a bunch of useless functionality. J. )onvince &rma that the business folks are including her &T folks in their planning. 'ut *achman by itself is not a complete solution for 5edA5ore. There are far too many issues that will be critical to 5A56#A2s success that *achman does not address. *achman does not give us a step6by6step process for creating a new architecture. *achman doesn2t even give us much help in deciding if the future architecture we are creating is the best architecture possible. +or that matter, *achman doesn2t even give us an approach to show a need for a future architecture. +or these and other issues, we are going to need to look at other methodologies.

The 1pen 2roup Architecture Frame'or+ 3T12AF4

The ,pen -roup Architecture +ramework is best known by its acronym, T,-A+. T,-A+ is owned by The ,pen -roup E87F. T,-A+2s view of an enterprise architecture is shown in +igure J.

8C

Figure 5# T12AF$s enterprise architecture As shown in the figure, T,-A+ divides an enterprise architecture into four categories, as follows/ 8. ,usiness architecture>escribes the processes the business uses to meet its goals 2. Application architecture>escribes how specific applications are designed and how they interact with each other . 6ata architecture>escribes how the enterprise datastores are organi0ed and accessed C. Technical architecture>escribes the hardware and software infrastructure that supports applications and their interactions T,-A+ describes itself as a Hframework,H but the most important part of T,-A+ is the Architecture >evelopment 5ethod, better known as A>5. A>5 is a recipe for creating architecture. A recipe can be categori0ed as a process. -iven that A>5 is the most visible part of T,-A+, & categori0e T,-A+ overall as an architectural process, instead of either an architectural framework (as The ,pen -roup describes T,-A+" or a methodology (as it describes A>5". Liewed as an architectural process, T,-A+ complements *achmanwhich, recall, & categori0ed as an architectural taxonomy. *achman tells you how to categori0e your artifacts. T,-A+ gives you a process for creating them. T,-A+ views the world of enterprise architecture as a continuum of architectures, ranging from highly generic to highly specific. &t calls this continuum the #nterprise )ontinuum. &t views the process of creating a specific enterprise architecture, such as 5A56#A, as moving from the generic to the specific. T,-A+2s A>5 provides a process for driving this movement from the generic to the specific. T,-A+ calls most generic architectures Foundation rchitectures. These are architectural principles that can, theoretically, be used by any &T organi0ation in the universe. T,-A+ calls the ne$t level of specificity !ommon Systems rchitectures. These are principles that one would e$pect to see in manybut, perhaps, not alltypes of enterprises. 8J

T,-A+ calls the ne$t level of specificity Industry rchitectures. These are principles that are specific across many enterprises that are part of the same domainsuch as, in our 5edA5ore case study, all pharmaceutical enterprises. T,-A+ calls the most specific level the "rgani#ational rchitectures. These are the architectures that are specific to a given enterprise, such as 5edA5ore. +igure ! shows the relationship between the #nterprise )ontinuum and the Architecture >evelopment 5ethod (A>5".

Figure 7# The T12AF Enterprise Continuum T,-A+ defines the various knowledge bases that live in the +oundation Architecture. Two that you might run into are the $echnical %eference Model (T.5" and the Standards Information Base (%&'". The T.5 is a suggested description of a generic &T architecture. The %&' is a collection of standards and pseudo6standards that The ,pen -roup recommends that you consider in building an &T architecture. T,-A+ presents both the T.5 and the %&' as suggestions1 neither is re4uired. &n my view, both the T.5 and the %&' are flawed for the same reason/ They are biased toward application portability, at the e$pense of application interoperability and application autonomy. & consider this an outdated view of technical architectures. +or an organi0ation such as 5edA5ore, T,-A+ largely boils down to the Architecture >evelopment 5ethod (A>5". &ndividuals within 5edA5ore will be e$posed to the #nterprise )ontinuum, the %&', and the T.5 (as well as a few other T,-A+ features", which is why & discussed them. 'ut the day6to6day e$perience of creating an enterprise architecture will be driven by the A>5, a high6level view of which is shown in +igure =.

8!

Figure 8# The T12AF Architecture 6evelopment Method 3A6M4 As shown in +igure =, the T,-A+ A>5 consists of eight phases that are cycled through after an initial Hpriming of the pump.H &2ll take you through these phases as they could be applied to the 5edA5ore case study. 'ut, before 5edA5ore can start the A>5, it needs to gain some e$perience with T,-A+. 5edA5ore will have two choices on how it can get this e$perience. +irst, 5edA5ore can train itself in T,-A+. 5edA5ore can download the T,-A+ documentation E20Fwhich describes all of T,-A+, including the A>5, in considerable detail. &t can purchase books on T,-A+ E28F. There is probably more free and ine$pensive available information about T,-A+ than about all other architectural methodologies combined. %econd, 5edA5ore can buy e$pertise in T,-A+. There are consultants who speciali0e in T,-A+ and have earned ,pen -roup certification E22F. 'ecause 5edA5ore wants to minimi0e any chances of failure, it has chosen to call in a T,-A+ consultant. 5edA5ore has brought in Teri, an ,pen -roupMcertified T,-A+ architect. .emember that the other players at 5edA5ore are )ath, the )#, of 5edA5ore1 'ret, the 'usiness L?1 and &rma, the )&,. &n the ?reliminary ?hase, Teri meets with the ma:or players at 5edA5ore to introduce the T,-A+ process. (er three goals in the preliminary phase are to/ 8. 5ake sure everybody is comfortable with the process. 2. 5odify the T,-A+ process, as necessary, to fit within the 5edA5ore culture. . %et up the governance system that will oversee future architectural work at 5edA5ore. Teri will work closely with 'ret to understand the business philosophy, business models, and strategic drivers of 5edA5ore. %he will work closely with &rma to define the architectural principles that drive technological architectures at 5edA5ore and document those principles using the T,-A+6recommended format. 8=

&n some organi0ations, achieving buy6in on the need for an enterprise architecture could be very difficult. This is especially true when the effort is driven from the &T organi0ation, and even more so when there is a history of discord between the business and the technical sides of the organi0ation. 5edA5ore does have this history of animosity. (owever, it has another fact going for it from which Teri should take heart/ The effort is not driven by &T, but is driven by )ath, the )#,. This gives the pro:ect high visibility and creates a positive incentive for cooperation from all sides. As soon as Teri and 5edA5ore have completed the ?reliminary ?hase, they are ready to start ?hase A. ?hase A begins, at least in theory, with a %e&uest for rchitecture 'ork from some organi0ation within 5edA5ore. This document includes the business reasons for the re4uest, budget and personnel information, and any constraints that need to be considered. 'ecause 5edA5ore has never done a %e&uest for rchitecture 'ork, Teri will probably need to work with the sponsoring organi0ation in creating such a re4uest. As soon as the .e4uest for Architecture <ork (or some e4uivalent" has been received, Teri (the T,-A+ consultant" starts 5edA5ore on ?hase A. &n ?hase A, Teri will ensure that the pro:ect has the necessary support within 5edA5ore, define the scope of the pro:ect, identify constraints, document the business re4uirements, and establish high6level definitions for both the baseline (starting" architecture and target (desired" architecture. These baseline and target definitions will include high6level definitions on all four of the #A sub6architectures shown back in +igure Jnamely, business, technology, data, and application architectures. The culmination of ?hase A will be a %tatement of Architecture <ork, which must be approved by the various stakeholders before the ne$t phase of the A>5 begins. The output of this phase is to create an architectural vision for the first pass through the A>5 cycle. Teri will guide 5edA5ore into choosing the pro:ect, validating the pro:ect against the architectural principles established in the ?reliminary ?hase, and ensure that the appropriate stakeholders have been identified and their issues have been addressed. The Architectural Lision created in ?hase A will be the main input into ?hase '. Teri2s goal in ?hase ' is to create a detailed baseline and target business architecture and perform a full analysis of the gaps between them. %he will work primarily with 'ret (or 'ret2s team" to achieve this. ?hase ' is 4uite involvedinvolving business modeling, highly detailed business analysis, and technical6re4uirements documentation. A successful ?hase ' re4uires input from many stakeholders. The ma:or outputs will be a detailed description of the baseline and target business ob:ectives, and gap descriptions of the business architecture. ?hase ) does for the information6systems architecture what ?hase ' does for the business architecture. &n this phase, Teri works primarily with &rma (or her team". T,-A+ defines nine specific steps, each with multiple sub6steps/ 8G

8. >evelop baseline data6architecture description 2. .eview and validate principles, reference models, viewpoints, and tools . )reate architecture models, including logical data models, data6management process models, and relationship models that map business functions to ).K> ()reate, .ead, Kpdate, >elete" data operations C. %elect data6architecture building blocks J. )onduct formal checkpoint reviews of the architecture model and building blocks with stakeholders !. .eview 4ualitative criteria (for e$ample, performance, reliability, security, integrity" =. )omplete data architecture G. )onduct checkpoint9impact analysis 7. ?erform gap analysis The most important deliverable from this phase will be the Target &nformation and Applications Architecture. ?hase > completes the technical architecturethe infrastructure necessary to support the proposed new architecture. This phase is completed mostly by engaging with &rma2s technical team. ?hase # evaluates the various implementation possibilities, identifies the ma:or implementation pro:ects that might be undertaken, and evaluates the business opportunity associated with each. The T,-A+ standard recommends that Teri2s first pass at ?hase # Hfocus on pro:ects that will deliver short6term payoffs and so create an impetus for proceeding with longer6term pro:ects.H This is good advice in any architectural methodology. Therefore, Teri should be looking for pro:ects that can be completed as cheaply as possible, while delivering the highest perceived value. A good starting place to look for such pro:ects is the organi0ational pain6points that initially convinced )ath (the 5edA5ore )#," to adopt an enterprise architectural6based strategy in the first place. These pain6points, described earlier, included difficulties in completing regional9warehouse speciali0ation and unreliability in data sharing. ?hase + is closely related to ?hase #. &n this phase, Teri works with 5edA5ore2s governance body to sort the pro:ects identified in ?hase # into priority order that include not only the cost and benefits (identified in ?hase #", but also the risk factors. &n ?hase -, Teri takes the prioriti0ed list of pro:ects and creates architectural specifications for the implementation pro:ects. These specifications will include acceptance criteria and lists of risks and issues. The final phase is (. &n this phase, Teri modifies the architectural change6 management process with any new artifacts created in this last iteration and with new information that becomes available. Teri is then ready to start the cycle again. ,ne of the goals from the first cycle should be information transfer, so that Teri2s services are re4uired less and less as more and more iterations of the cycle are completed. 87

5uch of the results of the T,-A+ process will be determined as much by the Teri95edA5ore relationship as it will by the T,-A+ specification itself. T,-A+ is meant to be highly adaptable, and details for the various architectural artifacts is sparse. As one book on T,-A+ says/ T,-A+ is not wholly specific with respect to generated documents1 in fact, it provides very little in the way of prescriptive document templatesmerely guidelines for inputs and outputs. E2 F The T,-A+ specification is also fle$ible with respect to the phases. As the specification itself says/ ,ne of the tasks before applying the A>5 is to review its components for applicability, and then tailor them as appropriate to the circumstances of the individual enterprise. This activity might well produce an Henterprise6specificH A>5. E2CF T,-A+ allows phases to be done incompletely, skipped, combined, reordered, or reshaped to fit the needs of the situation. %o, it should be no surprise if two different T,-A+6certified consultants end up using two very different processeseven when working with the same organi0ation. T,-A+ is even more fle$ible about the actual generated architecture. &n fact, T,-A+ is, to a surprising degree, Harchitecture6agnosticH. The final architecture might be good, bad, or indifferent. T,-A+ merely describes how to generate an enterprise architecture, not necessarily how to generate a good enterprise architecture. +or this, you are dependent on the e$perience of your staff and9or T,-A+ consultant. ?eople adopting T,-A+ in the hopes of ac4uiring a magic bullet will be sorely disappointed (as they will be with any of the methodologies".

Federal Enterprise Architecture 3FEA4

The +ederal #nterprise Architecture (+#A" is the latest attempt by the federal government to unite its myriad agencies and functions under a single common and ubi4uitous enterprise architecture. +#A is still in its infancy, as most of the ma:or pieces have been available only since 200!. (owever, as & discussed in the history section, it has a long tradition behind it and, if nothing else, has many failures from which it has hopefully learned some valuable lessons. +#A is the most complete of all the methodologies discussed so far. &t has both a comprehensive ta$onomy, like *achman, and an architectural process, like T,-A+. +#A can be viewed as either a methodology for creating an enterprise architecture or the result of applying that process to a particular enterprisenamely, the K.%. -overnment. & will be looking at +#A from the methodology perspective. 5y particular interest here is how we can apply the +#A methodology to private enterprises. 5ost writers describe +#A as simply consisting of five reference models, one each for performance/ business, service, components, technical, and data. &t is true that +#A

20

has these five references models, but there is much more to +#A than :ust the reference models. A full treatment of +#A needs to include all of the following/

A perspective on how enterprise architectures should be viewed (the segment model, that & will describe shortly" A set of reference models for describing different perspectives of the enterprise architecture (the five models, mentioned earlier" A process for creating an enterprise architecture A transitional process for migrating from a pre6#A to a post6#A paradigm A ta$onomy for cataloging assets that fall within the purview of the enterprise architecture An approach to measuring the success of using the enterprise architecture to drive business value

Aou can see that the +#A is about much more than models. &t includes everything necessary to build an enterprise architecture for probably the most comple$ organi0ation on earth/ the K.%. -overnment. As the +#A6?rogram 5anagement ,ffice (+#A?5," says, +#A, taken in toto, provides/ ...a common language and framework to describe and analy0e &T investments, enhance collaboration and ultimately transform the +ederal government into a citi0en6 centered, results6oriented, and market6based organi0ation as set forth in the ?resident2s 5anagement Agenda. E2JF. <hile it might be a stretch to imagine that anything short of divine intervention could Htransform the +ederal government into a citi0en6centered, results6oriented, and market6based organi0ation,H there is at least hope that some of the +#A methodology could help our beleaguered 5edA5ore corporation deal with its much more mundane problems. %o, let2s take a look at what +#A has to offer.

The FEA Perspective on EA

The +#A ?erspective on #A is that an enterprise is built of segments, an idea first introduced by +#A+ E2!F. A segment is a ma:or line6of6business functionality, such as human resources. There are two types of segments/ core mission-area segments and business6services segments. A core mission-area segment is one that is central to the mission or purpose of a particular political boundary within the enterprise. +or e$ample, in the (ealth and (uman %ervices (((%" agency of the federal government, health is a core mission6 area segment. A business-services segment is one that is foundational to most, if not all, political organi0ations. +or e$ample, financial management is a business6services segment that is re4uired by all federal agencies. Another type of enterprise6architecture asset is an enterprise service. An enterprise service is a well6defined function that spans political boundaries. An e$ample of an enterprise service is security management. %ecurity management is a service that works in a unified manner across the whole swath of the enterprise. 28

The difference between enterprise services and segments, especially business-service segments, is confusing. 'oth are shared across the entire enterprise. The difference is that business6service segments have a scope that encompasses only a single political organi0ation. #nterprise services have a scope that encompasses the entire enterprise. &n the federal government, for e$ample, both ((% and the #nvironmental ?rotection Agency (#?A" use the human resources business6service segment. (owever, the people who are managed by human resources are a different group for ((% from what they are for the #?A. 'oth ((% and the #?A also use the security management enterprise service. 'ut the security credentials that are managed by the security6management service are not specific to either of those agencies. %ecurity credentials are managed effectively only when they are managed at the scope of the enterprise. .esist the temptation to e4uate either segments or services with services, as in service-oriented architectures. There are two reasons such a comparison would be flawed. +irstly, enterprise services, business6service segments, and core mission6area segments are all much broader in focus than services found in service6oriented architectures. %econdly, segments are an organi0ational unit for an enterprise architecture, whereas services are an organi0ational unit for technical implementations. As organi0ational units for an enterprise architecture, their depth includes not :ust the technical, but also the business and the data architectures. ,ne final note about segments/ Although segments function at the political (that is, agency" level, they are defined at the enterprise (that is, government" level. #nterprise services, of course, both function and are defined at the enterprise level. The fact that segments are defined globally facilitates their reuse across political boundaries. ,ne can map out the usage of segments across the political boundaries of the enterprise, then use that map to seek opportunities for architectural reuse. +igure G, for e$ample, shows a segment map of the federal government from the +#A ?ractice -uide E2=F. As you can see, there are many segments (the vertical columns" that are used in multiple agencies, and any or all of these are good candidates for sharing.

22

Figure 9# Segment map of the federal government

FEA :eference Models

The five +#A reference models are all about establishing common languages. The goal here is to facilitate communication, cooperation, and collaboration across political boundaries. According to the +#A?5,/ The +#A consists of a set of interrelated Hreference modelsH designed to facilitate cross6agency analysis and the identification of duplicative investments, gaps, and opportunities for collaboration within and across agencies. )ollectively, the reference models EcomposeF a framework for describing important elements of the +#A in a common and consistent way. E2GF <hy do we need a common language; )onsider this e$change/ ;ames: >o you have a torch & can borrow; :oger: @o, &2m afraid not. ;ames: >o you know where & can get one; :oger: The hardware store in town should have one. %o, Iames goes out to the hardware store and buys himself a torch. (e returns. :oger: >id you get your torch; ;ames: Aes, here it is. :oger: That2s not a torchB That2s a flashlight. <hy didn2t you say so; & have one you could have borrowed. ;ames: <ell, why didn2t you say so;

The problem, of course, is that Iames comes from #ngland, where what & call a flashlight they call a torch. And when & hear torch, & think of a blowtorch. Although we both speak #nglish, we don2t necessarily speak the same #nglish. The result is that Iames goes out and unnecessarily spends money on something that & could have lent him. This is e$actly the problem that the +#A .eference 5odels are trying to solve on a much larger scale. %uppose the &nternal .evenue %ervice (&.%" decides it needs a demographics system to track ta$payer data. They ask around to see if anybody has one they can modify for their purposes. @obody does. 3ittle do they know that, right ne$t door, the -overnment ?rinting ,ffice (-?," has a perfectly good demographics system that is almost e$actly what the &.% needs. They :ust happen to call it a customer-analytics system. %o, the &.% goes out and builds its system from scratch, instead of :ust modifying the one already built (and paid for" by the -?,. And, in doing so, the &.% will waste considerably more money than Iames spent on his unnecessary flashlight. This, in a nutshell, is the goal of the five +#A reference models/ to give standard terms and definitions for the domains of enterprise architecture and, thereby, facilitate collaboration and sharing across the federal government. The five reference models are as follows/ 8. The Business %eference Model (B%M) gives a business view of the various functions of the federal government. +or e$ample, the '.5 defines a standard business capability called water resource management that is a subfunction of natural resources that is considered a line-of-business of the broader services for citi#ens business area. E27F 2. The !omponents %eference Model (!%M) gives a more &T view of systems that can support business functionality. +or e$ample, the ).5 defines a customer-analytics system that & described earlier in the hypothetical interchange between the &.% and the -?,. E 0F . The $echnical %eference Model ($%M) defines the various technologies and standards that can be used in building &T systems. +or e$ample, the T.5 defines *$$+ as a protocol that is a subset of a service transport that is a subset of service access and delivery. E 8F C. The ,ata %eference Model (,%M) defines standard ways of describing data. +or e$ample, the >.5 defines an entity as something that contains attributes and participates in relationships. E 2F J. The +erformance %eference Model (+%M) defines standard ways of describing the value delivered by enterprise architectures. +or e$ample, the ?.5 describes &uality as a technology measurement area that is defined as Hthe e$tent to which technology satisfies functionality or capability re4uirements.H E F

FEA Process
The +#A ?rocess is primarily focused on creating a segment architecture for a subset of the overall enterprise (in +#A2s case, the enterprise is the federal government and 2C

the subset is a governmental agency" and is described in the +#A ?ractice -uidance E CF. & discussed the +#A vision on enterprise segments earlier. The overall segment6 architecture development process is (at a very high level" as follows/

%tep 8/ Architectural Analysis>efine a simple and concise vision for the segment, and relate it back to the organi0ational plan. %tep 2/ Architectural >efinition>efine the desired architectural state of the segment, document the performance goals, consider design alternatives, and develop an enterprise architecture for the segment, including business, data, services, and technology architectures. %tep / &nvestment and +unding %trategy)onsider how the pro:ect will be funded. %tep C/ ?rogram65anagement ?lan and #$ecute ?ro:ects)reate a plan for managing and e$ecuting the pro:ect, including milestones and performance measures that will assess pro:ect success.

FEA Success Measurement

The +#A framework for measuring organi0ational success in using enterprise architecture is defined in the +ederal #nterprise Architecture ?rogram #A Assessment +ramework 2.8 E JF. +ederal agencies are rated on their overall maturity levels in three main categories/ 8. Architectural completion5aturity level of the architecture itself 2. Architectural use(ow effectively the agency uses its architecture to drive decision6making . Architectural resultsThe benefits being reali0ed by the use of the architecture ,5' assigns each agency a success rating, based on its scores in each category and a cumulative score, as follows/

-reenThe agency rates 4uite well in the completion area (it has a 4uite mature enterprise architecture". &t also rates well in both the use area (it is effectively using that enterprise architecture to drive ongoing strategy" and the results area (the usage of that architecture is driving business value". AellowThe agency rates 4uite well in the completion area. &t also rates well in either the use area or the results area. .edThe agency either does not have a completed architecture and9or is not effectively using that architecture.

The framework is interesting beyond the confines of the public sector. The category ratings can be fruitfully adapted by many enterprises to assess the maturity level of their own architectural efforts. +igure 7, for e$ample, shows my own interpretation of the ,5' maturity rankings for architectural completion, as & adapt them for the private sector. %imilar adaptations can be created for architectural usage and architectural results.

2J

Figure <# 1M, ran+ing of architectural completion& adapted for private sector y author 3:oger Sessions4

FEA Applied to MedAMore

@ow that & have taken you through the +#A approach, let2s see what this might mean to 5edA5ore. 3et2s assume that )ath (5edA5ore2s )#," has heard about +#A and how it is promising to streamline the federal government. &f it can do this for the federal government, she reasons, surely it can do this for her company. )ath hires a consultant, +red, who is an e$pert on +#A (if such a thing can be said to e$ist for a methodology that is, at the time of this writing, less than a year oldB". +red2s :ob is to show 5edA5ore how to do +#Aof course, not the real +#A, but +#A as it might be applied to the private sector. )ath introduces +red to 'ret (the business L?" and &rma (the )&,", and tells them to build her an5#A+#A adapted for 5edA5ore. Neep in mind that )ath has taken 4uite a risk. @o other company to date has attempted to apply +#A to the private sector1 and even the e$perience of using +#A within the public sector is nominal, at best. The first thing that +red will want to do is build enthusiasm for 5#A. Neep in mind that he is coming into an organi0ation in which the business folks barely speak to &T folks. &f 5#A is going to succeed, it needs to transform not only processes, but people. (e will want to create a series of seminars e$plaining the value of the soon6to6 be6defined 5#A and how 5#A will benefit not only 5edA5ore as a whole, but the individual units specifically.

2!

+red will ne$t build a governance structure5edA5ore2s e4uivalent to +#A?5,. &2ll call this group 5#A?5,. 5#A?5, will own 5#A, including the processes, the models, and the architecture itself. The ne$t thing that +red will likely do is create reference models that can be used by all of the organi0ations across 5edA5ore. The five reference models from +#A can serve as a starting point. %ome, such as the Technical .eference 5odel, might be usable with few modifications. ,thers, such as the 'usiness .eference 5odel, will re4uire e$tensive renovation. (e shouldn2t do these in e$cruciating detail, but create starting points and build them up as 5#A evolves. @e$t, +red will probably want to create a description of the segment architecture as it applies to 5edA5ore. @ote that he will not be doing a complete segment architecture :ust a high6level description. The actual process of completing the architecture will be a constantly evolving pro:ect. 'y this point, a lot of work will have been done with few results. +red will probably want to take a first pass at a segment6architecture process. +#A2s process will be a good starting point, but will re4uire speciali0ation to 5edA5ore at the detail level (such as who the team members are and what form the generated artifacts should take". @ow, +red will test6drive the process with the first segment delivery. (e will need to build a team, and then lead this team in analy0ing and prioriti0ing the segments mapping them to business value, determining their architectural options, delivering the work, and, perhaps most importantly, measuring the results. These measurements will be critical in building momentum for future work. %oon after completing the first segment, +red might decide that it is time to measure the progress of the different groups in 5edA5ore in using 5#A effectively. To do so, +red needs a yardstick to measure the success of the different groups within 5edA5ore in driving business value with 5#A. +red thus leads 5#A?5, in building a 5edA5ore e4uivalent to the +ederal #nterprise Architecture ?rogram #A Assessment +ramework E JF. This yardstick will be )ath2s main tool for ensuring that both the different groups are taking 5#A seriously and her investment is paying off. And, finally, after +red has completed this process, he will start the process again. #ach iteration will result in new segments being delivered, more business value being generated, and more substance being added to the 5#A methodology. At least, this is the theory. As & said earlier, with 5#A, we are working at the bleeding edge.

2artner
%o far, & have written about three different methodologies that come together under the banner of enterprise architectures. This last methodology is a little different. &t isn2t a ta$onomy (like *achman", a process (like T,-A+", or a complete methodology (like +#A". &nstead, it is what & define as a practice. &t is the enterprise6 architecture practice of one of the best known &T research and consulting organi0ations in the world/ -artner.

2=

3et me spend a moment e$ploring my use of the word practice. & use the word HpracticeH much like & would to describe a physician2s practice. A physiciansay, >r. ?Ore0does not diagnose a disease by studying ta$onomies, although ta$onomies do help him communicate to other healthcare providers. (e does not diagnose a disease by following a process, although he might go through an informal process in his head. (e diagnoses a disease by applying his practice skills. These practice skills include his e$perience, training, and ongoing relationships with his colleagues. (ow do you choose a physician; >o you grill candidates on how well they know the ta$onomy of medicine; >o you sit candidates down and ask for a detailed description of the methodology each follows to diagnose illness; ?robably not. Aou might ask your friends, but they probably only know a limited pool of candidates. ,ne approach to choosing a physician is to go to a well6known institution (a hospital or medical school" and choose from among their staff. &n this approach, you are counting on the institution to choose highly 4ualified physicians and to have developed a community that encourages collaboration and best practices. >oes that institution insist on a rigid methodology for its physicians to follow; ?robably not. #ven if it does, it is not your primary concern. Aou are not even concerned with who the physicians in the institution arealthough, in time, that will be of more interest to you. Aour initial concern is only the reputation of the institution. This is very similar to the -artner approach to enterprise architecture. Aou don2t bring in -artner because they do or don2t use T,-A+. Aou don2t go to -artner because they do or don2t follow *achman2s ta$onomy. Aou go to -artner because they are well6 known in their field. Aou assume both that they hire well64ualified specialists and that they have developed a community that encourages collaboration and best practice. &f you are a -artner customer and you check the -arner library for research notes describing their enterprise6architecture practice, you can find many such documents. +or e$ample, there is H-artner #nterprise Architecture ?rocess/ #volution 200JH E !F and H-artner #nterprise Architecture +ramework/ #volution 200JH E =F. (owever, these documents contain little descriptive information and, in any case, are dated in the late6200J timeframe. -artner contends that these best practices are timeless, and they continue to augment them as appropriate. The current -artner methodology was not solidified until probably April of 200!, after the -artner95eta merger that & described in the history section. The best summation of the -artner practice that & have heard is the following/ Architecture is a verb, not a noun. <hat does it mean to say that architecture is a verb, not a noun; &t means that it is the ongoing process of creating, maintaining, and, especially, leveraging an enterprise architecture that gives an enterprise architecture its vitality. An architecture that is :ust a bunch of stiff artifacts that sit in a corner gathering dust is useless, regardless of how sophisticated your ta$onomy is for categori0ing those artifacts or how brilliant your process is that guided their development. 2G

-artner believes that enterprise architecture is about bringing together three constituents/ business owners, information specialists, the technology implementers. &f you can bring these three groups together and unify them behind a common vision that drives business value, you have succeeded1 if not, you have failed. %uccess is measured in pragmatic terms, such as driving profitability, not by checking off items on a process matri$. -artner believes that the enterprise architectures must start with where an organi0ation is going, not with where it is. &f we are going to clean house, we don2t need to e$haustively document everything we are throwing out. 3et2s focus our energy on what we want to end up with. As soon as we know our goal, we can see how what we have relates to that goal. -artner recommends that an organi0ation begin by telling the story of where its strategic direction is heading and what the business drivers are to which it is responding. -artner will want this story in plain language, without worrying about prescribed documentation standards, acronyms, or techno6babble. The only goal is making sure that everybody understands and shares a single vision. 5ost organi0ations are facing ma:or changes in their business processes. The process of creating an enterprise6architecture vision is the organi0ation2s opportunity to sit down, take a collective breath, and ensure that everybody understands the nature, the scope, and the impact of those changes. As soon as an organi0ation has this single shared vision of the future, it can consider the implications of this vision on the business, technical, information, and solutions architectures of the enterprise. The shared vision of the future will dictate changes in all of these architectures, assign priorities to those changes, and keep those changes grounded in business value. #nterprise architecture, in the -artner view, is about strategy, not about engineering. &t is focused on the destination. The two things that are most important to -artner are where an organi#ation is going and how it will get there. Any architectural activity that is e$traneous to these 4uestions is irrelevant. HIust enough enterprise architecture, :ust in time,H is another saying you will hear from the -artner analyst. 3et2s say )ath (5edA5ore2s )#," likes what she hears. (ow is a -artner engagement likely to proceed; <ith +#A, T,-A+, or *achman, )ath needs to start by finding a 4ualified consultant who understands the methodology. <ith -artner, this step is much easier/ %he merely calls -artner. 3et2s say -artner sends -reg, the -artner #A consultant. The first thing -reg will want to do is make sure the architecture is driven from the highest levels of the corporation. The fact that he is being called by 5edA5ore2s )#, will be very reassuring. #$actly how -reg will proceed is difficult to predict, because -artner does not have a firm, step6by6step process. (owever, it is likely that he will start by focusing on )ath2s strategic vision for 5edA5ore. (e will want her to specify her vision in

27

business terms and resist any temptation to discuss technology. (ere are some possible business6vision statements -reg might elicit/

5edA5ore will have stores in at least 0 states, spread out over G geographic regions, by the year 2080. &t will accomplish this mainly through ac4uisition of regional pharmacies. 5edA5ore will be able to assimilate new regional systems within 820 days of finali0ation of purchase. 5edA5ore will reduce its purchasing costs by 80 percent, by consolidating all regional purchasing into a central system. 5edA5ore2s central office will be able to view consolidated sales and inventory reports from all stores that include data up to and including the previous day. 5edA5ore will be able to reduce its inventory on6hand to no more than a five6day supply. 5edA5ore will be able to invoice insurance companies by the end of the day on which the prescription was delivered to the patient. ?atients will be able to transfer prescriptions from any 5edA5ore pharmacy to any other. ?atients will be able to re4uest prescription refills though a <eb interface and receive e6mail notification of their availability for pick6up.

@otice that none of these visionary statements mentions technology (e$cept as a delivery mechanism, in the last statement". -reg is purposely keeping these early discussions focused on business strategy. Any one of )ath2s vision HbulletsH will have ma:or ramifications across the business, information, and technical architectures. ?art of -reg2s :ob will be to prioriti0e the bulleted items. 3et2s say )ath decides that her highest priority is consolidating purchasing, because this will improve profitability in the near term. -reg will soon work to turn )ath2s idea about consolidated purchasing into a common6re4uirements vision ().L". The ).L is where we will see some of the changes that will be re4uired to drive )ath2s vision for 5edA5ore. -reg will be going over the business changes with 'ret and the technical and information changes with &rma, but he will also be working to bring everybody together as a unified team. -reg will work with 'ret (the business L?" to develop a target business architecture that supports consolidated purchasing. As soon as they have spec2d out the future system, they will also look at their current architecture to see what can be recycled. -reg will work with &rma (the )&," to develop a target information architecture that allows the home office to track regional inventories and consolidate procurement. They will also work on the technical architecture for the &T systems that will support the new business architecture. After they understand the future, they will look at current architectures for opportunities to reuse e$isting technology assets. After -reg has completed the broad6brush architecture for their strategic vision, he will probably step back from the picture until the consolidated purchasing system has

been implemented. &f )ath needs help with the implementation of the architecture, she will likely look outside of -artner, because -artner does not do implementations. As soon as the implementation of consolidated purchasing has been completed, -reg will step back in to help with the ne$t iteration. (is approach will be to keep the architecture at a high level, business6focused, and hone in on details only when and where necessary. (e will continue to see his role not as creating an enterprise architecture for 5edA5ore, but helping them institute a process for allowing an enterprise architecture to emerge and evolve from the business strategy.

Comparison
As you can see, the leading enterprise6architecture methodologies are very different in their approaches. <hich one is best for your organi0ation; There is no one answer to this 4uestion. &2ll take you through the 82 criteria that & most often use for comparing and evaluating enterprise6architectural methodologies. @ot all of these criteria might be relevant to your organi0ation, and some might be more important than others. 'ut, at least, this section can serve as a starting point for your own evaluation. &2ll rank each methodology in each criteria. The ratings will be assigned as follows/

8/ >oes a very poor :ob in this area 2/ >oes an inade4uate :ob in this area / >oes an acceptable :ob in this area C/ >oes a very good :ob in this area

Neep in mind that these ratings are sub:ective. &2m sure most people would disagree with at least one of my ratings. $axonomy completeness refers to how well you can use the methodology to classify the various architectural artifacts. This is almost the entire focus of *achman. @one of the other methodologies focuses as much on this area. .atings/

*achman/ C T,-A+/ 2 +#A/ 2 -artner/ 8

+rocess completeness refers to how fully the methodology guides you through a step6 by6step process for creating an enterprise architecture. This is almost the entire focus of T,-A+, with its Architecture >evelopment 5ethod (A>5". .atings/

*achman/ 8 T,-A+/ C +#A/ 2 -artner/

%eference-model guidance refers to how useful the methodology is in helping you build a relevant set of reference models. This is almost the entire focus of +#A.

T,-A+ also provides support1 however, & am less impressed with the T,-A+ reference models. .atings/

*achman/ 8 T,-A+/ +#A/ C -artner/ 8

+ractice guidance refers to how much the methodology helps you assimilate the mindset of enterprise architecture into your organi0ation and develop a culture in which it is valued and used. This is a primary focus of -artner2s architectural practice. .atings/

*achman/ 8 T,-A+/ 2 +#A/ 2 -artner/ C

Maturity model refers to how much guidance the methodology gives you in assessing the effectiveness and maturity of different organi0ations within your enterprise in using enterprise architecture. .atings/

*achman/ 8 T,-A+/ 8 +#A/ -artner/ 2

Business focus refers to whether the methodology will focus on using technology to drive business value, in which business value is specifically defined as either reduced e$penses and9or increased income. .atings/

*achman/ 8 T,-A+/ 2 +#A/ 8 -artner/ C

-overnance guidance refers to how much help the methodology will be in understanding and creating an effective governance model for enterprise architecture. .atings/

*achman/ 8 T,-A+/ 2 +#A/ -artner/

+artitioning guidance refers to how well the methodology will guide you into effective autonomous partitions of the enterprise, which is an important approach to managing comple$ity. .atings/

*achman/ 8 T,-A+/ 2 +#A/ C -artner/

+rescriptive catalog refers to how well the methodology guides you in setting up a catalogue of architectural assets that can be reused in future activities. .atings

*achman/ 8 T,-A+/ 2 +#A/ C -artner/ 2

.endor neutrality refers to how likely you are to get locked6in to a specific consulting organi0ation by adopting this methodology. A high rating here indicates low vendor lock6in. .atings/

*achman/ 2 T,-A+/ C +#A/ -artner/ 8

Information availability refers to the amount and 4uality of free or ine$pensive information about this methodology. .atings/

*achman/ 2 T,-A+/ C +#A/ 2 -artner/ 8

$ime to value refers to the length of time you will likely be using this methodology before you start using it to build solutions that deliver high business value. .atings/

*achman/ 8 T,-A+/ +#A/ 8 -artner/ C

The criteria and ratings are summari0ed in +igure 80.

Figure "=# Criteria and ratings for each methodology ,ne of the important points of +igure 80 is that none of the enterprise6architecture methodologies is really complete. #ach has its strengths and weaknesses. (ow do you choose which methodology is best for you; (ere is my recommended approach/ 8. -o through the rows (criteria" in +igure 80, eliminating any that you feel are not important to your organi0ation. 2. Add any additional rows (criteria" that you feel are important, and rate each of the methodologies in that area. . )hange any of my ratings with which you disagree. At the end of this e$ercise, you should have a good idea about the strengths and weaknesses of each methodology with respect to your enterprise2s needs. &f a clear winner emerges, count yourself lucky. +ind a consultant who speciali0es in helping enterprises implement that methodology, and go for it. +or many organi0ations, there will be no clear winner. +or such organi0ations, & recommend you use a blended approach, in which you create your own enterprise6 architectural methodology consisting of bits and pieces of each of the methodologies that provide the highest value in your specific areas of concern. Aou will want a different kind of consultantone who has a broad perspective of all of these methodologies and speciali0es in helping enterprises create a methodology that works best, given the specific needs and political realities of that enterprise.

Conclusion
This paper has covered a broad introduction to the field of enterprise architecture. The history of the field goes back 20 years, but the field is still evolvingand rapidly so. Two of the four ma:or methodologies (-artner and +#A" have undergone ma:or changes in the last two years alone. As & have shown, these methodologies are 4uite different from each other, both in goals and in approach. This is good news and bad. &t is bad news, in that it increases the difficulty for many organi0ations in choosing one single enterprise6architectural methodology. (ow do you choose between methodologies that have so little in common; )hoosing between *achman and T,-A+, for e$ample, is like choosing between spinach and hammers. 'ut the good news is that these methodologies can be seen as complementing each other. +or many organi0ations, the best choice is all of these methodologies, blended together in a way that works well within that organi0ation2s constraints. This white paper should provide a good starting place for understanding the value of each of these methodologies and how they can complement each other. <hichever route you choose, remember that enterprise architecture is a path, not a destination. An enterprise architecture has no value unless it delivers real business value as 4uickly as possible. ,ne of the most important goals of any enterprise architecture is to bring the business side and the technology sides together, so that both are working effectively toward the same goals. &n many organi0ations, there is a culture of distrust between the technology and business folks. @o enterprise6architecture methodology can bridge this divide unless there is a genuine commitment to change. $hat commitment must come from the highest level of the organi#ation/ 5ethodologies cannot solve people problems1 they can only provide a framework in which those problems can be solved. 'ut, as soon as you have that commitment to change, an enterprise6architecture methodology can be a valuable tool for guiding that change. This change can manifest itself in many ways. %ome of the predicted benefits from a successfully implemented enterprise architectural include/

&mprovements in using &T to drive business adaptability. )loser partnership between business and &T groups. &mproved focus on organi0ational goals. &mproved morale, as more individuals see a direct correlation between their work and the organi0ation2s success. .educed numbers of failed &T systems. .educed comple$ity of e$isting &T systems. &mproved agility of new &T systems. )loser alignment between &T deliverables and business re4uirements.

&t is obvious that an organi0ation that does well in these key areas will be more successful than one that doesn2t. This is true regardless of whether success is

measured with tangibles, such as profitability and return on investment, or intangibles, such as customer satisfaction and employee turnover. The starting point for any enterprise architecture is some critical self6analysis. >oes your organi0ation spend too much money building &T systems that deliver inade4uate business value; &s &T seen as improving or hampering business agility; &s there a growing divide between your business and &T folks; And, finally, perhaps the most important 4uestion of all/ &s your organi0ation truly committed to solving these problems, and does that commitment come from the highest levels of the organi0ation; &f the answer to all of these 4uestions is Hyes,H enterprise architecture is your path. &t2s up to you to take that ne$t step.

2lossary

A6M 3Architecture 6evelopment Method4A process for creating an enterprise architecture that is part of the T,-A+ standard. application architectureThe architecture of a specific application. architect,ne whose responsibility is the design of an architecture and the creation of an architectural description. architectural artifactA specific document, report, analysis, model, or other tangible that contributes to an architectural description. architectural descriptionA collection of products (artifacts" to document an architecture. architectural frame'or+A skeletal structure that defines suggested architectural artifacts, describes how those artifacts are related to each other, and provides generic definitions for what those artifacts might look like. architectural methodologyA generic term that can describe any structured approach to solving some or all of the problems related to architecture. architectural processA defined series of actions directed to the goal of producing either an architecture or an architectural description. architectural taxonomyA methodology for organi0ing and categori0ing architectural artifacts. architectureThe fundamental organi0ation of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution (from &###68C=862000". usiness architectureAn architecture that deals specifically with business processes and business flow. usiness reference model 3,:M4An +#A term that gives a business view of the various functions of the federal government. usiness services segmentAn +#A term that refers to a segment that is foundational to most, if not all, political organi0ations, such as financial management. C!1)hief &nformation ,fficer, the e$ecutive in charge of information technology in a corporation. C!1 CouncilA council consisting of )&,s from each of the federal governmental agencies that coordinates work related to common interests. Clinger-Cohen Act of "<<7%ee Information $echnology Management %eform ct.

common-systems architecturesA T,-A+ term referring to an architecture that is common to many (but not all" types of enterprises, in contrast to foundation architectures and industry architectures. component reference model 3C:M4An +#A term that gives an &T view of systems that support business functionality. data architectureThe architecture of the data (typically stored in databases" owned by the enterprise. enterprise architectAn architect who speciali0es in enterprise architectures. enterprise architectureAn architecture in which the system in 4uestion is the whole enterprise, especially the business processes, technologies, and information systems of the enterprise. enterprise serviceAn +#A term referring to a well6defined function that spans political boundaries, such as security management. FEA%ee Federal 0nterprise rchitecture (F0 ). FEAF%ee Federal 0nterprise rchitectural Framework (F0 F). FEAPM1The organi0ation within the ,5' that owns and administers the +ederal #nterprise Architecture. Federal Architecture Program EA Assessment Frame'or+A benchmark used by the ,5' to measure the effectiveness of governmental bodies in using enterprise architecture. Federal Enterprise Architectural Frame'or+ 3FEAF4An enterprise6 architectural framework used by the K.%. federal government to describe how the various governmental agencies and their &T systems are related to each other. Federal Enterprise Architecture 3FEA4An architectural description of the enterprise architecture of the K.%. federal government that includes various reference models, processes for creating organi0ational architectures that fit in with the federal enterprise architecture, and a methodology for measuring the success of an organi0ation in using enterprise architectures. foundation architectureA term used by T,-A+ to refer to the most generic of architectures that can be used by any &T organi0ation, in contrast to common systems architectures. 2A1%ee -eneral ccountability "ffice (- ")/ 2artnerAn &T research and advisory organi0ation. gate'ayA transfer point of an autonomous system from which messages from the outside world are received or through which messages to the outside world are sent. 2eneral Accounta ility 1ffice 32A14A branch of the K.%. -overnment that is responsible for monitoring the effectiveness of different organi0ations within the K.%. -overnment. industry architectureA T,-A+ term that refers to a architecture that is common to most enterprises within an industry, in contrast to a commonsystems architecture and an organi#ational architecture. !nformation Technology Management :eform ActAn act passed by the K.%. )ongress in 877! that re4uires all governmental organi0ations to use effective strategies and frameworks for developing and maintaining &T resources.

1M, 31ffice of Management and ,udget4?art of the #$ecutive ,ffice of the ?resident of the K.%. that serves the function of presidential oversight on federal agencies. The 1pen 2roup Architectural Frame'or+%ee $"- F ($he "pen -roup rchitectural Framework) 1/2. organi>ational architectureA T,-A+ term that applies to an architecture that is specific to a particular organi0ation, in contrast to an industry architecture. performance reference model 3P:M4An +#A term that gives standard ways of describing terms related to measuring value. :eturn on !nvestment 3:1!4A measure (in percent" of the business value of a pro:ect, based on the increase in profit (either because of increased income or decreased e$penses" divided by the cost of the pro:ect. +or e$ample, a pro:ect with a cost of P800,000 that returned P200,000 in increased profit has an .,& of 200 percent. :1!%ee %eturn on Investment (%"I). segmentAn +#A term that refers to a ma:or line6of6business functionality, such as human resources, that might be shared across organi0ations. standards information ase 3S!,4A T,-A+ term that refers to a collection of information about standards, particularly in the area of open6 source. TAF!M 3Technical Architecture Frame'or+ for !nformation Management4An architectural framework developed by the >epartment of >efense and officially discontinued in 2000. technical architectureKsually refers to the architecture of the technical infrastructure within which applications run and interact. technical reference model 3T:M4?art of T,-A+, a reference model that gives a common language for various pieces of &T architecture. This term is also used for a similar meaning within F0 . T12AF 3The 1pen 2roup Architectural Frame'or+4 9#"An architectural methodology that is controlled by The ,pen -roup. /achman Frame'or+ for Enterprise ArchitecturesAn architectural framework in which an enterprise is modeled as 0 or ! cells, each of which represents an intersection between a stakeholder perspective and an abstraction.

:eferences

E08F &### %tandard 8C=862000/ &### .ecommended ?ractice for Architectural >escription of %oftware6&ntensive %ystems. E02F *achman, I.A. HA +ramework for &nformation %ystems Architecture.H IBM Systems Journal, Lolume 2!, @umber , 87G=. E0 F K.%. >epartment of >efense. $echnical rchitecture Framework for Information Management ($ FIM) .olumes 2-1. Lersion 2.0. .eston, LA/ >&%A )enter for Architecture, 877C. E0CF )linger6)ohen Act of 877! (?3 80=6 C=" (%ee T(,5A% (3ibrary of )ongress"." E0JF The )hief &nformation ,fficers )ouncil A0C. Federal 0nterprise rchitecture Framework .ersion 2/2. %eptember 8777.

E0!F &nformation Technology/ The +ederal #nterprise Architecture and Agencies2 #nterprise Architectures Are %till 5aturing, -A, Testimony 'efore the %ubcommittee on Technology, &nformation ?olicy, &ntergovernmental .elations and the )ensus, )ommittee on -overnment .eform, (ouse of .epresentatives. 5ay 87, 200C. E0=F &nformation Technology/ +'& &s Taking %teps to >evelop an #nterprise Architecture, but 5uch .emains to 'e Accomplished. -A,60J6 ! . %eptember 7, 200J. E0GF >,> 'usiness %ystems 5oderni0ation/ 3ong6%tanding <eaknesses in #nterprise6Architecture >evelopment @eed to 'e Addressed. -A,60J6=02. Iuly 22, 200J E07F (omeland %ecurity/ ?rogress )ontinues, but )hallenges .emain on >epartment2s 5anagement of &nformation Technology, Testimony 'efore )ongressional %ubcommittees, .andolph ). (ite, >irector, &nformation Technology Architecture and %ystems &ssues. -A,. 5arch 27, 200! E80F 'usiness 5oderni0ation/ %ome ?rogress 5ade Toward &mplementing -A, .ecommendations .elated to @A%A2s &ntegrated +inancial 5anagement ?rogram. -A,60J6=77.. %eptember 7, 200J E88F HframeworkH. $he merican *eritage ,ictionary of the 0nglish 3anguage. +ourth #dition. 'oston, 5A/ (oughton 5ifflin )ompany, 200!. E82F Hta$onomyH. $he merican *eritage ,ictionary of the 0nglish 3anguage. +ourth #dition. 'oston, 5A/ (oughton 5ifflin )ompany, 200!. E8 F *achman, Iohn A. HThe +ramework for #nterprise Architecture/ 'ackground, >escription and Ktility.H *achman &nstitute for +ramework Advancement (*&+A". >ocument &>/ G8062 860J 8 E8CF ,2.ourke, )arol, @eal +ishman, and <arren %elkow. 0nterprise rchitecture 4sing the 5achman Framework. 'oston, 5A/ )ourse Technology, 200 . &%'@/ 06!8760!CC!6 E8JF &nterview with Iohn *achman by .oger %essions, #ditor6in6)hief, in +erspectives of the International ssociation of Software rchitects, &ssue !. E8!F *achman, I.A. HA +ramework for &nformation %ystems Architecture.H IBM Systems Journal, Lolume 2!, @umber , 87G=. E8=F *achman, I.A., and I.+. %owa. H#$tending and +ormali0ing the +ramework for &nformation %ystems Architecture.H IBM Systems Journal, Lolume 8, @umber , 8772. E8GF *achman, I.A. HA +ramework for &nformation %ystems Architecture.H IBM Systems Journal, Lolume 2!, @umber , 87G=. E87F www.opengroup.org E20F www.opengroup.org9togaf E28F ?erks, )ol, and Tony 'everidge. -uide to 0nterprise I$ rchitecture. @ew Aork, @A/ %pringer, 200 . &%'@/ 06 G=67J8 26! E22F www.opengroup.org9togaf9cert E2 F ?erks, )ol, and Tony 'everidge. -uide to 0nterprise I$ rchitecture. @ew Aork, @A/ %pringer, 200 . &%'@/ 06 G=67J8 26! E2CF T,-A+ Lersion G.8.8. E2JF H+#A )onsolidated .eference 5odel >ocument Lersion 2.8,H >ecember 200!, published by the +ederal #nterprise Architecture ?rogram 5anagement ,ffice, ,ffice of 5anagement of 'udget. E2!F A ?ractical -uide to +ederal #nterprise Architecture by the )&, )ouncil, Lersion 8.0, +ebruary 2008.

E2=F H+#A ?ractice -uidance,H >ecember 200!, published by the +ederal #nterprise Architecture ?rogram 5anagement ,ffice, ,ffice of 5anagement of 'udget. E2GF H+#A )onsolidated .eference 5odel >ocument Lersion 2.8,H >ecember 200!, published by the +ederal #nterprise Architecture ?rogram 5anagement ,ffice, ,ffice of 5anagement of 'udget. E27F &bid. E 0F &bid. E 8F &bid. E 2F HThe >ata .eference 5odel, Lersion 2.0,H @ovember 200J, published by the +ederal #nterprise Architecture ?rogram 5anagement ,ffice, ,ffice of 5anagement of 'udget. E F H+#A )onsolidated .eference 5odel >ocument Lersion 2.8,H >ecember 200!, published by the +ederal #nterprise Architecture ?rogram 5anagement ,ffice, ,ffice of 5anagement of 'udget. E CF H+#A ?ractice -uidance,H >ecember 200!, published by the +ederal #nterprise Architecture ?rogram 5anagement ,ffice, ,ffice of 5anagement of 'udget. E JF +ederal #nterprise Architecture ?rogram #A Assessment +ramework 2.8, >ecember 200!. E JF &bid. E !F 'ittler, .. %cott, and -regg Nrei0man. H-artner #nterprise Architecture ?rocess/ #volution 200J.H ,ctober 28, 200J. -artner &>/ -008 0GC7 E =F Iames, -reta A., .obert A. (andler, Anne 3apkin, and @icholas -all. H-artner #nterprise Architecture +ramework/ #volution 200J.H ,ctober 2J, 200J. -artner &>/ -008 0GJJ

A out the author .oger %essions is the )T, of ,b:ect<atch. (is ,b:ect<atch @ewsletter is now in its 8 th year of publication. (e has written si$ books, including Software Fortresses6 Modeling 0nterprise rchitectures (Addison6<esley, 200 ", and many articles. (e is on the 'oard of >irectors of the &nternational Association of %oftware Architects (&A%A", is #ditor6in6)hief of ?erspectives of the &nternational Association of %oftware Architects, and is a 5icrosoft6recogni0ed 5L? in #nterprise Architecture. .oger holds multiple patents in both software and enterprise6architecture process. (e has given talks at more than 800 conferences around the world, covering a wide range of topics in enterprise architecture. 3earn more about .oger %essions and ,b:ect<atch at www.ob:ectwatch.com. Q 208 5icrosoft. All rights reserved.

C0