• Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,080
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
68
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Battleground of the Enterprise Architecture Frameworks Enterprise Architecture Deborah Weiss Notes accompany this presentation. Please select Notes Page view. These materials can be reproduced only with Gartner's official approval. Such approvals may be requested via e-mail — quote.requests@gartner.com.
  • 2. Client Issues 1. What is an enterprise architecture framework, and why do I need one? 2. What criteria do I use to evaluate different frameworks? 3. What frameworks will we compare, and how do they measure up?
  • 3. What Is an Enterprise Architecture Framework? Describes a method for designing an information system in terms of a set of building blocks and for showing how the building blocks fit together (TOGAF, v.8) Consists of various approaches, models and definitions for communicating the overall organisation and relationships of architecture components (CIO Council, 1999) Describes a specific approach to organising an enterprise architecture (The Enterprise Architecture Survival Guide) Presents a common vocabulary and set of perspectives, a framework for defining and describing complex enterprise systems (www.zifa.com)
  • 4. Defining Framework Derived from a search of the Oxford English Dictionary: A framework is something that provides structure when defining how technology is organised to support the business objectives of an enterprise. Can be viewed as having two parts. Content Deliverables Organisation Who uses? Structure When relevant? Hierarchy How determined? Enterprise Architecture Framework
  • 5. Why a Framework Is Needed Enterprise architecture (particularly at the enterprise level) is a complex and multifaceted problem: – Anything that instills consistency and discipline into the process is good – Anything that provides a structure and defines the relationships between the pieces is even better – An architecture is difficult enough to do if you have a framework; don't try to develop it without some organising structure An EA provides an agreed-upon set of constructs that can be used to express architectural concepts and a language to communicate them All EA programs should include some notion of a process to develop an EA and clearly define the relationship with the framework
  • 6. Defining Enterprise Architecture Short form – Enterprise architecture is the process of translating business vision and strategy into effective enterprise change by creating, communicating and improving the key principles and models that describe the enterprise's future state and enable its evolution. Long form – Enterprise architecture is the process of translating business vision and strategy into effective enterprise change by creating, communicating and improving the key principles and models that describe the enterprise's future state and enable its evolution. The scope of the enterprise architecture includes the people, processes, information and technology of the enterprise, and their relationships to one another and to the external environment. Enterprise architects compose holistic solutions that address the business challenges of the enterprise, and support the governance needed to implement them. Shortest form – Enterprise architecture means … architecting the enterprise.
  • 7. How to Evaluate Frameworks A good enterprise architecture framework should: Have a top-down approach that encourages architecture driven out of business strategy Support abstraction to allow the removal of complicating factors Contain a robust set of constructs for all levels of the EA and a well-developed language – Coherence and cohesion Aligned to a process for developing the EA Provide advice on architecture governance
  • 8. Frameworks That Will Be Compared IEEE 1471 The Open Group Architecture Framework (TOGAF) The Zachman Framework NASCIO Enterprise Architecture Framework Gartner's Enterprise Architecture Framework U.S. Federal Enterprise Architecture Program
  • 9. IEEE 1471 IEEE Recommended Practice for Architectural Description of Software-Intensive Systems To define useful terms, principles and guidelines for the consistent application of architectural precepts to systems throughout their life cycle To elaborate architectural precepts and their anticipated benefits for software products, systems, and aggregated systems (i.e., “systems of systems”) To provide a framework for the collection and consideration of architectural attributes and related information for use in IEEE standards To provide a useful road map for the incorporation of architectural precepts in the generation, revision, and application of IEEE standards
  • 10. How Does IEEE 1471 Stack Up? = good = caution Top down A focus on mission and environment influencing system design but limited linkage to business strategy Supports abstraction Uses multiple levels of detail to define architectural descriptions Constructs and language Well-developed set of architecture constructs Process Limited process Governance Minimal mention
  • 11. TOGAF Developed by The Open Group in the 1990s, currently in v.8.1 (The Open Group Architecture Framework) Focus on technical architecture through v.7 Focused around architecture development method Intentionally generic — no prescribed deliverables
  • 12. How Does TOGAF Stack Up? = good = caution Top down Business and information architecture recent additions Suggests starting with the business architecture You can enter the process anywhere along the continuum Supports abstraction Constructs and language Generically defined to support a wide range of deliverables Deliverables are not prescribed Difficult to understand the relationships between different deliverables Process Robust and well-defined Governance Robust
  • 13. Zachman Framework Proposed by John Zachman in 1987, extended in 1992 "Supports the organisation, access, integration, interpretation, development, management and changing of a set of architectural representations of information systems" Six "dimensions" address different subject areas of the architecture Five "perspectives" associated with the scope of interest of a class of stakeholders Order of dimensions is arbitrary Order of perspectives is broad to narrow Deliverable neutral Sequence neutral
  • 14. How Does Zachman Stack Up? = good = caution Top down Framework is sequence neutral, cells can be populated in any order Supports abstraction Perspectives address different levels of abstraction corresponding to the scope of interest of different stakeholders Constructs and language Well-defined set of constructs and language The "richest" framework in terms of detail Process Method neutrality is a stated goal Governance Tangential reference
  • 15. NASCIO Enterprise Architecture Toolkit Government-oriented, but usable in other industries Version 3.0: Business Architecture Developed "in kind" DOJ funded Enterprise architecture maturity assessment Source: National Association of State Chief Information Officers
  • 16. How Does NASCIO Stack Up? Top down = good = caution Guidance is top down; however, domains are isolated from each other without treatment of their relationships and linkages Supports abstraction Perspectives address different levels of abstraction corresponding to the scope of interest of different stakeholders Little to support abstraction for other complicating factors Constructs and language Good set of constructs and language Process Very detailed process — beware overprescription Provides examples and templates Governance In-depth, highly detailed, and examples help different organisations choose models to suit current political environment
  • 17. Gartner's Enterprise Architecture Framework Originally developed in 2002 Evolved to enhance usability and join the framework with extensive process work Basis in IEEE practices Describes required and optional "viewpoints" Clear top-down decomposition
  • 18. How Does the Gartner Framework Stack Up? = good = caution Top down Explicitly drives architecture out of the business strategy Supports abstraction Multiple levels of abstraction defined Constructs and language Simplified approach Defined set of constructs with relationships clearly defined Process Alignment with a separate EA process Governance Governance is well supported by both the process and framework
  • 19. U.S. Federal Enterprise Architecture Program Federal Enterprise Architecture Reference Models Strategic Outcomes Mission/ Customer Business Results Results Value Processes and Activities Value Human Other Technology Capital Assets Inputs FEAMS: Reference Models/ CORE.GOV: Business Cases Services/Components Business Cases: OMB Exhibit 300 Performance Goals and Measures Image Source: U.S. Federal Government
  • 20. Recommendations Every framework is different, because every enterprise is different – Culture, level of maturity, business imperatives No framework is an island – Choose the framework that best fits your needs; then borrow from others to fill any gaps Proper support for abstraction is key – Deficiencies in artifacts or governance are easy to supplement Some process is good, but beware of process that is too prescriptive Write it down – A high-level description of your framework, key constructs and the relationship to the EA process should be no more than 10 pages