Introduction to Enterprise Architecture Framework

-
Through the development of enterprise architecture, we can see that after decades of development, the industry has emerged a lot of enterprise architecture and enterprise architecture framework theory. In this chapter, the author will select several major enterprise architecture and enterprise architecture frameworks to elaborate. It should be noted that although this chapter is named "Enterprise Architecture and Enterprise Architecture Framework", due to the characteristics of enterprise architecture, its true form varies greatly among different enterprises. Even the federal enterprise architecture provides only five Layer reference model only, so the summary of the enterprise architecture can not be carried out one by one, and as a method to guide the creation of enterprise architecture, that is, the enterprise architecture framework, due to its standardized features, will be the focus of this chapter's content. Of course, even if the enterprise architecture framework has its standard aspect, it does not mean that every enterprise needs to cut its feet, disregard its own real needs and characteristics, and forcefully copy these framework theories, so in real life, companies should follow their own needs. Appropriate tailoring of enterprise architecture frameworks, or even customizing several frameworks (eg TOGAF + Zachman), is the only way to create an enterprise architecture that is suitable for you.

Photo source: Visual Paradigm, the best TOGAF software

Similarities and Differences of Enterprise Architecture Framework

Because the contents of these enterprise architectures and enterprise architecture frameworks are too complex, and because of the high degree of abstraction, it may be more obscure to go directly deeper. Therefore, before entering into the theories of each enterprise architecture and enterprise architecture framework, we first apply these enterprise architecture framework theories. Compare them and look for their commonalities and differences so as to avoid seeing these theories split up and lose the mastery of these theoretical sources. Since the problems that these theories need to solve are essentially the same, they must have common.

Commonness of enterprise architecture framework

Although there are many types of enterprise architecture framework theory, its purpose is still to guide people to create an enterprise architecture that meets the characteristics of their own company, and what methods are used to maintain the enterprise architecture so that it is synchronized with the development of the enterprise. To achieve this goal, various enterprise architecture frameworks basically describe the methodology for creating enterprise architecture in the following two aspects:
  • The process of creating and maintaining an enterprise architecture is how to create an enterprise architecture and how to ensure the correct evolution of the enterprise architecture.
  • The description of the content of the enterprise architecture, that is, how the content of the enterprise architecture is classified, and what each category should contain.
In fact, the current development of enterprise architecture theory has gradually converged, and there are great differences and the same feeling. Essentially all enterprise architecture frameworks have a description of the process of creating an enterprise architecture. In these enterprise architecture frameworks, the life cycle of the enterprise architecture is described as a cyclic evolution process, and appropriate governance is also required in the evolution process to ensure that each evolution is in an orderly, Controlled environment. In the development of enterprise architecture, most framework theories also recommend using the enterprise architecture maturity model to assess the state of the enterprise architecture.

In each iteration of the cycle, each enterprise architecture framework basically adopts a similar approach to gradually improve the enterprise architecture:
  • First identify and define the goals, scope, and relevant stakeholders of this cycle.
  • Establish a baseline architecture that describes the current state of the enterprise in all areas (business, data, applications, and technologies).
  • Use the same description and define the target architecture according to the goals and scope of the cycle.
  • Using the gap analysis method, identify and summarize the differences between the current architecture and the target architecture.
  • According to the results of the gap analysis, the implementation of migration will be carried out with the consent of relevant stakeholders.
Regarding the contents of the enterprise architecture, although different enterprise architecture framework theories have different perspectives, their hierarchy of enterprise architecture content is generally consistent, basically from the following aspects (or at least the following aspects): Describe the enterprise architecture:
  • Business architecture
  • Data architecture
  • Application architecture
  • Technology Architecture
At the same time, although different enterprise architecture frameworks have different descriptions of the specific content of these levels, basically all framework theories use the perspectives of different stakeholders to summarize and classify the specific content of each level.

In addition to the commonality of architecture processes and content, almost all architectural framework theories emphasize the significance of corporate executives for the success of enterprise architecture. Since the enterprise architecture covers all aspects of the business from the business to the information system, it will involve most of the people in the company. If there is no determination and drive from the top management of the company, coordinating so many people is a huge problem in itself, which directly affects The success of an enterprise architecture. In addition, the thinking of the company's top management is often the strategy of the company's development, which is the source of the evolution of the company. Implementing these strategies at all levels of the enterprise and implementing it through information technology is the significance of the enterprise architecture.

Comparison of Major Enterprise Architecture Frameworks

Although the problems faced by the enterprise architecture framework theory are the same, but because of their historical background and R & D groups are different, so their application scope and focus point of view have a greater difference. This chapter will compare the four major enterprise architecture framework theories (Zachman, FEA, Gartner, TOGAF) as described in the "Comparison of the Top Four Enterprise Architecture Methodologies". It should be noted that since this article should be completed in 2007, TOGAF has not released the 9th edition. Therefore, the article's argument that TOGAF focuses on the architectural process without the description of the content of the architecture is currently inaccurate. The author will give amendments in the content.

Zachman Framework

Of these four frameworks, Zachman’s history is the oldest, but compared to the latter frameworks, the framework only provides a classification method for the content of the enterprise architecture, but there is no corresponding process for the creation of the enterprise architecture. description of. But as the first widely recognized enterprise architecture framework theory, Zachman first proposed a method of describing various aspects of an information system based on different stakeholders' perspectives, so that stakeholders who stand in different perspectives can target The construction of the information system uses the same description method to communicate, and this also points the direction for the development of various enterprise architecture framework theories. In the Zachman framework, the content of the enterprise architecture is abstracted into six aspects of information systems that are observed using six perspectives, and Zachman believes that when all these perspectives are complete for each aspect, the content of an enterprise architecture is complete.

FEA

As the earliest theory of enterprise architecture proposed by government departments and the practice, the development of FEA has a long history so far. Although there are articles saying that FEA is still in the infancy stage, the various methods proposed by it are still worth our while. To study. Unlike Zachman, which only provides an enterprise architecture content taxonomy framework, FEA not only has its own categorization of enterprise architecture content, but also has a fairly detailed description of the architecture process.

Strictly speaking, FEA is not a strict enterprise architecture framework, but a concrete example of an enterprise architecture with the US federal government as an objective object, compared with FEAF (Federal Enterprise Architecture Framework) that was born before it. It is a true enterprise architecture framework theory, but due to its exemplary role in the government's enterprise architecture, the various reference models and governance methods abstracted in FEA are more easily accepted than methodological FEAFs. In many cases, FEA is also seen as an enterprise architecture framework theory.Just because FEA is different from a general enterprise architecture framework theory, its specific content is relatively clear. For example, its classification of services includes services such as health services, education services, natural resources services, and homeland security services that have obvious governmental behavior. However, the architecture content classification method used by FEA is indeed worth learning. He first used the concept of services to identify, organize, and define the various service capabilities of the enterprise department in line-of-business units. These services are grouped into Enterprise Service and Segment Service according to the scope of their use. In this way, the various lines of business of the various departments of the federal government have been summarized, and the original functionally duplicated services have also been identified, thus contributing to the reuse of services. At the same time, for each service line or service capability, FEA is described in detail in terms of services, data, applications, and technologies. All of these levels of description are standardized in the FEA by means of a five-tier reference model, thereby establishing a uniform method for each department to describe its respective service capabilities.

In addition to the description of the content, FEA also provides guidance on the architecture of the enterprise architecture. From the perspective of FEA, each department first needs to describe the current and target architecture of the company through a five-tier reference model, and find the differences between reality and ideals based on the gap analysis and refine it into various implementation projects. After establishing investment and fund-raising strategies for these projects, these projects are implemented and managed in order to promote the development of the company and the evolution of the corporate structure.

The above definition of architecture content and the description of the architecture process are the core content of FEA. In addition, the federal enterprise architecture system also includes an enterprise architecture assessment framework (EAAF) to assess the integrity, use, and use of an enterprise's architecture. , as well as the Federal Transition Framework (FTF) used by OMB to identify and manage cross-departmental projects.

From this it can be seen that compared to Zachman, FEA contains not only the classification method for the content of the architecture, but also the description of the architecture process, and even the method for assessing the architectural level. Therefore, the FEA has the characteristics of an enterprise architecture framework. However, from the perspective of abstraction and versatility, the Zachman framework is undoubtedly a general architecture construction methodology, while FEA is more inclined to a best practice based on concrete examples.

TOGAF

(Photo source: Best TOGAF software, Visual Paradigm)

Unlike the above frameworks, since TOGAF aims to provide a standard method for the creation of enterprise architecture, he differs from Zachman only in the classification of the content of enterprise architecture, and it is also different from FEA as close to the US federal government. Organizational structure and practical services. Compared with them, TOGAF proposes a highly abstract methodology and does not depend on any specific organizational form (for example, if you use FEA to create an enterprise architecture and may need to establish an OMB like the U.S. government does Coordinate the organization of management enterprise architecture, otherwise the framework such as FTF will be impossible to implement and manage), even he has no hard copy requirements for each method and content classification method proposed by himself, nor does he reject any other framework theory, so any Enterprises can tailor TOGAF or mix with other frameworks according to their own situation to create and maintain their own enterprise architecture.

The core of TOGAF is the Architecture Development Method (ADM). This set of methods is actually a set of process-oriented architecture development steps that are used to guide companies in how to establish and maintain their enterprise architecture. First, ADM sees the architectural process as a cyclical iterative process, and this iterative process can be hierarchical, ie, a company can use one team to implement the iterative development of the entire enterprise architecture, or multiple architecture development teams for each department. It is iteratively developed and eventually merged into one.

In TOGAF, ADM defines a total of ten steps. In addition to the "demand management" step is located in the center of each step as the drive and management method of other steps, the remaining nine steps are successively related, that is, the output of the previous step As an input to the following step. Similar to the spirit of the FEA process, ADM is also adhering to the following ideas to create and manage enterprise architecture:
  • Identify and define high-level strategies, goals, and driving forces.
  • Create high-level expectations for the architecture, which is the architectural vision.
  • Detailed architectural vision, detailed description of the business, data, applications and technologies, and gap analysis for the current architecture and target architecture described in the same way.
  • The results of the gap analysis will be transformed into solutions, and then a project plan will be formed.
  • Implement and manage these architectural projects.
  • Monitor changes in internal and external environments throughout all processes so that changes can be quickly reflected in the process of creating the architecture.
It can be seen that compared with FEA, the first two steps are equivalent to the target of the Performance Reference Model (PRM) in the FEA five-tier reference model, and the third step refinement coincides with the subsequent four-tier reference model in FEA. (Of course, the FEA five-layer reference model is not an architectural process concept, but the use of ADM does not exclude its use, and its core idea is the same). The subsequent gap analysis until the project's planning, implementation, and management is in line with the FEA's architecture process. Moreover, through the above steps, we can see that ADM adopts a top-down principle and gradually transitions the high-level strategy of the company to detailed technical implementation through a detailed and detailed approach, thereby building an enterprise architecture that covers all stakeholders. It should be noted that although the major steps in the ADM have a seemingly dependent relationship on the surface, this relationship is not rigidly defined. An enterprise can exchange the order of these steps according to their own needs, and even skip some of them. Steps, which are also advocated by TOGAF. In addition, in addition to defining these ten steps, ADM also defines in detail the input and output of each small step, target, and major step included in each major step.

In 2009, TOGAF introduced the 9th edition. In this version, The Open Group has added content framework (CF, Content Framework) to TOGAF. From then on, the enterprise architecture is not just a framework theory about the process of enterprise architecture. In the content framework, the enterprise architecture content is divided into three categories according to the form of presentation, matrix, and graphics, and the architecture products to be completed in each stage are defined according to the goals of the ADM at each stage. In addition, the content framework also describes in detail the relationship between the input and output of each step in the ADM and these architectural products.

The definition of architecture products in the content architecture constitutes the TOGAF meta-model of the architecture content. However, this meta-model is only a reference material. TOGAF does not recommend that it be strongly moved to the architecture practices of various companies or organizations. In order to achieve this flexibility, the content framework organizes content metamodels using plug-ins, that is, taking key and common architectural artifacts as the core content, and recommending them to the architecture practice process, while leaving the rest of the architectural artifacts. These are grouped into the grouping of governance extensions, service extensions, process modeling extensions, data extensions, infrastructure integration extensions, and motivation extensions, respectively. It should be noted that TOGAF only makes recommendations on the content of the architecture, even if the specific contents of the architecture products in the core groupings in practice should be customized according to the company's own needs.

It can be seen that TOGAF has more standard and more general characteristics than other framework theories, and since the addition of the TOGAF 9 kinds of content frameworks, the completeness of the enterprise architecture framework theory has also been greatly improved. Because of this, TOGAF The development has been the most widely used today, and it is the industry's most popular enterprise architecture framework theory.

In 2017, Visual Paradigm, a software company, introduced a TOGAF software called TOGAF Guide-through process that facilitates the development of Enterprise Architecture.regarded that as the 

Gartner

Unlike the above-mentioned enterprise architecture framework, Gartner does not provide a taxonomy of enterprise architecture content, nor does it provide guidelines for the process of building an enterprise architecture. From the perspective of the definition of an architectural framework, Gartner should not be considered a strictly enterprise architecture framework. theory. Gartner does not provide methodologies in the usual sense, but based on a large amount of practical experience accumulated in the field of enterprise architecture construction to provide various best practices on enterprise architecture. Therefore, if companies need to use Gartner's strengths to build their enterprise architecture, they will either invest in the purchase of their information services or build their own enterprise architecture based on several examples of enterprise architecture construction provided by Gartner.

Although there is no highly abstract and standardized general methodology to guide the construction of enterprise architecture, Gartner also has its own ideas and practical cases on the construction of enterprise architecture. Gartner sees enterprise architecture as a dynamic process, not just a static term. In Gartner's conception, the starting point of enterprise architecture construction should be the clear direction of the company's development direction, not just the description of the current state of the enterprise, and a successful enterprise architecture should be able to connect business owners, information experts, and technology implementers. Get up and provide them with a unified vision of the current status and direction of the company.

References:

Comments

Post a Comment

Popular posts from this blog

History of Enterprise Architecture

-
To learn any theory, I think the best way to get started is to explore its historical roots and development process, so as to clarify the true reasons for the theory, and to prevent readers from falling into the obscure vortex shared by various theories at first. Ultimately, even why the school is not clear. The same goes for learning about enterprise architecture and enterprise architecture framework theory. Enterprise architecture is a set of theories developed since the 1970s and 1980s. Many different theoretical frameworks for enterprise architecture have been derived during the development of these decades, and many large international companies and governments have In the process of repeated exploration, an enterprise architecture that meets their respective characteristics has been created, and the methodology on how to establish an enterprise architecture, the enterprise architecture framework, and the corresponding enterprise architecture tools have also been widely used in t...
Read more

Enterprise Architecture - Organizational Roles and Skills

-
Image
Scrum development will have three roles: PO, Scrum Master, and Development Team. What are the roles of the development enterprise architecture? What skills are required for each role to be able to take on the work of the architecture? This article describes the role and skill requirements in architecture development so that everyone knows who will do it when implementing TOGAF and what skills need to be improved or improved. Software development management is more complicated, and the development and management of the architecture is more complicated. Since there is no specific practice yet, for the time being there is no in-depth understanding and refinement of these contents. The following describes most of the framework capabilities framework from TOGAF . Emerging corporate architect role The role of the enterprise architect is described in TOGAF or Non-TOGAF: Extending Enterprise Architecture over RUP . Enterprise architects are thought leaders, visionaries, and industry ...
Read more

Enterprise Architecture Design Methodology - TOGAF

-
Image
The ADM method is composed of a set of stages arranged in a ring according to the architecture development order of the architecture field. Through these development stages, the designer can confirm whether or not the complex business requirements have been fully discussed. One of the most famous ADM infrastructure diagrams in TOGAF is as follows: The ADM method is applied iteratively throughout the architecture development process, between phases, and within each phase. In the entire life cycle of ADM, each phase needs to confirm the design results based on the original business requirements. This also includes some unique stages in the business process. Confirmation work requires review of the company's coverage, time frame, level of detail, plan, and milestones. Each stage should take into account the reuse of architectural assets (formerly ADM iterations, other frameworks, system models, industry models, etc.). Photo source: TOGAF management tool from Visual Paradig...
Read more