The enterprise architecture method has always emphasized the comprehensive and positive design of the organization’s business, application, data, and technical architecture, so as to achieve the alignment of organizational strategy and business, as well as the alignment of business and IT. But many projects are difficult to truly achieve this. There are three reasons:
The theory of architecture is not in place. Learning TOGAF helps to establish architectural thinking, but it is far from enough. Even if you pass the TOGAF accreditation level, you need to go through specific project implementation, constantly reflect on the content of TOGAF, and tailor and supplement it to gradually form a specific architectural project implementation method.
Lack of suitable landing methods and tools. The architecture emphasizes the forward design, and the business, application, data and technical architecture is a positive derivation from top to bottom, and a reverse relationship from bottom to top. This requires that at the beginning of the architecture project, it is necessary to plan the complete technical path of the architecture project, and design most of the tools and templates used in the project process, and ensure the logical relationship between the various architectures through the tools and templates. The inheritance between the various architecture domains is implemented.
Need higher ability of project implementation consultant. Regardless of the boundary and scope of the architecture project, the architecture implementation consultant is required to have a global mindset, understand both business and IT, be able to build logical blueprints and dig into the details in depth. Some also need background knowledge and skills experience in the industry in which the project is located.
We did not hope that through an article or a video, we can comprehensively improve the capabilities of the architect. In fact, both the sublimation of the framework theory and the improvement of personal abilities require continuous training in practice. In layman’s terms, the more pits that jump in, the better the ability to jump out. However, there are still methods and tools for architecture forward design, and these tools can be used for reference and can be used for reference in all walks of life.
The company introduced today is a typical product research and development company, mainly engaged in the research and development of large and complex products. As we all know, the research and development process of complex products must continuously verify the correctness of the research and development theory through simulation, calculation and experiment, ensure that the design results meet the original requirements, and master the final performance indicators of the product. Product research and development and testing are closely coupled, and a large number of three-dimensional digital collaborative design and manufacturing technologies, model-based system engineering (MBSE) technologies and digital simulation computing technologies are used in the process.
The feature of this project is that the business architecture, application architecture, data architecture and technical architecture have been comprehensively constructed through architecture methods. Projects that comprehensively define the four architecture domains are rare. This kind of project needs to pay more attention to the logical derivation and verification relationship between each architecture domain.
We planned the connections between the various architecture domains in the project demonstration phase (see the figure below). Starting from the business architecture, the business components, business data interaction relationships and demand measurement models are defined; based on the functional scope of the business components and the current status of enterprise application integration, the application architecture is designed, and the information requirements catalog, business/data are given UC matrix, application portfolio catalog and application interaction relationship; based on the analysis of the data subject domain and data object of the business component, the data architecture is designed, and the conceptual data, data/application UC matrix, data/business UC matrix, and Analyze the definition of the data theme; finally define the technical architecture through the application system deployment of the application architecture and the data distribution of the data architecture, data frequency, etc., and form the platform decomposition diagram, technical standard catalog, technical pedigree catalog, application/technology matrix , Environment and location map, etc.
First, business structure
The main goal of business architecture work is to analyze the current business situation, identify existing business capabilities and problems, propose business improvement requirements, and design the target business architecture based on the corporate strategic vision. When the project sorts out the AS-IS business structure, it uses the 5W1H survey form to investigate information, while referring to the management program documents, according to the principle of business component aggregation, to sort out the current components, and to correspond the components to the development stage. At the same time, on the premise of sorting out business components, a flow chart is formed through the series connection of business components.
When designing the TO-BE business architecture, through business demand analysis and reference to external benchmarks, identify the business components that need to be improved or added to form an overall view of the future business components. For changed business components, the specific change requirements will be described in detail in the business architecture gap analysis section.
In the process of business architecture design, the tools and methods used include “5W1H Form”, “Business Architecture Gap Analysis Matrix”, etc., to provide input for application architecture, data architecture, opportunities and solutions, and migration planning.
Two, application architecture
The main goal of application architecture work is to design the target application architecture based on the current application architecture requirements of the enterprise and the data flow analysis results in the business architecture. The design of the application architecture originated from the informatization requirements in the 5W1H business survey form (this is an interface that is reserved during the design of the business architecture to guide the design of the application architecture). At the same time, combined with the five-element definition of business components, as well as on-site investigation of existing information systems to understand the status quo of informatization applications, the current application architecture can be obtained through analysis. The design relationship between business architecture and application architecture is shown in the figure below.
In order to further understand the application’s support to the business, it is necessary to analyze the correspondence between the combed AS-IS application architecture and the AS-IS business architecture, to understand the current information support situation, and the situation where there is no information support, for the design Input of TO-BE application components.
When designing the TO-BE application architecture, it is necessary to collect information requirements and perform functional analysis and sorting. At the same time, use the business/data UC matrix for application boundary division and data flow design.
In the application architecture design process, the tools and methods used include “Business/Data UC Matrix”, “Application Architecture Gap Analysis Matrix”, etc., to provide input for data architecture, technical architecture, opportunities and solutions, and migration planning.
Three, data architecture
The main goal of data architecture work is to design a target data architecture based on the current data architecture requirements of the enterprise and the data flow in the business architecture.
There are four steps to determine the AS-IS data structure, including research on existing business, sorting out the indicators involved in the business, and forming thematic analysis data; determining the business data in the AS-IS data structure through the data categories in the business/data UC matrix; The master data is the core of the basic data, and the master data is determined according to the characteristics of the master data. Analyze the attributes of the master data and determine the metadata of the master data. Determine the coded data according to the coding rules of the main data; finally form the AS-IS data structure diagram.
Designing the TO-BE data architecture is also divided into four steps, including defining the TO-BE subject analysis data category according to the indicator system; according to the business data requirements in the 5W1H survey, and combining the business data in the AS-IS data architecture to determine the TO- The business data in the BE data architecture; the basic data remains relatively stable without major changes in the business data; the TO-BE data architecture diagram is finally derived.
Based on the determination of the TO-BE data structure and the AS-IS data structure, the gap analysis matrix is used to compare the AS-IS data structure and the TO-BE data structure to determine the gap and provide input for opportunities, solutions, and migration planning.
Four, technical architecture
The main goal of the technical architecture work is to design the target technical architecture based on the current technical architecture, technical standards, and business/application/data architecture requirements. Sort out the AS-IS technical architecture to form a platform breakdown map and technical pedigree catalog.
The platform breakdown diagram mainly describes the technical platform that supports the operation of the information system architecture. The diagram covers all aspects of the infrastructure platform and provides an overview of the organization’s technical platform. The technology pedigree catalog is to identify and maintain a list of all technologies in use by the organization, including hardware, infrastructure software, and application software. The technical pedigree catalog is the basis on which the remaining matrices and graphs are built.
When designing the TO-BE technical architecture, on the basis of the AS-IS technical architecture, focus on adding new business scenarios or application support, the required technical solutions (software and hardware, network, etc.), and the basic equipment required after the operating cycle Design the technical architecture of TO-BE.
5. Opportunity solutions and migration planning
The main goal of the opportunity solution and migration planning work is to analyze the gap analysis proposed by the business architecture, information system architecture and technical architecture, design work packages, and identify the interaction of work packages and resource requirements, determine priorities, and design migration planning routes.
Define the work package based on the results of the gap analysis, collect and summarize the gap analysis results of the business architecture, application architecture, data architecture, and technical architecture, and consider implementation constraints (including corporate strategy, resource constraints, resistance to change, etc.), and then analyze the gap The results are reviewed and merged to form a work package.
When determining the migration plan, it is necessary to first perform a dependency analysis and perform a work package resource assessment. According to the migration planning template, in the migration planning plan, it is necessary to clarify the person in charge of the work package, the preconditions and the specific implementation path. As an input for future implementation of governance. To
Based on the TOGAF enterprise architecture methodology, this project completed the business architecture, application architecture, data architecture and technical architecture for test business scenarios, formulated opportunity solutions and migration plans, and completed the entire process of architecture design in accordance with TOGAF theoretical methods. Architecture practice provides a powerful practical case. The architectural artifacts defined in TOGAF completed in the project are shown in the figure below.
If you want to know more about the detailed technical path, implementation process, architecture products and other content of this project, please pay attention to the enterprise architecture practice case series courses.
Author: Digital Business Cloud Classroom
Source: Brief Book
The copyright belongs to the author. For commercial reprints, please contact the author for authorization, and for non-commercial reprints, please indicate the source.