Enterprise architecture framework: Difference between revisions

An enterprise architecture framework (EA framework) defines how to organize the structure and views and objects associated with an enterprise architecture. An architecture framework serves as guiding principles to establish a common practice for creating, interpreting, analyzing and using architecture descriptions within a particular domain and/or layers. The framework structures the practitioner's way of thinking in the specific area with supporting maps, matrices and models.

The three components of the enterprise architecture framework are:^[2]

• Views : provide the mechanisms for communicating information about the relationships that are important in the architecture.
• Methods: A method is a discipline where it gathers and organizes the phases in a construct, that helps the viewer and user to ensure integrity, accuracy and completeness of the task. A method is thereby a series of phases with a collection of activities that the user of the method needs to follow and undertake in order to reach a specific goal. There can be multiple methods within ether a framework or any other given discipline or field of inquiry. A method should structure the work within a specific area with supporting techniques, tools, principles, rules, procedures and practices.
• Approaches: An approach is a way of dealing with something, it is a series of steps to be taken in order to produce a wished pre-determined, sought for result. The approach structures modelling in the specific areas with a supporting scope, concept, roadmap and conceptual model.
• Training/Experience : support the EA framework, methods and approaches.

Because the discipline of enterprise engineering and enterprise architecture is so broad, and because enterprises can be large and complex, the models associated with the discipline also tend to be large and complex. To manage this scale and complexity, an architecture framework provides tools, methods and approaches that can bring the task into focus and allow valuable artifact to be produced when they are most needed.

Architecture frameworks are commonly used in IT and information system governance, meanwhile today, one of the most important driving force is in developing ones organization to adopt to the market changes! An organization may wish to mandate that certain models be produced before a system design can be approved.

The first Enterprise Architecture models were constructed late 1980s as a result of a new thinking about Enterprise Architecture. Enterprise Architecture had gradually emerged during the 1980s out of the desire of Information System/Information Technology people to reach business people outside their department and gain a wider, stronger influence over investment in business information systems. The pitch for Enterprise Architecture has always included better business-IT alignment, business and IT agility, cheaper and more efficient IT procurement and operations.

In the history of Enterprise Architecture and Enterprise Architecture frameworks since 1980, influential sources have included:

1. "Business System Planning" (BSP) IBM.
2. "Information Engineering" James Martin and others.
3. "Framework for Information System Architecture" John Zachman.
4. "Enterprise Architecture Planning" (EAP) Stephen Spewak.
5. The Enterprise Edition of TOGAF, The Open Group.
6. "EA as Strategy" MIT’s Centre for Information System Research.

Modern Enterprise Architecture frameworks (at least, all those including an Enterprise Architecture process) clearly descend from planning methods like those at 1 and 4 above, and borrow (sometimes explicitly, sometimes implicitly) from the other sources.

In the 1982, John Zachman was working in IBM and with their Business Systems Planning method when he was perhaps the first to mention Enterprise Architecture in the public domain: "Although many popular information systems planning methodologies, design approaches, and various tools and techniques do not preclude or are not inconsistent with enterprise-level analysis, few of them explicitly address or attempt to define enterprise architectures." ^[4]

IBM’s Business Systems Planning method, started in the 1970s, was/is a method for analyzing and designing an organization’s information architecture, with the goals:

1. understand the issues and opportunities with the current applications and technical architecture;
2. develop a future state and migration path for the technology that supports the enterprise;
3. provide business executives with a direction and decision making framework for IT capital expenditures;
4. provide information system (IS) with a blueprint for development

In 1987, Zachman published a paper "A Framework for Information Systems Architecture" ^[5]. The paper did not mention enterprise architecture; it provided no planning process; it provided only a classification scheme for artifacts that describe (at several levels of abstraction) the what, how, where, who, when and why of information systems.

In 1993, Stephen Spewak’s book Enterprise Architecture Planning defined a process for defining architectures for the use of information in support of the business and the plan for implementing those architectures. The business mission is the primary driver. Then the data required to satisfy the mission. Then the applications built to store and provide that data. Finally the technology to implement the applications. Enterprise Architecture Planning is a data-centric approach to architecture planning. An aim is to improve data quality, access to data, adaptability to changing requirements, data interoperability and sharing, and cost containment.

Some time after Stephen Spewak’s book (perhaps as late as 1997?), the Zachman Framework was refocused from information systems architecture to enterprise architecture.

Today, TOGAF ^[7] is by so far the most popular Enterprise Architecture framework (judged by published certification numbers) that some assume it defines EA. However, TOGAF started life as an IT architecture framework. In 1994, the Open Group selected TAFIM from the US DoD as a basis for development of an open IT architecture framework. TOGAF started out taking a strategic and enterprise-wide, but technology-oriented, view. It emerged out of the desire to rationalize a messy IT estate. Right up to version 7, TOGAF was still focused on defining and using a Technical Reference Model (or foundation architecture) to define the platform services required from the technologies that an entire enterprise uses to support business applications. In its “enterprise edition” TOGAF 8 (2002/3) shifted its focus to the business, data and application layers on top of technology architecture. It introduced structured analysis, after Information Engineering, which features, for example, mappings of organization units to business functions and data entities to business functions. Today, business functions are often called business capabilities. And many enterprise architects regard their business function/capability hierarchy as the fundamental Enterprise Architecture artifact. They map data entities, use cases, applications and technologies to the functions/capabilities.

TOGAF 9 said: “Business planning at the strategy level provides direction to enterprise architecture. Normally, the business principles, business goals, and strategic drivers of the organization are defined elsewhere.” In other words, Enterprise Architecture is not a business strategy, planning or management methodology. Enterprise Architecture strives to align business information systems technology with given business strategy, goals and drivers. “A complete enterprise architecture should address all four architecture domains - business, data, application, technology.” (TOGAF 9.1).

The British Computer Society (BCS) reference model for enterprise and solution architecture ^[8] defines Enterprise Architecture thus: “A strategic approach to architecture that addresses a whole enterprise. The highest level, widest scope, longest term kind of architecture. 1: Documentation describing the structure and behaviour of an enterprise and its information systems. Or 2: A process for describing an enterprise and its information systems and planning changes to improve their integrity and flexibility.”

The brief history above shows that enterprise architecture has always been inseparable from information system architecture, which is natural if you consider that business people need information to make decisions and carry out business processes.

Persons who have ever remodeled their home, know how important building codes, blueprints, and city or county inspections are to successfully complete the project. The architect operates within a "framework" of building codes, preparing blueprints for each phase of the project, from the structural changes to the size and layout of the rooms. Detailed drawings specify plumbing, electrical, and building construction information for the entire structure. Enterprise Architecture works in a similar manner.^[9]

An architecture framework for IT affects every aspect of the enterprise. An enterprise architecture framework is similar to building codes that ensure the building is soundly constructed. The IT governance bodies and procedures serve as the city and county inspectors for building improvement projects. Frameworks contain models and standards that will be used to develop IT architecture descriptions. The architecture description is the blueprint.^[9]

In the context of the creation of Enterprise Architecture it is common, according to Péter Bernus (2005),^[11] to recognise three or four types of architecture, each corresponding to its particular architecture domain. Examples of such domains are:

• Business architecture,
• Information systems architecture, often subdivided into
  • Data architecture, and
  • Application architecture,
• and Technical architecture.

Architectural domains are a structuring criterion for a collection of architecture products. They should not be confused with the application domain of the framework as such.^[11]

Contemporary federal guidance suggests thinking about “layers” of the enterprise architecture:^[12]

• Business Layer includes Business, Process, Service and Value.
• Application Layer includes Applications (customized and/or off-the-shelf software) and Data.
• Technology Layer includes Platform (such as operating systems) and Infrastructure (such as telephone networks and hardware).

The most notable difference between regular domain-centric EA frameworks and the approach taken within layered EA frameworks, such as the LEAD Frameworks,^[13] is the concept of building and structuring objects within a framework of interconnected layers of Business (Business, Process, Service and Value), Application (Software and Data) and Technology (Platform and Infrastructure). The main principles of layered EA frameworks and the interconnected layers are integrating and thereby interlinking the different modelling principles. For this, the concept of decomposition and composition is built into the layers and this is not considered done in the same way as traditional/regular Enterprise Architecture (e.g. like value and performance management as well as continuous improvement).

An Ideal EA Framework should have Following Components:

1. Architecture Development Method / Methodology
2. Architecture Artifacts Map
3. Business Value Measurement Metrics
4. EA Initiative Model
5. EA Maturity Model
6. Enterprise Communication Model
7. EA Governance Model

Most of Popular Frameworks including TOGAF, Zachman and ASSIMPLER focus on one or multiple of these aspects. So it is important to invest some time in planning which Framework (or combination of Frameworks) is most suitable for a situation. TOGAF is very strong in terms of defining Architecture Development Method, Zachman is very strong in defining artifacts and Taxonomy. ASSIMPLER is capable of establishing a strong corelation between Business and IT and has a strong Business Value Measurement Model.

The application and technology domains (which are not to be confused with business domains) are characterized by domain capabilities and domain services. The capabilities are supported by the services. The application services are also referred to in service-oriented architecture (SOA). The technical services are typically supported by software products.

The data view starts with the data classes which can be decomposed into data subjects which can be further decomposed into data entities. The basic data model type which is most commonly used is called merda (master entity relationship diagrams assessment, see entity-relationship model). The Class, subject and entity forms a hierarchical view of data. Enterprises may have millions of instances of data entities.

The Enterprise Architecture Reference Traditional Model offers clear distinction between the architecture domains (business, information/data, application/integration and technical/infrastructure). These domains can be further divided into Sub domain disciplines. An example of the EA domain and sub domains is in the image on the right.

Many enterprise architecture teams consist of Individuals with Skills aligned with the Enterprise Architecture Domains and sub-domain disciplines. Here are some examples: enterprise business architect, enterprise documentational architect, enterprise application architect, enterprise infrastructure architect, enterprise information architect, etc.

An example of the list of reference architecture patterns in the application and information architecture domains are available at Architectural pattern (computer science).

A view model is a framework, which defines the set of views or approaches to be used in systems analysis or systems design or the construction of an enterprise architecture.

Since the early 1990s there have been a number of efforts to define standard approaches for describing and analyzing system architectures. Many of the recent Enterprise Architecture frameworks have some kind of set of views defined, but these sets are not always called "view models".

A first important standard in the field of software architecture and system architecture is IEEE 1471, an IEEE Standard for describing the architecture of a software-intensive system approved in 2000. This standard has been adopted by the International Organization for Standardization (ISO) and published as ISO/IEC 42010:2007, still identical to the IEEE 1471:2000. In 2006 a technical committee of the ISO launched a revision of this standard, now published as ISO/IEC/IEEE 42010:2011.

ISO/IEC/IEEE 42010 establishes common terminology for architecture framework and specifies requirements for standardization of frameworks. An architecture framework is defined as:

conventions, principles and practices for the description of architectures established within a specific domain of application and/or community of stakeholders

An architecture framework is specified by:

1. the relevant stakeholders in the domain,
2. the types of concerns arising in that domain,
3. architecture viewpoints framing those concerns and
4. correspondence rules integrating those viewpoints cited before.

Frameworks conforming to the standard can include methods, tools, definitions, methods and other practices beyond those specified.

• EABOK (The Guide to the Enterprise Architecture Body of Knowledge) – a U.S. Federal-funded guide to EA in the context of legislative and strategic business requirements.
• Generalised Enterprise Reference Architecture and Methodology (GERAM)
• IDEAS Group – a four-nation effort to develop a common ontology for architecture interoperability
• RM-ODP – the Reference Model of Open Distributed Processing (ITU-T Rec. X.901-X.904 | ISO/IEC 10746) defines an enterprise architecture framework for structuring the specifications of open distributed systems.
• TOGAF – The Open Group Architecture Framework – a widely used framework including an architectural Development Method and standards for describing various types of architecture.
• Good enough architecture methodology – a methodology based on experiences, results and best-practices gathered through real-life implementations of various building blocks that altogether provide a realizable architecture and working solutions.
• ARCON – A Reference Architecture for Collaborative Networks – not focused on a single enterprise but rather on networks of enterprises^[14][15]
• Dragon1 - An open Visual Enterprise Architecture Method recently recognized by The Open Group as Architecture Framework

Enterprise architecture frameworks that are released as open source:

• TRAK – a general systems-oriented framework based on MODAF 1.2 and released under GPL/GFDL.
• MEGAF is an infrastructure for realizing architecture frameworks that conform to the definition of architecture framework provided in ISO/IEC/IEEE 42010.
• Praxeme, an open enterprise methodology, contains an enterprise architecture framework called the Enterprise System Topology (EST)
• GOD, a generalist observation methodology, contains an enterprise architecture framework based on observation, an innovative certified approach provided in the SDFL Department of DUJ.
• SABSA is an open framework and methodology for Enterprise Security Architecture and Service Management, that is risk based and focuses on integrating security into business and IT management.
• LEAD Frameworks. LEAD is an abbreviation for Layered Enterprise Architecture Development and is the only community-driven open source EA framework built upon international standards that is in use today. LEAD consists of frameworks, methods, and approaches that are all integrated with to each other and with supporting maps, matrices, and models.

• Avancier Methods (AM) Processes and documentation advice for enterprise and solution architects, supported by training and certification.
• Solution Architecting Mechanism (SAM) – A coherent architecture framework consisting of a set of integral modules.^[16]
• Integrated Architecture Framework (IAF) – from Capgemini company in 1993
• CLEAR Framework for Enterprise Architecture – Atos Origin's Enterprise Architecture Framework
• OBASHI – the OBASHI Business & IT methodology and framework
• Information FrameWork (IFW) – conceived by Roger Evernden in 1996
• SAP Enterprise Architecture Framework
• Zachman Framework – an architecture framework, based on the work of John Zachman at IBM in the 1980s
• ASSIMPLER Framework – an architecture framework, based on the work of Mandar Vanarse at Wipro in 2002

• DoDAF – the US Department of Defense Architecture Framework
• MODAF – the UK Ministry of Defence Architecture Framework
• NAF – the NATO Architecture Framework
• AGATE – the France DGA Architecture Framework
• DNDAF – the DND/CF Architecture Framework (CAN)
• The LEAD Architecture Framework for Defense

• European Space Agency Architectural Framework (ESAAF) - a framework for European space-based Systems of Systems ^[17][18]
• Government Enterprise Architecture (GEA) – a common framework legislated for use by departments of the Queensland Government
• FDIC Enterprise Architecture Framework
• Federal Enterprise Architecture Framework (FEAF) – a framework produced in 1999 by the US Federal CIO Council for use within the US Government, not to be confused with the 2002 Federal Enterprise Architecture (FEA) guidance on categorizing and grouping IT investments, issued by the US Federal Office of Management and Budget
• NIST Enterprise Architecture Model
• Treasury Enterprise Architecture Framework (TEAF) – a framework for treasury, published by the US Department of the Treasury in July 2000.^[19]
• Nederlandse Overheid Referentie Architectuur (NORA) – a reference framework from the Dutch Government E-overheid NORA
• The LEAD Architecture Framework for Government

• The LEAD Architecture Framework for Insurance

• The LEAD Architecture Framework for Banking

• The LEAD Architecture Framework for Transport

Template:Wikipedia books

Wikimedia Commons has media related to Enterprise architecture.

• Architecture patterns (EA reference architecture)
• Enterprise architecture
• Enterprise architecture planning
• Enterprise engineering
• ISO/IEC/IEEE 42010
• Reference architecture