What is the overall enterprise architecture? What’s the use? How do you do that? Let’s take a look at the case of the company I worked for.

At that time, the company had 200 r&d personnel and more than 200 servers. When I first joined the company, the system could not play any more. There were always various problems.

After I joined the company, my main task was to upgrade and transform the system. I spent one and a half months to write a 124-page document on the overall architecture of the enterprise, which directly guided the subsequent technical transformation. The following figure is the contents of that document, and the download address of relevant materials is at the end of the article.

Enterprise business model

The content of enterprise business model mainly includes main business, business model, business subject, competitive product analysis, organizational structure, business operation model and business process, etc.

The main business is what the company does.

A business model is how a company makes money.

A business entity is a group of people who do the business together.

Competitive product analysis is to understand the situation of competitors.

Organizational structure refers to how the company is divided into departments. The number of people is marked in the organizational structure chart. According to the corresponding relationship between the system and the business, which modules in the system are frequently used and the complexity of the business and its corresponding modules can be understood.

The business operation model refers to how the company operates. We make plans before sales, find suppliers to buy things, and sell them to our dealers and purchasers after service and settlement, so that we can make profits. After sales, we conduct big data analysis, and finally guide our pre-sales, forming a virtuous cycle.

Think of a company as a machine that puts money in and turns it around to generate more money.

Finally, the business process and attached documents, business process including booking process, order processing process, product supply process, financial settlement process, account management process. The establishment of enterprise business model guides the establishment of the whole application system model, which is the foundation and premise of the construction of the entire application system, after all, the application system is to serve the business.

Present situation of architecture

Architecture status includes functional architecture, application architecture, data design and physical architecture.

Functional architecture

The functional architecture consists of three parts: functions, roles, and permissions. A function is an enterprise service. Every function used by a user is an enterprise service. Roles are categories of user operations. The corresponding relationship between functions and roles is rights. Understand the state of the system architecture, starting with the functional architecture.

Application architecture

The application is the processor, and the application architecture includes the existing architecture diagram, the current state of Web applications, the current state of Job applications and the interface architecture. Among them, interface is the key of the application layer, which is the part where one program interacts with another program.

The application architecture diagram lists which business logic is not reused. In other words, the business logic needs to be repeatedly developed for as many applications as it is called. Once one place is changed, many places have to be changed at the same time, resulting in inefficient system development.

Business logic, such as subscription logic, is called by multiple applications, but they are not related to the application. Business logic can exist independently or host in multiple applications. Business logic is an abstraction of business operations that business applications and business departments perform together.

Data design

More than 100 databases, more than 10,000 tables, can use an E-R graph to represent? It’s ok.

Data design depends on enterprise data, rather than database design. Proper classification of enterprise data will directly lead to data design, and finally draw e-R graph. After data design is completed, database design will naturally come out.

If you look at this E-R chart, you can see that it includes five categories of data: product, order, settlement, user, and infrastructure. The low-level E-R diagram can change, but the high-level E-R diagram generally doesn’t change, because it depends on your business model, and the business model is stable, and the high-level E-R diagram is stable.

As long as the early design of the database is good, it can do easy to scale, easy to split. From the inside out, a box can be a library, a module, or a table.

It can be a library with 5 modules in the early stage of business development, 5 libraries in the middle stage, and more libraries at lower levels in the later stage, depending on the business stage and system complexity. After the design of the data is complete, the design of the database is easy to plan and adjust.

The above is the static relationship between database and data table. Next, we introduce the flow state of data, namely the state diagram. To understand the changes of existing data flow through data state graph, such as the change of domestic order state graph, the value of this graph lies not only in the database layer, but also in servitization.

In the figure, there is a payment action between waiting for payment and payment success, through which the data state is changed to payment success, otherwise continue to wait until the order is closed due to timeout. This payment can be made into a microservice, which can then be invoked by different applications.

Physical architecture

The physical architecture includes the IDC equipment room, access relationships between equipment rooms, physical server deployment diagram, equipment room and service distribution, website architecture, database architecture, cluster list, and domain name list.

Putting this together in lists and graphs makes it easy to understand and discover problems, which is where the value of tables and diagrams comes in, especially in terms of the global architecture.

At that time, the company had only 200 servers in five regions and eight computer rooms, but they were distributed widely, resulting in complicated physical structure and communication. One of the main reasons for the continuous failure before the technical transformation is the unreasonable physical structure. 60% or 70% of the responsibility for operation and maintenance is attributed to the application architecture, which is a wrong direction.

The physical architecture is unreasonable, and the application architecture is difficult to be reasonable, because the physical architecture is our infrastructure, located at the bottom, and the lower layer serves the upper layer. Operation and maintenance should serve the application, the application should serve the business, and the business should serve the customers.

The domain model

Domain models focus on concepts, on responsibilities, on boundaries, and on interactions. Interactions are not clear until responsibilities and boundaries are defined. Domain model is to propose a system solution for the existing problem domain, and then establish a complete model on the chart, just like the construction drawings drawn with AutoCAD.

Domain models are part of the outline design phase. For the design of a single application architecture, business and functional requirements, use-case diagrams, use-case activity diagrams, and domain models should be understood first. Business process diagrams are abstractions of business operations and domain diagrams are abstractions of business logic code.

The establishment of domain vocabulary is the first step in the establishment of domain model, which can unify terms and define concepts to reduce polysemy and polysemy. Once the concept is identified, its properties and behavior are extended, and then it is constructed as a unit with other things, it is easy to form a model. The domain model has a reference correspondence with the business flow chart in the enterprise business model.

The domain model can be large or small when implemented, and in the early days of the business, when the system is small, it can be a class. As the system grows, it may be a DLL library. On a larger scale, it might be a service to be called by different applications.

Each approach has the potential to become a service, especially in the middle and late stages of the system. The domain model is the construction drawing of the business logic code, which not only helps to understand the business logic of the current system, but also guides the architectural transformation of the future.

Architecture planning

After we understand the business, understand the current situation of the architecture, and find the problems of the existing architecture, we can make mid – and long-term architecture planning, as well as the adjustment and concrete implementation of the architecture. Architecture planning includes top-level architecture planning, website function planning, application planning, SOA planning, hierarchical architecture planning, database planning and physical planning, etc.

Top-level architecture planning

Above is a top and side view of the top-level architecture. The first picture is an overhead view, sitting on an airplane, of the entire top-level architecture with functions in the outermost layer, business operations in the middle, and data in the inner layer.

Functions correspond to the user interface of the service system, operations correspond to the services of the service system, and data corresponds to the data stores of the service system, such as databases.

The second diagram is a cross section, with applications at the top, services and frameworks at the middle, and infrastructure data centers at the bottom. As you can see from the service layer in the figure, the categorization of services is closely related to the categorization of business processes.

Website function planning

Website function planning is the re-division of functions, compared with the current status of the architecture, how to adjust the future function? For example, in the case of the function planning of the domestic website, the global function map, buyer function map, platform function map and supplier function map are drawn respectively.

In fact, when doing website function planning, more need to consider the status quo, rather than future adjustment, if there is no big problem, do not adjust, respect history. Because some things (like names) have been used by users for a long time, it is often difficult to adjust and reasonable rather than accurate.

Application of planning

What is the system? System = element + relationship. What is the application architecture? Application architecture = Application + Architecture. Application is the smallest unit of the system, and application classification and application number constitute the application relationship, that is, the application architecture.

As shown in the case above, the application category created framework FX and common business system CBS. These two product lines were not included in the original 200 applications, but distributed in different business lines, resulting in repeated construction.

The application number is assigned to each application with a six-digit numeric ID, just like our ID card. The first two digits represent the product line, the middle two represent the subsystem, and the last two represent the application, such as 100206. Application numbers are fundamental to application management, dependency, and tracking, and are used in centralized logging and monitoring frameworks.

SOA planning

SOA planning is interface planning and its categorization has reference correspondence to business processes in the business model. The above example has five service centers: reservation service, order processing service, product supply service, financial settlement service, and public service.

Each service only needs to implement a set of its own logic, which can be called by our foreground, background, interface, job applets, etc. The logic of the service is consistent with our business logic. When modifying the code, only one place needs to be changed to affect all the front-end applications that call the service.

Layered architecture

Layered architecture seems simple, but ensuring a uniform layered architecture across the r&d center is not. So how do you do that to make writing code more efficient and keeping the project consistent?

Firstly, I will briefly introduce two popular hierarchical architecture systems. One is domain architecture: Repository Layer, Domain Layer, Application Layer, Presentation Layer and Infrastructure Layer See below.

The other is a relatively traditional three layers: Data Layer, Business Layer and Presentation Layer, as shown in the figure below.

What is the difference between domain architecture and three-tier architecture? In our opinion, in the early stage of three-tier architecture, most of us were driven by tables, while in the domain architecture, most of us were driven by business logic. The difference between the two is quite obvious.

But now, if both are centered on business logic, the two are essentially the same. At that time, my company adopted the second method of layering, and we wanted to keep layering to a minimum, which meant that even people who had just graduated from the company would basically not mess with layering.

Compared with the first method, the second method is much simpler. The amount of code in each application should not be too large, and when the project becomes too large, we break it up properly rather than putting it all into a single application.

In summary, I believe that the simpler the layering, the clearer the overall software structure and the easier it is to unify the code. Make the project extremely simple, is conducive to replication, is conducive to the rapid construction of business, is conducive to scale, stable and reliable.

Database Planning

Database is the longest life cycle in the whole information system, the most difficult to modify the part, so to strengthen planning. The design of the database should be at least two steps in advance. It is better to build a new database early than late based on the high-level E-R diagram and data design.

The cost of database adjustment is high, the cycle is long, and the problems caused by a long time need to be solved for a long time. Solve the new table in the new database first, and then adjust the old table gradually according to the needs of the current business and application.

Physical planning

Physical architecture planning includes cluster planning and domain name planning. The first is cluster planning.

20x planning, 5x design and 1.5x implementation: Plan and design larger, but implement smaller, which not only facilitates future expansion, but also saves money today.

Two logical networks: one Intranet and one extranet, two load balancers, two firewalls, security isolation of extranet.

There are four product lines: international, domestic, new business, and common business. Common business, such as single sign-on and enterprise payment gateway, are also in one product line.

Six clusters: Web cluster, SOA cluster, middleware cluster, database cluster, Job cluster, and ITD cluster.

The above horizontal clusters and vertical product lines form a matrix structure, which basically determines the network infrastructure. Domain name planning. The internal domain name should be changed, the outage of the outage, the merge of the merge. The external domain name should be changed as little as possible. If it is to be changed, it should have historical inheritance (such as jump) and minimize the impact on users.

other

In addition to the above architecture planning, there are other important items such as source code management planning, document management planning, technology selection, and team division. Why do all this? Because of the unification of how to put the source code, how to put the documents of each department, what tool version to use in the future, only conducive to team collaboration, based on the unification of the environment can have a higher level of promotion.

For team division of labor, it is necessary to gradually align the organizational structure with the system architecture planning. For the selection of technology, we need to pay attention to the introduction of middleware, to have a rhythm, the force should be relatively concentrated, to small-scale pilot, find non-core projects, and then large-scale promotion after successful trial.

Architecture to implement

After finishing the architecture planning, it is the implementation of the architecture. Our overall framework implementation ideas are: tree target, map, set example, focus, build culture, build system, whole environment, set up the framework department.

The architecture department recruits a few veteran programmers and a few architects. Go out inside and raise your sights. External cattle people please come in, landing to understand the history and business. The technical suggestions are: SOA as a service, infrastructure as a platform, common business as a service, strengthen the project profile design.

When the R&D team reached more than 200 people and had hundreds of applications, and in the case of continuous failures, we could not start coding without design as before, but to strengthen the project outline design and review. The back of the supplement and the front of the defense, both hands must grasp, both hands must be hard.

Specific plan is: Roadmap step by step implementation, transform phase 1, transform phase 2, transform phase 3, near fine far thick, seek truth from facts, gradually refine, gradually perfect. Constantly establish technical transformation projects, constantly combine technical transformation with business research and development projects, technical transformation is work order, work order is technical transformation. Avoid too much impact on the business, and continue to have business value output, this is the key to the sustainable implementation of architecture transformation!

The above briefly introduces the writing method of the overall architecture. Our writing idea is to first understand the business and establish the enterprise business model, which mainly includes static business subject, organizational structure and dynamic business operation model and business process.

Then understand the architecture status, establish the existing information system model, mainly including functional architecture, application architecture, data design and physical architecture. One is business, one is electronic, the two are the whole company’s electronic commerce system.

Then, the domain model is established based on the enterprise business model and the existing system model. The domain model is relatively stable and directly guides the following architecture planning. Finally, it must be implemented.

The attached file is a real case after removing sensitive information, and its value is as follows:

  • The Big Picture serves as a direction and guidance.
  • Will recessive knowledge explicit, convenient communication, widely advertised.
  • Value for new hires, quick start.
  • For the value of senior employees, understand the big picture, process comb, and then focus on your part.

For the overall enterprise architecture, you can refer to the standard TOGAF(Open Group Architecture Framework). In fact, we didn’t know about TOGAF until we finished that document, and there are many similarities and differences between them.

The content of TOGAF mainly includes business architecture, application architecture, data architecture and technical architecture. At that time, we were just oriented to solve the problems of corporate system architecture and took time as the main line. The content included enterprise business model, architecture status, domain model, architecture planning and architecture implementation.

Methodology is important, but it is more important to see things as they are, to look into problems and find solutions. Welcome to like and pat brick!

Case Reference:

Github.com/das2017/Top…

The list of topics covered in this series (not published in that order) is as follows. If you are interested, please follow:

  • Introduction: Small and medium-sized R&D team architecture practice three points
  • Cache Redis: Quick start and application of Redis
  • Message queue RabbitMQ: How to use the good news queue RabbitMQ?
  • Centralized log ELK: A centralized log ELK of architectural practices for small and medium r&d teams
  • Task scheduling Job: Task scheduling Job in the architectural practice of small and medium-sized R&D teams
  • Metrics: What does app monitoring do?
  • Microservices Framework MSA: This is what you want. NET stack microservice architecture practice
  • Solr
  • Distributed coordinator ZooKeeper
  • Gadgets: Dapper.NET/EmitMapper/AutoMapper/Autofac/NuGet
  • Release tool Jenkins
  • Overall architecture design: How to do e-commerce enterprise overall architecture?
  • Single project architecture design
  • Uniform application layering: How to standardize all application layering in a company?
  • Debugging tool WinDbg
  • Single sign-on (sso)
  • Enterprise Payment Gateway
  • “Article

The authors introduce

Zhang Huiqing, an IT veteran of more than 10 years, has successively served as architect of Ctrip, chief architect of Gooda Group, CTO of Zhongqing E-Travel and led the upgrading and transformation of the technical architecture of the two companies. Focus on architecture and engineering efficiency, technology and business matching and integration, technology value and innovation.

Thanks to Yuta Tian guang for correcting this article.