A Comparison of the Top Four Enterprise-Architecture Methodologies - The Diigo Meta page

• 13 Dec 14
  

  kkkugan

  ea practice msdn

• 02 Dec 14
  

  Lorenzo Manzoni

  EA principles framework zachman togaf

• 07 Nov 14
  

  dianapenciuc
  • perhaps 90 percent of the field use one of these four methodologies:
  • 
• 24 Oct 14
  

  Stewart McGill
  • 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.
• 12 Oct 14
  

  an88zi

  useful comparison of systems building methodologies системообразующие методологии

  framework architecture methodology comparison information architecture

  • The problem, of course, is that James comes from England, where what I call a flashlight they call a torch.
  • practice
  • practice
  • my use of the word
  • Architecture is a verb, not a noun.

  3 more annotations...

• 11 Sep 14
  

  bottledblues
  • The cost and complexity of IT systems have exponentially increased, while the chances of deriving real value from those systems have dramatically decreased.
  • This white paper discusses these four approaches to enterprise architecture. It does so within the context of a fictional company that is facing some very nonfictional operations problems. These problems include:
  • When examining each of these methodologies in depth, one is struck by the fact that none of these approaches is really complete. Each has strengths in some areas and weaknesses in others.
  • • The Zachman Framework for Enterprise Architectures—Although self-described as a framework, is actually more accurately defined as a taxonomy
      
    • The Open Group Architectural Framework (TOGAF)—Although called a framework, is actually more accurately defined as a process
  • That promise hasn't changed: reducing IT cost and complexity, while increasing business value and effectiveness—or, to put it even more simply, improving your competitiveness in an increasingly competitive world.
  • This field was inaugurated to address two major problems in information technology (IT) that were then already becoming apparent. The first problem was managing the increasing complexity of information-technology systems. The second problem was the increasing difficulty in delivering real business value with those systems.

  4 more annotations...

• 12 Aug 14
  

  ilycom

  • 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—Organizations were spending more and more money building IT systems; and
      
    • Poor business alignment—Organizations were finding it more and more difficult to keep those increasingly expensive IT systems aligned with business need.
  • • The Zachman Framework for Enterprise Architectures—Although self-described as a framework, is actually more accurately defined as a taxonomy
      
    • The Open Group Architectural Framework (TOGAF)—Although called a framework, is actually more accurately defined as a process
      
    • The Federal Enterprise Architecture—Can be viewed as either an implemented enterprise architecture or a proscriptive methodology for creating an enterprise architecture
      
    • The Gartner Methodology—Can be best described as an enterprise architectural practice
  • • IT systems that have become unmanageably complex and increasingly costly to maintain.
      
    • IT systems that are hindering the organization's ability to respond to current, and future, market conditions in a timely and cost-effective manner.
      
    • Mission-critical information that is consistently out-of-date and/or just plain wrong.
      
    • A culture of distrust between the business and technology sides of the organization.
  • This field was inaugurated to address two major problems in information technology (IT) that were then already becoming apparent. The first problem was managing the increasing complexity of information-technology systems. The second problem was the increasing difficulty in delivering real business value with those systems.
  • The relationship between complexity and planning for buildings and cities is similar for information systems. If you are building a simple, single-user, nondistributed system, you might need no architects at all. If you are building an enterprise-wide, 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 is the architect's architect, the architect who is responsible for coordinating the work of all of the other architects. Do you need such an architect? It all depends on what you are building: Thoreau's cabin or New York City.
  • Building a large, complex, enterprise-wide information system without an enterprise architect is like trying to build a city without a city planner. Can you build a city without a city planner? Probably. Would you want to live in such a city? Probably not.
  • Of course, hiring a city planner does not guarantee a livable city; it merely improves your chances.

  • architectural artifact—A specific document, report, analysis, model, or other tangible that contributes to an architectural description

      

    architectural description*—A collection of products (artifacts) to document an architecture
  • architectural taxonomy—A methodology for organizing and categorizing architectural artifacts
  • architecture*—The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution
  • Clinger-Cohen Act of 1996 [04], also known as the Information Technology Management Reform Act, which mandated that all federal agencies take steps to improve the effectiveness of their IT investments. A CIO Council, consisting of CIOs from all major governmental bodies, was created to oversee this effort.
  • In April 1998, the CIO Council began work on its first major project, the Federal Enterprise Architecture Framework (FEAF).
  • MAM incorporated some innovate business ideas, such as patient-relationship management, inventory management, automated insurance billing, and even utility optimization.
  • MAM consisted of three programs: MAM/Store, which ran on a small computer at a drug store; MAM/Warehouse, which ran on a server in a regional warehouse; and MAM/Home, which ran on a large server at the home office.
  • These three programs communicated through files that were transferred from one location (for example, a store) to another (for example, a regional warehouse). When reliable communications lines existed, file transfers could occur through FTP. The system was also flexible enough to accommodate transfers through courier, where necessary.
  • Some of the problems MedAMore was running into were the following:
  • MAM/Store required regional specializations. For example, different insurance plans needed to be supported in different regions, and these all required changes to the MAM/Store module.
  • The regional warehouses that had been acquired through acquisition each had different ways of receiving orders from the retail stores and different procedures from ordering supplies from the wholesalers.
  • The file-transfer approach to information sharing that had worked so well when MedAMore consisted of 30 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. Files were often delivered late, sometimes not at all, and occasionally multiple times. This made it difficult for the home office to access reliable, up-to-date financial information, especially in the areas of sales and inventory.
  • The modules had grown to over 1 million lines of code each. It 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. Changing even a single line of code required a rebuild of the entire multimillion-line module.
  • The business side of MedAMore wanted to acquire two more regional chains, but IT was still struggling to bring the existing acquisitions online.
  • The technical side saw the business side as making impossible demands and blamed it for refusing to consult IT before entering into acquisition discussions.
  • The business side saw IT as reducing business agility.
  • The distrust had reached such a point that, by 2005, the CIO was no longer considered part of the executive team of MedAMore
  • At a CEO 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 cost-effective IT systems that enabled business agility.
  • MedAMore-Enterprise Architecture, or MAM-EA. After it was completed, MAM-EA would drive all new IT investment and ensure that every dollar invested in IT was delivering the maximum value to the business.
  • The Zachman "Framework" is actually a taxonomy for organizing architectural artifacts (in other words, design documents, specifications, and models) that takes into account both who the artifact targets (for example, business owner and builder) and what particular issue (for example, data and functionality) is being addressed.
  • For a physical building, some of these players are the owner (who is paying for the project), the builder (who is coordinating the overall construction), and a zoning board (who is ensuring that construction follows local building regulations).
  • A building architect prepares different artifacts for each of these players. Every 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 doesn't care about the placement of studs in the walls. The builder doesn't care how the bedroom windows line up with the morning sun.
  • there are 36 intersecting cells in a Zachman grid—one for each meeting point between a player's perspective (for example, business owner) and a descriptive focus (for example, data.). As we move horizontally (for example, left to right) in the grid, we see different descriptions of the system—all from the same player's perspective. As we move vertically in the grid (for example, top to bottom), we see a single focus, but change the player from whose perspective we are viewing that focus.
  • For example, artifacts relating to a service-oriented architecture live mostly in the third row (designer's perspective). They generally will not be of interest to the business owner (Bret, in the MedAMore case study).
  • So, MedAMore can use the Zachman grid to ensure that appropriate discussions are occurring between all of the important stakeholders of MAM-EA.
  • Consider, for example, the data column (the first column) of the Zachman grid. From the business owner's (Bret's) perspective, data is information about the business. From the database administrator's perspective, data is rows and columns in the database.
  • While the business owner thinks about data quite differently from the database administrator, there should be some relationship between these perspectives. Somebody should be able to follow Bret's business requirements and show that the database design is, in fact, being driven by those requirements. If Bret has requirements that are not traceable down to the database design, we must ask if the business needs will be met by this architecture. On the other hand, it there are database-design elements that do not trace back to business requirements, we might ask if we have included unnecessary design at the database level.

  • Zachman grid can help in the development of MAM-EA. It can help:  

     
    1. Ensure that every stakeholder's perspective has been considered for every descriptive focal point.
  • Ensure that all of Bret's business requirements can be traced down to some technical implementation.
  • Convince Bret that Irma's technical team isn't planning on building a bunch of useless functionality.
  • Zachman does not give us a step-by-step process for creating a new architecture.
  • TOGAF describes itself as a "framework," but the most important part of TOGAF is the Architecture Development Method, better known as ADM. ADM is a recipe for creating architecture. A recipe can be categorized as a process. Given that ADM is the most visible part of TOGAF, I categorize TOGAF overall as an architectural process, instead of either an architectural framework (as The Open Group describes TOGAF) or a methodology (as it describes ADM).
  • Zachman tells you how to categorize your artifacts. TOGAF gives you a process for creating them.
  • TOGAF views the world of enterprise architecture as a continuum of architectures, ranging from highly generic to highly specific.
  • It views the process of creating a specific enterprise architecture, such as MAM-EA, as moving from the generic to the specific. TOGAF's ADM provides a process for driving this movement from the generic to the specific.
  • TOGAF calls most generic architectures Foundation Architectures. These are architectural principles that can, theoretically, be used by any IT organization in the universe.
  • TOGAF defines the various knowledge bases that live in the Foundation Architecture. Two that you might run into are the Technical Reference Model (TRM) and the Standards Information Base (SIB). The TRM is a suggested description of a generic IT architecture. The SIB is a collection of standards and pseudo-standards that The Open Group recommends that you consider in building an IT architecture.
  • There is probably more free and inexpensive available information about TOGAF than about all other architectural methodologies combined.

  • Her three goals in the preliminary phase are to:  

     
    1. Make sure everybody is comfortable with the process.
      
    2. Modify the TOGAF process, as necessary, to fit within the MedAMore culture.
      
    3. Set up the governance system that will oversee future architectural work at MedAMore.
  • Teri will work closely with Bret to understand the business philosophy, business models, and strategic drivers of MedAMore. She will work closely with Irma to define the architectural principles that drive technological architectures at MedAMore and document those principles using the TOGAF-recommended format.
  • The effort is not driven by IT, but is driven by Cath, the CEO. This gives the project high visibility and creates a positive incentive for cooperation from all sides.
  • Phase A begins, at least in theory, with a Request for Architecture Work from some organization within MedAMore. This document includes the business reasons for the request, budget and personnel information, and any constraints that need to be considered
  • Phase A
  • define the scope of the project, identify constraints, document the business requirements, and establish high-level definitions for both the baseline (starting) architecture and target (desired) architecture.
  • The culmination of Phase A will be a Statement of Architecture Work, which must be approved by the various stakeholders before the next phase of the ADM begins.
  • Phase B is to create a detailed baseline and target business architecture and perform a full analysis of the gaps between them. She will work primarily with Bret (or Bret's team) to achieve this.
  • Phase D completes the technical architecture—the infrastructure necessary to support the proposed new architecture. This phase is completed mostly by engaging with Irma's technical team.
  • Phase E evaluates the various implementation possibilities, identifies the major implementation projects that might be undertaken, and evaluates the business opportunity associated with each. The TOGAF standard recommends that Teri's first pass at Phase E "focus on projects that will deliver short-term payoffs and so create an impetus for proceeding with longer-term projects."
  • This is good advice in any architectural methodology. Therefore, Teri should be looking for projects that can be completed as cheaply as possible, while delivering the highest perceived value. A good starting place to look for such projects is the organizational pain-points that initially convinced Cath (the MedAMore CEO) to adopt an enterprise architectural-based strategy in the first place. These pain-points, described earlier, included difficulties in completing regional/warehouse specialization and unreliability in data sharing.
  • Phase F is closely related to Phase E. In this phase, Teri works with MedAMore's governance body to sort the projects identified in Phase E into priority order that include not only the cost and benefits (identified in Phase E), but also the risk factors.
  • In Phase G, Teri takes the prioritized list of projects and creates architectural specifications for the implementation projects. These specifications will include acceptance criteria and lists of risks and issues.
  • TOGAF merely describes how to generate an enterprise architecture, not necessarily how to generate a good enterprise architecture.
  • ...a common language and framework to describe and analyze IT investments, enhance collaboration and ultimately transform the Federal government into a citizen-centered, results-oriented, and market-based organization as set forth in the President's Management Agenda.
  • The FEA Perspective on EA is that an enterprise is built of segments, an idea first introduced by FEAF [26]. A segment is a major line-of-business functionality, such as human resources. There are two types of segments: core mission-area segments and business-services segments.
  • he 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. Figure 9, for example, shows my own interpretation of the OMB maturity rankings for architectural completion, as I adapt them for the private sector. Similar adaptations can be created for architectural usage and architectural results.
  • Gartner believes that enterprise architecture is about bringing together three constituents: business owners, information specialists, the technology implementers. If you can bring these three groups together and unify them behind a common vision that drives business value, you have succeeded; if not, you have failed. Success is measured in pragmatic terms, such as driving profitability, not by checking off items on a process matrix.
  • Gartner believes that the enterprise architectures must start with where an organization is going, not with where it is. If we are going to clean house, we don't need to exhaustively document everything we are throwing out. Let's 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.
  • Gartner recommends that an organization begin by telling the story of where its strategic direction is heading and what the business drivers are to which it is responding. Gartner will want this story in plain language, without worrying about prescribed documentation standards, acronyms, or techno-babble. The only goal is making sure that everybody understands and shares a single vision.
  • Enterprise architecture, in the Gartner view, is about strategy, not about engineering. It is focused on the destination. The two things that are most important to Gartner are where an organization is going and how it will get there. Any architectural activity that is extraneous to these questions is irrelevant.
  • specify her vision in business terms and resist any temptation to discuss technology.
  • MedAMore will have stores in at least 30 states, spread out over 8 geographic regions, by the year 2010. It will accomplish this mainly through acquisition of regional pharmacies.
  • MedAMore will be able to assimilate new regional systems within 120 days of finalization of purchase.
  • MedAMore's 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.
  • MedAMore will be able to invoice insurance companies by the end of the day on which the prescription was delivered to the patient.
  • Patients will be able to request prescription refills though a Web interface and receive e-mail notification of their availability for pick-up
  • After they understand the future, they will look at current architectures for opportunities to reuse existing technology assets.
  • Practice guidance refers to how much the methodology helps you assimilate the mindset of enterprise architecture into your organization and develop a culture in which it is valued and used. This is a primary focus of Gartner's architectural practice
  • One 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.
  • Whichever 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 quickly as possible
  • In many organizations, there is a culture of distrust between the technology and business folks. No enterprise-architecture methodology can bridge this divide unless there is a genuine commitment to change. That commitment must come from the highest level of the organization. Methodologies cannot solve people problems; they can only provide a framework in which those problems can be solved.
  • perhaps the most important question of all: Is your organization truly committed to solving these problems, and does that commitment come from the highest levels of the organization?
  • • architectural methodology—A generic term that can describe any structured approach to solving some or all of the problems related to architecture.
      
    • architectural process—A defined series of actions directed to the goal of producing either an architecture or an architectural description.
  • Gartner—An IT research and advisory organization.
  • segment—An FEA term that refers to a major line-of-business functionality, such as human resources, that might be shared across organizations
  • technical reference model (TRM)—Part of TOGAF, a reference model that gives a common language for various pieces of IT architecture. This term is also used for a similar meaning within FEA.
  • TOGAF (The Open Group Architectural Framework) 8.1—An architectural methodology that is controlled by The Open Group.

  82 more annotations...

• 16 Jun 14
  

  Stuart Bridge

  "taxonomy"

  enterprise-architecture IT

• 16 May 14
  

  Johann Höchtl

  governance framework government enterprise

• 31 Mar 14
  

  Michiel Perdeck

  enterprise architecture enterprise-architecture zachman togaf

• 20 Mar 14
  

  mohitbahl
• 02 Mar 14
  

  Volkan Güney

  "methodologies"

  EA Microsoft blended

• 30 Nov 13
  

  heycorey
• 10 Sep 13
  
• 07 Sep 13
  

  Giovanni Lofrumento

  EnterpriseArchitecture

• 09 Jul 13
  

  Philip Guth

  article zachman enterprise architecture togaf

  • Zachman's vision was that business value and agility could best be realized by a holistic approach to systems architecture that explicitly looked at every important issue from every important perspective. His multiperspective approach to architecting systems is what Zachman originally described as an information systems architectural framework and soon renamed to be an enterprise-architecture framework.
• 27 Jun 13
  

  davedubya

  EnterpriseArchitecture

• 13 Jun 13
  
• 17 May 13
  

  R.C. Iwabuchi

  TI CHERD

• 13 May 13
  

  Toni Dorta

  curiosidades

• 24 Apr 13
  

  rstarmach

  architecture comparison togaf zachman enterprise architecture ea

• 13 Jan 13
  

  Pradyumn Sharma

  "Many enterprise-architectural methodologies have come and gone in the last 20 years. At this point, perhaps 90 percent of the field use one of these four methodologies:
  The Zachman Framework for Enterprise Architectures—Although self-described as a framework, is actually more accurately defined as a taxonomy
  The Open Group Architectural Framework (TOGAF)—Although called a framework, is actually more accurately defined as a process
  The Federal Enterprise Architecture—Can be viewed as either an implemented enterprise architecture or a proscriptive methodology for creating an enterprise architecture
  The Gartner Methodology—Can be best described as an enterprise architectural practice"

  enterprise architecture

• 08 Jan 13
  

  rodriguezringach

  enterprise architecture methodology

• 19 Dec 12
  

  David Mir

  togaf architecture zachman enterprise-architecture framework enterprise ea enterprise architecture

• 14 Dec 12
  

  Rolien Thalen

  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—Organizations were spending more and more money building IT systems; and
  Poor business alignment—Organizations were finding it more and more difficult to keep those increasingly expensive IT systems aligned with business need.
  
  The bottom line: more cost, less value. These problems, first recognized 20 years ago, have today reached a crisis point. The cost and complexity of IT systems have exponentially increased, while the chances of deriving real value from those systems have dramatically decreased.
  
  Today's bottom line: even more cost, even less value. Large organizations can no longer afford to ignore these problems. The field of enterprise architecture that 20 years ago seemed quaintly quixotic today seems powerfully prophetic.
  
  Many enterprise-architectural methodologies have come and gone in the last 20 years. At this point, perhaps 90 percent of the field use one of these four methodologies:
  
  The Zachman Framework for Enterprise Architectures—Although self-described as a framework, is actually more accurately defined as a taxonomy
  The Open Group Architectural Framework (TOGAF)—Although called a framework, is actually more accurately defined as a process
  The Federal Enterprise Architecture—Can be viewed as either an implemented enterprise architecture or a proscriptive methodology for creating an enterprise architecture
  The Gartner Methodology—Can be best described as an enterprise architectural practice
  
  This white paper discusses these four approaches to enterprise architecture. It does so within the context of a fictional company that is facing some very nonfictional operations problems. These problems include:
  
  IT systems that have become unmanageably complex and increasingly costly to maintain.
  IT systems that are hindering the organization's ability to respond to current, and future, market conditions in a timely and cost-effective manner.
  Mission-critical information that is consistently out-of-date and/or just plain wrong.
  A culture of distrust between the business and technology sides of the organization.
  
  How should this company choose from among these four very different approaches to enterprise architecture? This white paper traces the journey the company is likely to face in using any one of these methodologies.
  
  When examining each of these methodologies in depth, one is struck by the fact that none of these approaches is really complete. Each has strengths in some areas and weaknesses in others.
  
  For many enterprises, none of these methodologies will therefore be a complete solution. For such organizations, this white paper proposes another approach, one that might be called a blended methodology. Choose bits and pieces from each of these methodologies, and modify and merge them according to the specific needs of your organization. This white paper gives an approach to creating such a blended methodology that is a best fit for your organization's needs. May 2007

  IT 2007 Architecture Enterprise Architecture 5-stars

• 12 Dec 12
  

  learnngetbetter

  architecture

• 09 Dec 12
  

  Cloud Rains

  EnterpriseArchitecture

• 24 Sep 12
  

  Cameron Stewart

  zachman enterprise architecture delicous

• 10 Aug 12
  

  ianmac50

  togaf

• 10 Jun 12
  

  Beth Giles

  enterprise architecture

• 19 Apr 12
  

  mostafa yazdanifard

  enterprise-architecture articles Reference

  • As I have shown, these methodologies are quite different from each other, both in goals and in approach. This is good news and bad. It is bad news, in that it increases the difficulty for many organizations in choosing one single enterprise-architectural methodology. How do you choose between methodologies that have so little in common? Choosing between Zachman and TOGAF, for example, is like choosing between spinach and hammers.

      

    But the good news is that these methodologies can be seen as complementing each other. For many organizations, the best choice is all of these methodologies, blended together in a way that works well within that organization's 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.
• 03 Apr 12
  

  Joe Sabado

  blog_ea

• 29 Mar 12
  

  Irene Finder

  Roger Sessions has creates a whitepaper on MSDN entitled "A Comparison of the Top Four Enterprise Architecture Methodologies", which provides a history of enterprise architecture approaches, followed by a comparison of the four major methodologies:
  *Zachman Framework for Enterprise Architectures
  *The Open Group Architecture Framework (TOGAF)
  *The Federal Enterprise Architecture (FEA)
  *The Garner/Meta methodology
  Rating 9.5

  Enterprise Architectuur 2007 Architectuur Rating1

• 25 Mar 12
  

  Francois-Xavier ROBERT

  zachman togaf

• 13 Mar 12
  

  Jean-Marie Favre

  enterprise architecture method model comparative linguistics comparison history evolution language visual

• 12 Mar 12
  

  deepakpradhan
  • perhaps 90 percent of the field use one of these four methodologies:
  • The Open Group Architectural Framework (TOGAF)—Although called a framework, is actually more accurately defined as a process
  • database architect, a solutions architect, an infrastructure architect, a business architect, and an enterprise architect.

  1 more annotation...

• 10 Mar 12
  

  Cory Salveson

  to-read togaf zachman architecture enterprise-architecture ea enterprise architecture framework enterprise

• 06 Mar 12
  

  Vinay R

  ea enterprise comparison zachman togaf architecture fea gartner

• 04 Feb 12
  

  Neal Enssle
  • The Zachman "Framework" is actually a taxonomy for organizing architectural artifacts
  • But Zachman by itself is not a complete solution for MedAMore. There are far too many issues that will be critical to MAM-EA's success that Zachman does not address. Zachman does not give us a step-by-step process for creating a new architecture. Zachman doesn't even give us much help in deciding if the future architecture we are creating is the best architecture possible. For that matter, Zachman doesn't even give us an approach to show a need for a future architecture. For these and other issues, we are going to need to look at other methodologies.
  • I categorize TOGAF overall as an architectural process, instead of either an architectural framework (as The Open Group describes TOGAF) or a methodology (as it describes ADM).
  • Viewed as an architectural process, TOGAF complements Zachman—which, recall, I categorized as an architectural taxonomy. Zachman tells you how to categorize your artifacts. TOGAF gives you a process for creating them.

  • TOGAF is meant to be highly adaptable, and details for the various architectural artifacts is sparse. As one book on TOGAF says:

      

     TOGAF is not wholly specific with respect to generated documents; in fact, it provides very little in the way of prescriptive document templates—merely guidelines for inputs and outputs. [23]

      

  • TOGAF allows phases to be done incompletely, skipped, combined, reordered, or reshaped to fit the needs of the situation. So, it should be no surprise if two different TOGAF-certified consultants end up using two very different processes—even when working with the same organization.

      

    TOGAF is even more flexible about the actual generated architecture. In fact, TOGAF is, to a surprising degree, "architecture-agnostic". The final architecture might be good, bad, or indifferent. TOGAF merely describes how to generate an enterprise architecture, not necessarily how to generate a good enterprise architecture. For this, you are dependent on the experience of your staff and/or TOGAF consultant. People adopting TOGAF in the hopes of acquiring a magic bullet will be sorely disappointed (as they will be with any of the methodologies).

  4 more annotations...

• 26 Jan 12
  

  andyscotuk

  togaf comparison enterprise architecture

• 20 Jan 12
  

  Lindy McKeown Orwin

  Gartner enterprise architecture comparison framework methodologies zachman

• 10 Jan 12
  

  ConsultPath Reference

  EnterpriseArchitecture

• 19 Dec 11
  

  Mehmet Akyuz

  A Comparison of the Top Four Enterprise-Architecture Methodologies

  ea

• 17 Nov 11
  

  Claudio Bergamini

  Roger Sessions

  ea

• 10 Oct 11
  

  Armando Siliceo-Roman

  Enterprise Architecture Methodology

• 29 Sep 11
  

  Luca Filipozzi

  enterprise architecture ea

• 07 Sep 11
  

  Bill D

  architecture enterprise comparison article

• 23 Aug 11
  

  Neil Forster

  Enterprise-Architecture comparison

• 22 Aug 11
  

  William Barnett

  framework enterprise architecture SAD

• 14 Aug 11
  

  nicolas 3

  EA enterprise architecture introduction article TOGAF zachman

• 08 Aug 11
  

  Jonathan Mike

  patterns & practices enterprise-architecture togaf zachman

• 28 Jul 11
  

  themistry

  architecture methodologies

• 12 Jul 11
  

  vvasam

  EA

• 13 Jun 11
  

  spyrallrall

  EA

  • architect—One whose responsibility is the design of an architecture and the creation of an architectural description

      

    architectural artifact—A specific document, report, analysis, model, or other tangible that contributes to an architectural description

      

    architectural description*—A collection of products (artifacts) to document an architecture

      

    architectural framework—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 methodology—A generic term that can describe any structured approach to solving some or all of the problems related to architecture

      

    architectural process—A defined series of actions directed to the goal of producing either an architecture or an architectural description

      

    architectural taxonomy—A methodology for organizing and categorizing architectural artifacts

      

    architecture*—The fundamental organization 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 architecture—An architecture in which the system in question is the whole enterprise, especially the business processes, technologies, and information systems of the enterprise
• 20 Apr 11
  

  acorrea

  enterprise architecture TOGAF

• 

  ronald fuller

  architecture taxonomy business technology ideas data

• 18 Apr 11
  

  Vasileios Fasoulas

  togaf zachman architecture

• 14 Apr 11
  

  Rachel Murray

  architecture enterprise

• 22 Mar 11
  

  Tomás Guerrero

  A Comparison of the Top Four Enterprise-Architecture Methodologies
   
  Roger Sessions
  ObjectWatch, Inc.
  
  May 2007
  
  Applies to:
     Enterprise Architecture
  
  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 evolving—and rapidly so. (36 printed pages)

  arquitectura_empresarial marco Zachman togaf

• 14 Feb 11
  

  aarmst12

  architecture zachman togaf comparison article delicious bookmark

• 29 Jan 11
  

  Lucky Phil
  • • ems that are hindering the organization's ability to respond to current, and future, market conditions in a timely and cost-effective manner.
      
    • Mission-critical information that is consistently out-of-date and/or just plain wrong.
      
    • A culture of distrust bet
  • on-critical
  • system
  • should
  • How should this company choose from among these four very different approaches to enterprise architecture? This white paper traces the journey the company is likely to fa
  • blended methodology

  • to the specific needs of your organization. This white paper gives an approach to creating such a blended methodology that is a best fit for your organization's needs.

      

    But even a blended methodology will only be as good as an organization's commitment to making changes. This commitment must be driven by the highest level of the organization. The good news is th

  • te paper discusses these four approaches to enterprise architecture. It does so within the context of a fictional company that is facing some very nonfictional operations problems. These problems include:  

     
    • IT systems that have become unmanageably complex and increasingly costly to maintain.
      
    • IT
  • enterprise architecture—An architecture in which the system in question is the whole enterprise, especially the business processes, technologies, and information systems of the enterprise
  • Zachman's vision was that business value and agility could best be realized by a holistic approach to systems architecture that explicitly looked at every important issue from every important perspective. His multiperspective approach to architecting systems is what Zachman originally described as an information systems architectural framework and soon renamed to be an enterprise-architecture framework.
  • One dimension is the various "players in the game." For a physical building, some of these players are the owner (who is paying for the project), the builder (who is coordinating the overall construction), and a zoning board (who is ensuring that construction follows local building regulations).
  • The second dimension for architectural artifact organization is the descriptive focus of the artifact: the what, how, where, who, when, and why of the project. This dimension is independent of the first. Both the builder and the owner need to know what, but the owner's need to know what is different from the builder's need to know what. What what is what depends on who is asking the question.
  • On the other ha

  • So, we can see five ways in which the Zachman grid can help in the development of MAM-EA. It can help:  

     
    1. Ensure that every stakeholder's perspective has been considered for every descriptive focal point.
      
    2. Improve the MAM-EA artifacts themselves by sharpening each of their focus points to one particular concern for one particular audience.
      
    3. Ensure that all of Bret's business requirements can be traced down to some technical implementation.
      
    4. Convince Bret that Irma's technical team isn't planning on building a bunch of useless functionality.
      
    5. Convince Irma that the business folks are including her IT folks in their planning.

  • Figure 5. TOGAF's enterprise architecture

      

    As shown in the figure, TOGAF divides an enterprise architecture into four categories, as follows:  

     
    1. Business architecture—Describes the processes the business uses to meet its goals
      
    2. Application architecture—Describes how specific applications are designed and how they interact with each other
      
    3. Data architecture—Describes how the enterprise datastores are organized and accessed
      
    4. Technical architecture—Describes the hardware and software infrastructure that supports applications and their interactions
  • TOGAF describes itself as a "framework," but the most important part of TOGAF is the Architecture Development Method, better known as ADM. ADM is a recipe for creating architecture. A recipe can be categorized as a process. Given that ADM is the most visible part of TOGAF, I categorize TOGAF overall as an architectural process, instead of either an architectural framework (as The Open Group describes TOGAF) or a methodology (as it describes ADM).
  • For an organization such as MedAMore, TOGAF largely boils down to the Architecture Development Method (ADM). Individuals within MedAMore will be exposed to the Enterprise Continuum, the SIB, and the TRM (as well as a few other TOGAF features), which is why I discussed them. But the day-to-day experience of creating an enterprise architecture will be driven by the ADM, a high-level view of which is shown in Figure 7.

  • Comparison

      

    As you can see, the leading enterprise-architecture methodologies are very different in their approaches. Which one is best for your organization? There is no one answer to this question. I'll take you through the 12 criteria that I most often use for comparing and evaluating enterprise-architectural methodologies. Not all of these criteria might be relevant to your organization, and some might be more important than others. But, at least, this section can serve as a starting point for your own evaluation.

      

    I'll rank each methodology in each criteria. The ratings will be assigned as follows:  

     
    • 1: Does a very poor job in this area
      
    • 2: Does an inadequate job in this area
      
    • 3: Does an acceptable job in this area
      
    • 4: Does a very good job in this area
     
      

    Keep in mind that these ratings are subjective. I'm sure most people would disagree with at least one of my ratings.

      

    Taxonomy completeness refers to how well you can use the methodology to classify the various architectural artifacts. This is almost the entire focus of Zachman. None of the other methodologies focuses as much on this area. Ratings:  

     
    • Zachman: 4
      
    • TOGAF: 2
      
    • FEA: 2
      
    • Gartner: 1
     
      

    Process completeness refers to how fully the methodology guides you through a step-by-step process for creating an enterprise architecture. This is almost the entire focus of TOGAF, with its Architecture Development Method (ADM). Ratings:  

     
    • Zachman: 1
      
    • TOGAF: 4
      
    • FEA: 2
      
    • Gartner: 3
     
      

    Reference-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 FEA. TOGAF also provides support; however, I am less impressed with the TOGAF reference models. Ratings:  

     
    • Zachman: 1
      
    • TOGAF: 3
      
    • FEA: 4
      
    • Gartner: 1
     
      

    Practice guidance refers to how much the methodology helps you assimilate the mindset of enterprise architecture into your organization and develop a culture in which it is valued and used. This is a primary focus of Gartner's architectural practice. Ratings:  

     
    • Zachman: 1
      
    • TOGAF: 2
      
    • FEA: 2
      
    • Gartner: 4
     
      

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

     
    • Zachman: 1
      
    • TOGAF: 1
      
    • FEA: 3
      
    • Gartner: 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 expenses and/or increased income. Ratings:  

     
    • Zachman: 1
      
    • TOGAF: 2
      
    • FEA: 1
      
    • Gartner: 4
     
      

    Governance guidance refers to how much help the methodology will be in understanding and creating an effective governance model for enterprise architecture. Ratings:  

     
    • Zachman: 1
      
    • TOGAF: 2
      
    • FEA: 3
      
    • Gartner: 3
     
      

    Partitioning guidance refers to how well the methodology will guide you into effective autonomous partitions of the enterprise, which is an important approach to managing complexity. Ratings:  

     
    • Zachman: 1
      
    • TOGAF: 2
      
    • FEA: 4
      
    • Gartner: 3
     
      

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

     
    • Zachman: 1
      
    • TOGAF: 2
      
    • FEA: 4
      
    • Gartner: 2
     
      

    Vendor neutrality refers to how likely you are to get locked-in to a specific consulting organization by adopting this methodology. A high rating here indicates low vendor lock-in. Ratings:  

     
    • Zachman: 2
      
    • TOGAF: 4
      
    • FEA: 3
      
    • Gartner: 1
     
      

    Information availability refers to the amount and quality of free or inexpensive information about this methodology. Ratings:  

     
    • Zachman: 2
      
    • TOGAF: 4
      
    • FEA: 2
      
    • Gartner: 1
     
      

    Time 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. Ratings:  

     
    • Zachman: 1
      
    • TOGAF: 3
      
    • FEA: 1
      
    • Gartner: 4
     
      

    The criteria and ratings are summarized in Figure 10.

      

    

      

    Figure 10. Criteria and ratings for each methodology

  • One of the important points of Figure 10 is that none of the enterprise-architecture methodologies is really complete. Each has its strengths and weaknesses.

      

    How do you choose which methodology is best for you? Here is my recommended approach:  

     
    1. Go through the rows (criteria) in Figure 10, eliminating any that you feel are not important to your organization.
      
    2. Add any additional rows (criteria) that you feel are important, and rate each of the methodologies in that area.
      
    3. Change any of my ratings with which you disagree.
     
      

    At the end of this exercise, you should have a good idea about the strengths and weaknesses of each methodology with respect to your enterprise's needs. If a clear winner emerges, count yourself lucky. Find a consultant who specializes in helping enterprises implement that methodology, and go for it.

      

    For many organizations, there will be no clear winner. For such organizations, I recommend you use a blended approach, in which you create your own enterprise-architectural methodology consisting of bits and pieces of each of the methodologies that provide the highest value in your specific areas of concern.

      

    You will want a different kind of consultant—one who has a broad perspective of all of these methodologies and specializes in helping enterprises create a methodology that works best, given the specific needs and political realities of that enterprise.
  • Whichever route you choose, remember that enterprise architecture is a path, not a destination.
  • In many organizations, there is a culture of distrust between the technology and business folks. No enterprise-architecture methodology can bridge this divide unless there is a genuine commitment to change. That commitment must come from the highest level of the organization. Methodologies cannot solve people problems; they can only provide a framework in which those problems can be solved.

  • Some of the predicted benefits from a successfully implemented enterprise architectural include:  

     
    • Improvements in using IT to drive business adaptability.
      
    • Closer partnership between business and IT groups.
      
    • Improved focus on organizational goals.
      
    • Improved morale, as more individuals see a direct correlation between their work and the organization's success.
      
    • Reduced numbers of failed IT systems.
      
    • Reduced complexity of existing IT systems.
      
    • Improved agility of new IT systems.
      
    • Closer alignment between IT deliverables and business requirements.

  20 more annotations...

• 26 Jan 11
  

  Helios BOlorinos

  enterprise_architecture framework reference

• 25 Jan 11
  

  Janet Kuntz

  entarch architecture

• 10 Sep 10
  

  futbolsalas15

  Design

• 06 Sep 10
  

  cdhaw01

  architecture togaf zachman framework enterprise_architecture

• 14 Aug 10
  

  Salman ZG

  hich messages from the outside world are received or through which messages to

  enterprise-architecture architecture compare togaf zachman

  • The Zachman Framework for Enterprise Architectures
    The Open Group Architecture Framework (TOGAF)
    Federal Enterprise Architecture (FEA)
    Gartner
  • System complexity
  • IT systems aligned with business need
  • proscriptive

  • These problems include:  

    • IT systems that have become unmanageably complex and increasingly costly to maintain.
    • IT systems that are hindering the organization's ability to respond to current, and future, market conditions in a timely and cost-effective manner.
    • Mission-critical information that is consistently out-of-date and/or just plain wrong.
    • A culture of distrust between the business and technology sides of the organization.
  • none of these methodologies will therefore be a complete solution
  • But even a blended methodology will only be as good as an organization's commitment to making changes. This commitment must be driven by the highest level of the organization. The good news is that, with a real commitment to change and a tailored methodology for guiding that change, the 20-year-old promise of enterprise architecture is within reach.
  • Gartner had struggled to build an enterprise-architecture practice, but never achieved the status of the Meta Group. In 2005, Gartner decided that if they couldn't compete with Meta Group, they would do the next best thing: They would buy it.
  • The business side saw IT as reducing business agility. The technical side saw the business side as making impossible demands and blamed it for refusing to consult IT before entering into acquisition discussions.
  • using enterprise architectures to build stronger partnerships between their technical and business groups and deliver more cost-effective IT systems that enabled business agility
  • create a common enterprise architecture for MedAMore that would unite its technical and business people.
  • EA would drive all new IT investment and ensure that every dollar invested in IT was delivering the maximum value to the business.

  • a framework is defined as:

     A structure for supporting or enclosing something else, especially a skeletal support used as the basis for something being constructed;

  • A taxonomy, on the other hand, is defined as:

     The classification of organisms in an ordered system that indicates natural relationships; The science, laws, or principles of classification; systematics; Division into ordered groups or categories [12]
  • Zachman originally explained his IT taxonomy using the building industry as an analogy. In that industry, architectural artifacts are implicitly organized using a two-dimensional organization.
  • One dimension is the various "players in the game."
  • second dimension for architectural artifact organization is the descriptive focus of the artifact: the what, how, where, who, when, and why of the project.

  • we can see five ways in which the Zachman grid can help in the development of MAM-EA. It can help:  

    1. Ensure that every stakeholder's perspective has been considered for every descriptive focal point.
    2. Improve the MAM-EA artifacts themselves by sharpening each of their focus points to one particular concern for one particular audience.
    3. Ensure that all of Bret's business requirements can be traced down to some technical implementation.
    4. Convince Bret that Irma's technical team isn't planning on building a bunch of useless functionality.
    5. Convince Irma that the business folks are including her IT folks in their planning.
  • Zachman does not give us a step-by-step process for creating a new architecture. Zachman doesn't even give us much help in deciding if the future architecture we are creating is the best architecture possible.

  • TOGAF divides an enterprise architecture into four categories, as follows:  

    1. Business architecture—Describes the processes the business uses to meet its goals
    2. Application architecture—Describes how specific applications are designed and how they interact with each other
    3. Data architecture—Describes how the enterprise datastores are organized and accessed
    4. Technical architecture—Describes the hardware and software infrastructure that supports applications and their interactions
  • the most important part of TOGAF is the Architecture Development Method
  • TRM and the SIB are flawed for the same reason: They are biased toward application portability, at the expense of application interoperability and application autonomy
  • Zachman tells you how to categorize your artifacts. TOGAF gives you a process for creating them.
  • TOGAF calls most generic architectures Foundation Architectures. These are architectural principles that can, theoretically, be used by any IT organization in the universe.
  • TOGAF calls the next level of specificity Common Systems Architectures. These are principles that one would expect to see in many—but, perhaps, not all—types of enterprises.
  • TOGAF calls the next level of specificity Industry Architectures. These are principles that are specific across many enterprises that are part of the same domain—such as, in our MedAMore case study, all pharmaceutical enterprises.
  • TOGAF calls the most specific level the Organizational Architectures. These are the architectures that are specific to a given enterprise, such as MedAMore.

  • In the Preliminary Phase, Teri meets with the major players at MedAMore to introduce the TOGAF process. Her three goals in the preliminary phase are to:  

    1. Make sure everybody is comfortable with the process.
    2. Modify the TOGAF process, as necessary, to fit within the MedAMore culture.
    3. Set up the governance system that will oversee future architectural work at MedAMore.
  • Phase A begins, at least in theory, with a Request for Architecture Work
  • This document includes the business reasons for the request, budget and personnel information, and any constraints
  • TOGAF defines the various knowledge bases that live in the Foundation Architecture. Two that you might run into are the Technical Reference Model (TRM) and the Standards Information Base (SIB). The TRM is a suggested description of a generic IT architecture. The SIB is a collection of standards and pseudo-standards that The Open Group recommends that you consider in building an IT architecture.
  • A segment is a major line-of-business functionality, such as human resources. There are two types of segments: core mission-area segments and business-services segments.
  • A core mission-area segment is one that is central to the mission or purpose of a particular political boundary within the enterprise. For example, in the Health and Human Services (HHS) agency of the federal government, health is a core mission-area segment.
  • A business-services segment is one that is foundational to most, if not all, political organizations. For example, financial management is a business-services segment that is required by all federal agencies.
  • An enterprise service is a well-defined function that spans political boundaries
  • The difference is that business-service segments have a scope that encompasses only a single political organization. Enterprise services have a scope that encompasses the entire enterprise.
  • Resist the temptation to equate either segments or services with services, as in service-oriented architectures. There are two reasons such a comparison would be flawed. Firstly, enterprise services, business-service segments, and core mission-area segments are all much broader in focus than services found in service-oriented architectures. Secondly, segments are an organizational unit for an enterprise architecture, whereas services are an organizational unit for technical implementations. As organizational units for an enterprise architecture, their depth includes not just the technical, but also the business and the data architectures.

  • The five reference models are as follows:  

    1. The Business Reference Model (BRM) gives a business view of the various functions of the federal government. For example, the BRM 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 citizens business area. [29]
    2. The Components Reference Model (CRM) gives a more IT view of systems that can support business functionality. For example, the CRM defines a customer-analytics system that I described earlier in the hypothetical interchange between the IRS and the GPO. [30]
    3. The Technical Reference Model (TRM) defines the various technologies and standards that can be used in building IT systems. For example, the TRM defines HTTP as a protocol that is a subset of a service transport that is a subset of service access and delivery. [31]
    4. The Data Reference Model (DRM) defines standard ways of describing data. For example, the DRM defines an entity as something that containsattributes and participates in relationships. [32]
    5. The Performance Reference Model (PRM) defines standard ways of describing the value delivered by enterprise architectures. For example, the PRM describes quality as a technology measurement area that is defined as "the extent to which technology satisfies functionality or capability requirements." [33]

  • The overall segment-architecture development process is (at a very high level) as follows:  

    • Step 1: Architectural Analysis—Define a simple and concise vision for the segment, and relate it back to the organizational plan.
    • Step 2: Architectural Definition—Define 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.
    • Step 3: Investment and Funding Strategy—Consider how the project will be funded.
    • Step 4: Program-Management Plan and Execute Projects—Create a plan for managing and executing the project, including milestones and performance measures that will assess project success.

  • Federal agencies are rated on their overall maturity levels in three main categories:  

    1. Architectural completion—Maturity level of the architecture itself
    2. Architectural use—How effectively the agency uses its architecture to drive decision-making
    3. Architectural results—The benefits being realized by the use of the architecture
  • In Phase A, Teri will ensure that the project has the necessary support within MedAMore, define the scope of the project, identify constraints, document the business requirements, and establish high-level definitions for both the baseline (starting) architecture and target (desired) architecture.
  • The culmination of Phase A will be a Statement of Architecture Work
  • The output of this phase is to create an architectural vision for the first pass through the ADM cycle. Teri will guide MedAMore into choosing the project, validating the project against the architectural principles established in the Preliminary Phase, and ensure that the appropriate stakeholders have been identified and their issues have been addressed.
  • The first thing that Fred will want to do is build enthusiasm for MEA
  • goal in Phase B is to create a detailed baseline and target business architecture and perform a full analysis of the gaps between them
  • MEAPMO will own MEA, including the processes, the models, and the architecture itself
  • Fred will next build a governance structure
  • Phase B is quite involved—involving business modeling, highly detailed business analysis, and technical-requirements documentation.
  • The next thing that Fred will likely do is create reference models that can be used by all of the organizations
  • Next, Fred will probably want to create a description of the segment architecture as it applies to MedAMore. Note that he will not be doing a complete segment architecture—just a high-level description. The actual process of completing the architecture will be a constantly evolving project.
  • Phase C does for the information-systems architecture what Phase B does for the business architecture.

  • TOGAF defines nine specific steps, each with multiple sub-steps:  

    1. Develop baseline data-architecture description
    2. Review and validate principles, reference models, viewpoints, and tools
    3. Create architecture models, including logical data models, data-management process models, and relationship models that map business functions to CRUD (Create, Read, Update, Delete) data operations
    4. Select data-architecture building blocks
    5. Conduct formal checkpoint reviews of the architecture model and building blocks with stakeholders
    6. Review qualitative criteria (for example, performance, reliability, security, integrity)
    7. Complete data architecture
    8. Conduct checkpoint/impact analysis
    9. Perform gap analysis

    The most important deliverable from this phase will be the Target Information and Applications Architecture.
  • Now, Fred will test-drive the process with the first segment delivery. He will need to build a team, and then lead this team in analyzing and prioritizing the segments—mapping them to business value, determining their architectural options, delivering the work, and, perhaps most importantly, measuring the results.
  • And, finally, after Fred has completed this process, he will start the process again
  • It isn't a taxonomy (like Zachman), a process (like TOGAF), or a complete methodology (like FEA). Instead, it is what I define as a practice.
  • Phase D completes the technical architecture—the infrastructure necessary to support the proposed new architecture.
  • much like I would to describe a physician's practice.
  • These practice skills include his experience, training, and ongoing relationships with his colleagues.
  • Phase E evaluates the various implementation possibilities
  • evaluates the business opportunity associated with each
  • How do you choose a physician?
  • focus on projects that will deliver short-term payoffs and so create an impetus for proceeding with longer-term projects."
  • One approach to choosing a physician is to go to a well-known institution (a hospital or medical school) and choose from among their staff
  • looking for projects that can be completed as cheaply as possible, while delivering the highest perceived value
  • Your initial concern is only the reputation of the institution.
  • You go to Gartner because they are well-known in their field. You assume both that they hire well-qualified specialists and that they have developed a community that encourages collaboration and best practice.
  • Phase F is closely related to Phase E. In this phase, Teri works with MedAMore's governance body to sort the projects identified in Phase E into priority order that include not only the cost and benefits (identified in Phase E), but also the risk factors.
  • best practices are timeless
  • In Phase G, Teri takes the prioritized list of projects and creates architectural specifications for the implementation projects. These specifications will include acceptance criteria and lists of risks and issues.

  • The best summation of the Gartner practice that I have heard is the following:

     Architecture is a verb, not a noun.

    What does it mean to say that architecture is a verb, not a noun? It 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 just a bunch of stiff artifacts that sit in a corner gathering dust is useless, regardless of how sophisticated your taxonomy is for categorizing those artifacts or how brilliant your process is that guided their development.

    Gartner believes that enterprise architecture is about bringing together three constituents: business owners, information specialists, the technology implementers. If you can bring these three groups together and unify them behind a common vision that drives business value, you have succeeded; if not, you have failed. Success is measured in pragmatic terms, such as driving profitability, not by checking off items on a process matrix.

    Gartner believes that the enterprise architectures must start with where an organization is going, not with where it is. If we are going to clean house, we don't need to exhaustively document everything we are throwing out. Let's 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.

    Gartner recommends that an organization begin by telling the story of where its strategic direction is heading and what the business drivers are to which it is responding. Gartner will want this story in plain language, without worrying about prescribed documentation standards, acronyms, or techno-babble. The only goal is making sure that everybody understands and shares a single vision.
  • The final phase is H. In this phase, Teri modifies the architectural change-management process with any new artifacts created in this last iteration and with new information that becomes available.

  • Most organizations are facing major changes in their business processes. The process of creating an enterprise-architecture vision is the organization's 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 organization 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.

    Enterprise architecture, in the Gartner view, is about strategy, not about engineering. It is focused on the destination. The two things that are most important to Gartner are where an organization is going and how it will get there. Any architectural activity that is extraneous to these questions is irrelevant. "Just enough enterprise architecture, just in time," is another saying you will hear from the Gartner analyst.
  • TOGAF allows phases to be done incompletely, skipped, combined, reordered, or reshaped to fit the needs of the situation.
  • TOGAF merely describes how to generate an enterprise architecture, not necessarily how to generate a good enterprise architecture.
  • FEA is the most complete of all the methodologies discussed so far. It has both a comprehensive taxonomy, like Zachman, and an architectural process, like TOGAF.
  • Notice that none of these visionary statements mentions technology (except as a delivery mechanism, in the last statement). Greg is purposely keeping these early discussions focused on business strateg
  • Any one of Cath's vision "bullets" will have major ramifications across the business, information, and technical architectures. Part of Greg's job will be to prioritize the bulleted items
  • Greg will soon work to turn Cath's idea about consolidated purchasing into a common-requirements vision (CRV)
  • Greg will be going over the business changes with Bret and the technical and information changes with Irma, but he will also be working to bring everybody together as a unified tea
  • FEA as simply consisting of five reference models, one each for performance: business, service, components, technical, and data.
  • Greg will work with Bret (the business VP) to develop a target business architecture that supports consolidated purchasing. As soon as they have spec'd out the future system, they will also look at their current architecture to see what can be recycled.

  • A full treatment of FEA needs to include all of the following:  

    • A perspective on how enterprise architectures should be viewed (the segment model, that I 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 pre-EA to a post-EA paradigm
    • A taxonomy 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
  • They will also work on the technical architecture for the IT systems that will support the new business architecture. After they understand the future, they will look at current architectures for opportunities to reuse existing technology assets.
  • Greg will work with Irma (the CIO) to develop a target information architecture
  • After Greg has completed the broad-brush architecture for their strategic vision, he will probably step back from the picture until the consolidated purchasing system has been implemented.
  • Gartner does not do implementations.
  • As soon as the implementation of consolidated purchasing has been completed, Greg will step back in to help with the next iteration.
  • He will continue to see his role not as creating an enterprise architecture for MedAMore, but helping them institute a process for allowing an enterprise architecture to emerge and evolve from the business strategy.
  • enterprise architecture is a path, not a destination.
  • enterprise architecture has no value unless it delivers real business value as quickly as possible
  • No enterprise-architecture methodology can bridge this divide unless there is a genuine commitment to change. That commitment must come from the highest level of the organization. Methodologies cannot solve people problems; they can only provide a framework in which those problems can be solved.
  • 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 self-analysis. Does your organization spend too much money building IT systems that deliver inadequate business value? Is IT seen as improving or hampering business agility? Is there a growing divide between your business and IT folks? And, finally, perhaps the most important question of all: Is your organization truly committed to solving these problems, and does that commitment come from the highest levels of the organization? If the answer to all of these questions is "yes," enterprise architecture is your path. It's up to you to take that next step.

  91 more annotations...

• 05 Aug 10
  

  Roozbeh F

  ea paper softwareengineering

• 28 Jul 10
  

  Walt Davis
  • The Zachman Framework for Enterprise Architectures
  • The Zachman Framework for Enterprise Architectures
  • The Zachman Framework for Enterprise Architectures
  • The Zachman Framework for Enterprise Architectures
  • The Zachman Framework for Enterprise Architectures

  • enterprisearchitecture. The field initially began to address two problems:  

    • System complexity—Organizations were spending more and more money building IT systems; and
    • Poor business alignment—Organizations were finding it more and more difficult to keep those increasingly expensive IT systems aligned with business need.
  • The cost and complexity of IT systems have exponentially increased, while the chances of deriving real value from those systems have dramatically decreased.
  • Today's bottom line: even more cost, even less value. Large organizations can no longer afford to ignore these problems. The field of enterprise architecture that 20 years ago seemed quaintly quixotic today seems powerfully prophetic.
  • The Zachman Framework for Enterprise Architectures
  • • The Zachman Framework for Enterprise Architectures—Although self-described as a framework, is actually more accurately defined as a taxonomy
    • The Open Group Architectural Framework (TOGAF)—Although called a framework, is actually more accurately defined as a process
    • The Federal Enterprise Architecture—Can be viewed as either an implemented enterprise architecture or a proscriptive methodology for creating an enterprise architecture
    • The Gartner Methodology—Can be best described as an enterprise architectural practice

  8 more annotations...

• 

  Rob West

  togaf enterprise-architecture

• 07 Jul 10
  

  jkazda

  togaf enterprise-architecture

• 14 May 10
  

  Enrico Marongiu

  BPR enterprise architecture methodologies architect reference tutorial comparison

• 05 Mar 10
  

  enterprise-architecture comparison framework

• 19 Feb 10
  

  aminggs

  "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 stil

  document article msdn roger-sessions softwaredevelopment softwarearchitecture enterprisearchitecture zachmanframework togaf fea import:delicious

• 06 Feb 10
  

  Edward Glantz
• 17 Jan 10
  

  Mohammad Reza B.

  Enterprise Architecture TOGAF

• 12 Jan 10
  

  jssunil

  architecture zachman togaf enterprise_architecture ea methodologies enterprise enterprise-architecture software computer toread

• 30 Dec 09
  

  endre domiczi

  togaf zachman enterprise_architecture architecture methodologies

• 01 Sep 09
  

  Anthony Bouch

  enterprise architecture togaf

• 02 Jun 09
  

  rsearjeant

  enterprise-architecture comparison togaf zachman microsoft

• 01 Jun 09
  

  jimheru

  Arquitectura Empresarial

• 28 May 09
  

  architecture:enterprise framework

• 01 Apr 09
  

  immu_h

  ea enterpriseArchitecture

• 20 Feb 09
  

  fun wild
• 21 Jan 09
  

  Iain Napier

  enterprise_architecture to_read togaf zachman

• 16 Dec 08
  

  Reza Khalafi

  EnterpriseArchitecture architecture zachman enterprise-architecture togaf enterprise_architecture ea enterprise

• 21 Oct 08
  

  Luiz Aquino

  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 evolving

  software microsoft enterprise_architecture

• 09 Oct 08
  

  burgenland

  togaf zachman enterprise_architecture ea architecture

• 30 Sep 08
  

  Gajapathi Kannan

  architecture

• 17 Sep 08
  

  Sultan Meghji
• 24 Jun 08
  

  Island Chen

  zachman EA

• 21 May 08
  

  Robert Winter

  Compares Zachman, TOGAF, FEA and Gartner

  enterprise architecture

  • Taxonomy completeness refers to how well you can use the methodology to classify the various architectural artifacts.
  • Prescriptive catalog refers to how well the methodology guides you in setting up a catalogue of architectural assets that can be reused in future activities.
  • Information availability refers to the amount and quality of free or inexpensive information about this methodology.
  • 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 expenses and/or increased income.
  • Partitioning guidance refers to how well the methodology will guide you into effective autonomous partitions of the enterprise, which is an important approach to managing complexity
  • Maturity model refers to how much guidance the methodology gives you in assessing the effectiveness and maturity of different organizations within your enterprise in using enterprise architecture.
  • Process completeness refers to how fully the methodology guides you through a step-by-step process for creating an enterprise architecture.
  • Vendor neutrality refers to how likely you are to get locked-in to a specific consulting organization by adopting this methodology.
  • Governance guidance refers to how much help the methodology will be in understanding and creating an effective governance model for enterprise architecture.
  • Time 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.
  • Practice guidance refers to how much the methodology helps you assimilate the mindset of enterprise architecture into your organization and develop a culture in which it is valued and used.
  • Reference-model guidance refers to how useful the methodology is in helping you build a relevant set of reference models.

  10 more annotations...

Would you like to comment?

Join Diigo for a free account, or sign in if you are already a member.