Enterprise architecture training comprehension

I. Introduction

Many companies hope to be able to do digital transformation, but when it comes to the specific start, they feel that their eyes are smeared and they don't know how to start. This training explained to us how to implement the strategy through the methodology of TOGAF.

 

2. Why is enterprise architecture so important?

As software development engineers, we are always used to working hard and conscientiously to complete the development tasks assigned to us on time and with high quality. If there is a business-oriented development, we will first ask the business to understand the specific demand background and want to solve it before accepting the demand. business problem, which is not easy.

So why do you need to solve this business problem? What does it have to do with the company's business strategy? Or how does the business strategy of the enterprise correspond to our daily development work layer by layer? As a qualified architect, whether it is business architecture, technical architecture or application architecture, this is a basic fact that must be known. My understanding is that TOGAF is the method that effectively maps the corporate strategy to the IT system level. Its connotation is to emphasize the alignment between IT and business, and implement the strategic plan by establishing an enterprise architecture to ensure that the planning of the architecture is driven and led by the business. After the architecture is implemented, business goals can be achieved; this is the same principle as our goal management. It is through top-down decomposition of goals, and only top-down decomposition can ensure that IT actions closely correspond to business goals.

TOGAF9.2, as the standard of enterprise architecture, includes the following four architectures (as shown in the figure below), among which I would like to discuss some of my understanding of business architecture (BA) and application architecture (AA).

1. Business Architect

2. Data Architecture (Data Architect)

3. Application Architect

4. Technology Architecture (Technology Architect)

 

3. Business Architecture (BA)

First of all, in TOGAF methodology, the business architecture is an intermediate key link in the business strategy and technology connection. It clearly defines the corporate governance structure, business capabilities, business processes and business data. Among them, the business capability defines what the enterprise does, and the business process defines how the enterprise does it.

In the scope of clarifying business capabilities, business architects need to determine the driving factors and business goals for implementing this business strategy through policy research, high-level interviews, and peer research, that is, what the company should do to achieve this business strategy . Then, the business process clarifies the positioning and responsibilities of each department in the process, specific business rules, business data flow and other dimensions of information. Since enterprise architecture is the embodiment of an enterprise's cognition of market information, business architecture (BA) is a specific methodology for realizing or implementing this embodiment.

Why do I say that? For example, in the first few years of the company, the first thing the company did was to survive, and then what happened? The construction of all systems is based on urgent needs first, and high-level requirements such as data sharing or function reuse between systems are discussed in vain, which leads to a lot of chimneys, which is our current status quo. However, with the increase of new chimneys and the further consolidation of old chimneys, demand delivery will show a downward trend with the increase of functional complexity and cross-team communication costs. At this time, it will gradually fail to keep up with the business rhythm. At this time, the business function (or business strategy) may remain largely unchanged, but with the expansion of the scale, the original business process may no longer be suitable. This is the time when the business architecture (BA) starts to exert its capabilities up. At this time, it needs to redefine or adjust new business processes according to the actual situation of the enterprise (such as changes in organizational structure and processes) in order to better adapt to or support the business.

For example, several business lines that I am in charge of have been developing in the direction of diversion in recent years. The business processes of each business line are basically the same. The more different point may be that the information that needs to be collected is inconsistent. Or the channel display style is inconsistent. The R&D side will also find that the general process can be reused, so they think it can be built together, but the business side will also have its own ideas (such as exclusive resources, different styles, etc.), which is true in itself. After all, every business Each line also memorizes its own KPI, so it must be the safest to do it according to your own business concept, even if the indicators are not met, you will accept your fate (I admit the pit I dug myself while crying). But how does this solve the conflict between resource reuse and resource exclusiveness? Is there no way? According to the method of business architecture (BA), it should be clearly defined from the business process level how to seek common ground while reserving differences or how to manage the three business lines segmentally, and communicate with the leadership to get full understanding and approval. Once this newly adjusted business process is in place, the R&D side can have more traces (principles) to follow during system development, so that the R&D efficiency can be improved, and the mid-platformization based on the goal of maximizing reuse can be implemented more smoothly.

 

4. Application Architecture (AA)

First of all, as Mr. Wen said, the application architecture here does not refer to the architecture of the application system, but a description of a group of application systems and their interrelationships, which is used to define the systems that need to be used to support a certain type of business , which is relatively macroscopic than our usual system architecture, because it does not focus on the internal implementation of a single application system.

Remember the process of application architecture design?

First of all, the application architecture needs to define specific business requirements from the business functions and processes in the business architecture blueprint. I'll expand a bit here. As an application architecture, I think it is necessary to start from the essence of the business. First of all what is architecture? The purpose of architecture is to address the concerns of stakeholders. The left picture below is taken from "Software System Architecture: Using Viewpoints and Perspectives to Collaborate with Stakeholders". I try to use the brain map (right picture) to decompose. Each system is actually designed to meet a series of needs of stakeholders, specifically through a series of elements in the system architecture, such as a bunch of architectural perspectives (viewpoints) presented by those -ability, business function points and their interrelationships To satisfy each concern of stakeholders respectively. Going back to the category of application architecture, the business blueprint is actually the overall strategy of the enterprise, that is, the overall requirements. Therefore, it is inevitable to delineate the scope from the business blueprint, because starting from here can ensure that the needs of all stakeholders are met.

 

Next, the application architecture needs to analyze what system needs to be provided based on business functions and processes; in fact, what we are told here is what system needs to carry what functions, but the size is at the system level rather than the service level.

Then, according to a certain methodology, all the functions are classified and assigned to the corresponding system; what is to be expressed here is the methodology of domain-driven design (DDD) combined with business, and the same type of business needs to be merged and processed to make The service layer has high cohesion and low coupling.

Finally, formulate the interaction mode between systems for each system, divide the service granularity, etc. Here is the category of system architecture, because it involves the granular division of system services and the corresponding technical implementation details.

From the above, it seems that this is the methodology to guide the construction of the business center. Why do I say this? We can take some of the systems we are in charge of as an example. When we were working on the system before, we adopted the strategy of urgent use first and developed a bunch of systems first. However, when it developed to a certain scale, the business felt that it needed refined and standardized management. Therefore, we have to prepare for a unified customer management system; the functions of the various systems of the entire company overlap and overlap to a certain extent, and internal coordination has become a big problem. During the whole process, we felt like we were fighting a local informatization war. If you have a headache, you will treat your head and feet, and you will use whatever system you need to solve. In the end, a so-called chimney-style system architecture was formed, which in turn led to the entire Architecture repeats the wheel, and cross-system management also causes unnecessary waste of time and energy for operators.

My understanding is that China-Taiwan is strictly a business strategy. Please take a closer look to see if this is the case. First of all, the enterprise structure is the embodiment of the enterprise's cognition of market information, and the middle platform is the enterprise's continuous development process. The ability to respond quickly can only be solidified in the so-called business system by finding common ground in its various business processes and using it as a best practice. Oneness principle.

 

Five, afterword

After this day of enterprise architecture training, I really opened up a preliminary understanding of enterprise architecture, but how to further combine the current business and system status, and then further refine the business architecture (BA) and application architecture (AA) through the TOGAF methodology It is indeed a relatively high-level job. For the time being, it is true that I only understand the superficiality. Later, I may need to practice more in my daily work. Let me look at some best practices in the industry at the same time.

Guess you like

Origin blog.csdn.net/justyman/article/details/112299128