Chapter III Construction of Business In Taiwan

3.1 What business center

From the two dimensions of business operation mechanism and system development mechanism, the main content of the construction of business platform is developed.

3.1.1 Definition of Service Medium

== The business platform is divided into business domains to form a high-cohesion and low-coupling business-oriented capability center, and to create a continuously evolving enterprise-level business capability sharing service platform. The intuitive presentation of the business center is the ability center, common trading center, commodity center, inventory center, etc. It not only provides rich shared services, but also includes the methods and mechanisms of building enterprise capability domain. Business Center is not only a development and design platform for upper-layer applications, but also a platform for configuring, arranging, and expanding business objects, business capabilities, business rules, and business processes to complete enterprise resource operation and management. It provides a high concurrency and high availability execution environment for the stable operation of the upper application system.

• 1. Microservices are not the business medium
  • Microservice is a popular technology architecture nowadays, and the connotation of business middle platform is not only a technical architecture, but also a business architecture at the organizational level.
  • First of all, as a technical framework, zhongtai reflects the zhongtai system that this book focuses on, but in a broad sense, it is also a leapfrog enterprise organization management mode and concept. The central office is to build the front desk business of separation of powers on the basis of “centralization” and connect these businesses.
  • Secondly, the business in Taiwan combined with the thought of the overall planning of system theory, the system will be split in two directions of vertical and horizontal. It absorbs the vertical split application method of microservices “by business domain” and forms the capability center of “high cohesion and low coupling”.
  • Then, on the basis of vertical separation, the horizontal separation between the business center and the business application has created the sharing concept of the center, making it beyond the category of micro services.
  • The vertical split service in the middle platform reduces the coupling degree between fields. The horizontal isolation between the middle platform and the upper application promotes the cross-sharing of business and data among the applications, greatly reduces the repeated construction and investment, and thus creates the sustainable accumulation and operation of enterprise assets. Therefore, the middle platform has become a new infrastructure for enterprise digital-intelligence transformation
  • Therefore, microservices are not business center, but microservices and business center are not completely separate, and microservices are the best practice of building business center capability at the technical level.
• 2. The service console is not a foreground application
  • The foreground application consists of two parts: the foreground interaction interface and the foreground application service
  • Foreground application service refers to the function unit set of foreground interface providing back-end service interface
  • Generally, the service center does not directly face the foreground interface, but provides the foreground application service and provides the shared service interface
  • The functions provided by the foreground application service have application limitations and particularity. It is generally required to complete a specific business scenario
  • The business center, by contrast, does the common parts of multiple business scenarios, as well as mounting and executing extended functions for specific front-end businesses
  • Generally speaking, the front desk application service will arrange and transform the middle desk capabilities according to the special needs of the front desk business scenarios and then provide the front desk interface for use.
• 3. Business middle platform is the realization of general business mechanism
  • Service Center shared Service domain An important difference between foreground application services is that the service center implements the functions of the common part of the business scenario
  • This part of the general function is the combination of different front desk business, through the abstraction of the formation of the general business operation mechanism, to solve the problem of the common front desk business.
  • This general business operation mechanism is one of the core contents of the business center.
  • Zhongtai focuses on the abstraction and realization of general mechanism, so zhongtai has universality and inclusiveness. Combined with the configuration items that can be dynamically modified and the plug-ins that can be immediately expanded, the medium platform solves the problem of service personalization through the isolation of business space, that is, a set of common mechanism supports different services at the same time, thus further ensuring the openness of the medium platform.
  • The middle of the business relies on these two points to support the changing business landscape and ensure that the brand is not torn down and rebuilt

3.1.2 Main construction contents of business center

Business center focuses on the realization of general business operation mechanism and system open mechanism. Here, we split the business operation mechanism into four business elements: business objects, business capabilities, business rules, and business processes, and split the system open mechanism into business configuration and business isolation.

1. Business objects

Business objects include entity objects and procedure objects. Entity objects refer to specific enterprise resources, products and services, such as stores, users, customers, organizations, price policies and other tangible or intangible resources. Process objects mainly refer to the description of business actions in business activities. For example, “order” is a description of trading activities, and “statement” is a description of the profit process of multi-stakeholder bodies. They are all process objects.

2. Business ability

Business capabilities are abstract implementations of similar business functions and operations on business objects. Business capabilities can change the state of business objects and manipulate related business data by combining business rules. A single capability can support multiple functions. Ability to base HI structures and algorithms. Ability is the embodiment of the system endogenous mechanism. In different service scenarios, service capabilities can indirectly represent different application functions. For example, the ability of merchants to enter can correspond to the function of merchants’ independent registration, and the function of e-commerce platform background to actively open a merchant account.

3. Service rules

Business rules are business logic, definitions or descriptions of constraints used to control or influence business capabilities. In Taiwan, business rules and business capabilities are independent and implemented separately. Business rules affect the aggregation, transformation, and change of capabilities provided by capability centers and business data. For example, “the ability to create goods you” with “goods need to review” business rules, will produce “after the creation of goods, goods brand into the state to review, can only be released after the review”.

4. Business processes

A business process defines the sequence in which a series of business actions are executed to achieve a specific business purpose. Zhongtai designs different business engines for different business needs, such as transaction engine to deal with transaction related logic, promotion engine to be responsible for promotion related automation, and approval process engine to be responsible for the approval of business documents. Business engines and process definitions determine how execution is automated within and between capability centers. For example, through customizable transaction processes, business systems can realize both payment before delivery and delivery after payment. This kind of business is achieved not by changing the code, but by adjusting the business process so that the middle stage can change on demand.

5. Configure services

Business configurations are control points and extension points embedded in the mid-platform business logic. Through the visual configuration view, users can dynamically control the execution logic of the central console to ensure flexible service operation. For example, the user authentication extension point allows you to configure whether a user needs to be authenticated when placing an order. In the case of authentication, whether to use slider authentication, face authentication or other authentication methods, so as to dynamically control the service execution in the single order scenario.

6. Service isolation

As a shared service, the service center needs to support multiple foreground applications. On the basis of sharing, it is necessary to isolate foreground applications, so that foreground applications can execute personalized logic, and avoid interference with each other, and operate and develop independently. For example, when any foreground application adds functionality or changes its execution logic, we only need to perform regression tests on the foreground application as a whole, not the other foreground applications.

3.2 Architecture design and composition of the business center

For enterprises, to carry out business construction, the first need to carry out top-level architecture design. == The core architecture of the business middle stage is the architecture style of vertical segmentation and horizontal stratification. == In the longitudinal dimension, the domain of central Taiwan is divided to form the capability center of Central Taiwan; At the same time, in the horizontal dimension, according to the correlation between the business domain and the upper application, the business domain is stratified. Based on the hierarchical dependence of competency centers, different strategies can be adopted to design and construct competency centers at different levels. On the basis of determining the core architecture of the business center, we further introduce the key characteristics of the business center in the three stages of design state, management state and operation state from the perspective of software engineering, so as to guide the architecture design of the business center.

3.2.1 Core architecture of the Service center

The construction of enterprise business is a systematic project. The Centre has its own architecture. So how are the main architectural styles used in the middle stage? To sum up, it is vertical segmentation and horizontal sealing layer.

Vertical segmentation refers to the vertical segmentation of the business content of the enterprise according to the criteria of different fields and independent operation. After cutting the size of different, not rigorous multiple business fields, zhongtai from the technology of a series of analysis, abstraction, classification, deduction, to form in the business of independent operation, technology containing multiple micro services system. After the segmentation of each system, we generally called the center of capability in the middle. Such as the common member center, marketing center, trading center, inventory center, message center, certification center, process center, scheduling center, etc. Each capability center supports a different business domain, and all domain objects within it have a direct aggregation relationship with the business domain.

Horizontal stratification refers to the need to build on the foundation of vertical segmentation. For different business areas, the middle platform will be divided into business entity layer, business collaboration layer and business activity layer from bottom to top according to the different nature of its managed objects.



Note that the “horizontal layering” here focuses on the internal business center, while the “horizontal isolation” mentioned in Section 3.1.1 refers to the horizontal isolation at the level of the entire IT system, that is, the separation of the center from the foreground applications.

• Biz Entity Layer (BEL) : Consists of capability centers that manage static resources of the enterprise, located at the bottom of the three-tier model, such as goods, members, users, etc.
• Biz CollaBoration Layer (BCL) : The Biz CollaBoration Layer (BCL) consists of capability centers that manage enterprise resource usage policies. It is located in the middle of the three-layer model and acts as a link between the preceding and the following, such as the marketing policy center and the pricing policy center.
• Biz Activity Layer (BAL) : it is composed of the ability center to manage or implement the core business activities of the enterprise. It is located at the top of the three-layer model and can call the business capabilities of the lower two layers in real time to complete the execution of business activities, which is inferior to the trading center and settlement center.

Through horizontal stratification, the middle platform establishes the dependency relationship and data flow relationship between capability centers at different levels.

3.2.2 Contents of the Business Medium Platform System

From the point of view of software system engineering, the complete middle platform system consists of three stages: design state, management state and operation state.

1. The design state

The design business platform provides component platform and capability platform. The function of the building platform is to build applications quickly, and the function of the capability platform is to manage and use the capabilities of the central platform uniformly. Component platform can complete the registration, publishing, and access guidance of front-end and back-end components. Components include technical components and business components. Technical components encapsulate common technical capabilities; Business components encapsulate not only specific business logic, but also calls to mid-stage capabilities. The component platform provides component materials for the end-to-end construction of business applications, from creating applications, describing data models to assembling pages, and accelerates the construction of applications. The capability platform provides guidance for the registration, publication and access of capabilities. Through the capability platform, the users of the CTI system (including the users of the CTI capability, the providers of the CTI capability and the mechanism design of the CTI) can not only view the details of the capabilities of the CTI domain, but also summarize the invocation of statistical capabilities. An ability map is an embodiment of an ability platform.

2. The management mode

The middle stage of management mode should include demand management, schedule management, quality management, project management, configuration management and other aspects. Because the construction of central Taiwan is completed by the cooperation of many people and many roles, it needs to be promoted through a unified management platform. We generally implement demand management, schedule management and quality management commonly used in the software production process on the R&D service platform of the technology platform, see 5.2.2 for details. In the process of advancing the construction of the middle platform, the construction party also needs to strengthen the evaluation of the output of each stage, and through the recording of the evaluation results, to realize the traceability of the online content.

3. The running state

The middle stage of running mode includes three aspects: ability configuration, ability arrangement and ability execution. Configurable and choreographed capabilities need to be reported in a unified manner to form a global control center, known as the Mid-platform Control Platform (MPC). MPC completes the management and configuration of business capabilities, and then realizes the execution of capabilities through the execution plane. In combination with the operation plane (BOC), the three platforms work together to achieve flexible control of the operation content in the middle platform.

3.3 Service Platform Construction Strategy

How should the business middle stage be built around the core architecture and systems? Specific strategies for building business medias: domain driven, requirements structured, and capability configurable. First, we divide the domain of the business center on the whole through the domain drive, and then divide the specific capability center of the business center. Secondly, the specific field is refined. Here we will use two strategies, requirement structure and capability configuration, resulting in an easy-to-use and flexible business capability center.

3.3.1 Domain-driven design

The construction of the business center first needs to carry out overall planning. Domain-Driven Design (DDD) is a practical strategy to clarify the intricacies of internal and external systems involved in the middle platform. By referring to domain-driven design, we can sort out the journey map of all roles involved in the business application system, including operators, consumers, customer service and shopping guides, etc. Then, according to the business objects or entities involved in the user’s journey map, we can peel off the differences and extract commonalities, and finally form shared service capabilities. Domain-driven design, first proposed by Eric Evans, aims to model the domain involved in software to deal with the software complexity problem caused by the system scale being too large. The domain-driven process of building a business middle stage can be divided into strategic and tactical stages.

1. Strategic phase

The core purpose of the strategic stage of business center construction is to divide the problem domain, determine the core domain and sort out the limiting context. Domains can be divided into core domains, support subdomains, and general subdomains by type. The major system functions and core domains that realize the business vision and value are called supporting subdomains, and the relatively common subdomains are called common subdomains. A bounding context provides a context for a domain, ensuring that terms in a domain have a non-ambiguous meaning within their specific boundary scope. In the process of domain-driven business construction, the developers and domain experts communicate and confirm information in the common language from the business dimension, and sort out the core domain and the sub-domain supporting the core domain. In the process, some common system requirements and scenarios for technical dimensions will emerge, forming a common subdomain.

On the basis of domain division, we divide the business domain involved in the middle platform into management, login authentication, message sending, data dictionary and other general functions, which can form a general capability domain ==. For scenarios related to customer interaction (such as consumers browsing commodities and placing orders, and consumers enjoying membership rights and interests), the commodity center, trading center, inventory center, member center, marketing center and other fields that promote business behavior can form the business center == business capability domain ==. General competence domain focuses on basic competence and provides basic support for commercial competence domain. The business capability domain mainly focuses on all kinds of business capabilities to further support the diversified scenarios of the front desk business.



Unlike traditional DDD, there is less emphasis on supporting subdomains. This is because zhongtai is a shared service platform for enterprise applications, which will support a variety of business applications. It makes sense to distinguish between core domains and supporting subdomains from different business application perspectives. However, from the perspective of the business medium, there is little need to distinguish between the core domain and the supporting sub-domain during the construction process, because the business medium construction is driven by business applications.

2. Tactical phase

After the system is divided into multiple capability centers, the Mid-stage construction enters the tactical phase. In the tactical phase, specific domain design is carried out for the identified capability centers. At this stage, we focus more on the elements within the domain. We generally use domain models to express domain knowledge. Common domain models include entities, value objects, domain services, domain events, and aggregations.

Take the transaction context as an example, build the following figure,



In the context of this constraint, the key core is Transaction. A transaction represents not only an order, but also an action. A transaction produces many kinds of documents, such as TradeOrder, PayOrder, DeliveryOrder and so on. A trade order may consist of one or more Order Items. These documents contain the corresponding document ID, status and other entity attributes. Tarim is the bounded context entity. In the context of transaction, all entities and value objects are around the transaction, and the external need to access the transaction context must start from the transaction, so the transaction can be regarded as the aggregation root of a transaction context. However, after a consumer places an order, the transaction entity will be seen first. In the process of creating the aggregate root entity, corresponding documents need to be created. To fully build and initialize the trading entity, we can encapsulate the concrete creation logic with a TransactionFactory.

Each entity involves a change of state, and the work of that state change can trigger a domain event. Domain events are usually “noun + verb past tense”. When a consumer places an order, an OrderCreated domain event is generated. For a trade order entity, creating an order is the ability of the entity. In the process of ordering, DeductStock needs to be deducted. This action involves domain objects of other contexts in the trading context, so it can be coordinated through domain services to ensure the consistency of different contexts.

In conclusion, in the process of domain driven design, we through the strategic and tactical two stages, from on macroscopic overall borders areas, could be divided into general business middle ability and business domains, and for each competency center, refining domain objects, forming rich domain object model, the ability to build into a specific business center in the field of ability.

3. Event-based storm DDD

However, there are many different approaches to how to operationalize real-time DDD, and Event Storming is an economical, efficient, and fun way to quickly explore complex business areas.

Time storm is a tactical stage design method, which deduces strategic and macroscopic domain model from microscopic domain events from bottom to top. It is nicknamed “wall paste” by the industry because it covers all four walls of a room with post-it notes. There is almost no learning curve, and the only slightly higher requirements are a room big enough and plenty of post-it notes in different colors. Its core is collaborative co-creation, which requires domain experts, business architects and technicians to explore and build domain models iteratively in a collaborative way.

The theoretical basis of event storms comes from domain events. If a system is capable of supporting a business, the role’s actions on the business will result in a response from the system as the business proceeds, leaving a footprint. These footprints often exist somewhere in the form of data. The response of a system that leaves such a footprint is a domain event. Business operations at the time can be inferred by tracing the footprint of domain events. If the domain events are sorted according to time, a series of business behaviors can be restored on the time line, thus deriving the capabilities required by the system and transforming them into the spatial structure of the system through technical means. The spatial structure of the system is the domain model of the system.The vegetarian figure above is a domain event flow generated after an event storm on the same-city delivery demand in the mall. First, event storms unfold based on business scenarios. In this requirement, domain experts identified several business scenarios including store creation, intra-city distribution configuration, commodity selection, order confirmation, order receiving, and distribution. Each business scenario is then expanded to identify, from left to right, the domain event under that scenario, as well as the command and role that triggered it. The subsequent modeling work of these events is based on the tactical layer input on which the domain model can be progressively deduced.

After the event storm, both the overlap with the general model and the divergence can be found. In doing so, we have not only maximized our existing capabilities, but also continued to expand our capabilities by adding differentials.

For how to build the event storm-based business mid-stage domain model, refer to the process shown below.

1. Business architects and domain experts lead the team in identifying domain events, commands, and roles by business scenario and ordering them by time.
2. Business architects and domain experts lead teams to refine subdomains based on business scenarios and event flows at the tactical layer. For the center, the subdomain can be considered as the center of capability. But at this point, the capability center is still in the problem domain space and there is no solution.
3. The technical staff leads the team in extracting business elements based on the event flow, identifying entities, value objects, and aggregations.
4. Once again, the technical staff leads the team across the strategic layer to identify the bounded context and its mapping and integration relationships, and to verify that there is sufficient capacity to address the competence-centric issues. At this point, the capability center problem is resolved in a bounded context, and the business mid-platform architecture finally moves from a problem to a solution.

3.3.2 Structure of requirements

The core value of the business center lies in the sharing of capabilities. The first question that users of CMCS face when contacting CMCS is: How to know what capabilities the CMCS have? How well do these capabilities match up with real business scenarios? Therefore, the construction of the business medium first needs to consider the presentation of business capabilities. We structurally express business requirements in a hierarchy of business scenarios, business capabilities, and business configurations. Demand structuralization reflects a kind of structural thinking, that is, when facing the demand problem, a hierarchical structure is adopted to disassemble the demand. When the capabilities are presented in a structured way, understanding the capabilities provided by the central platform is usually through the API list, and is limited to developers because it is difficult for business people to understand the API list. But structuring requirements not only makes it easier to understand the sharing capabilities of the middle of the business, it also broadens the audience. Requirements structure, generally can be reflected from two dimensions.

1. Ability map. Visually represent each node in the requirements scenario and process from a structured hierarchy of domains, scenarios, and capabilities. In this way, mid-stage capability users can quickly match available business domains, scenarios, and capabilities based on raw requirements. For non-existent business scenarios, capability users form scenario capability development items for current requirements.
2. Configure the view. In the same domain, different business scenarios lead to different business rules. In the configuration view, users can view existing service rules in the service center to match the rules in the current service scenario. If the rule already exists but does not match the current required rule policy, the extended implementation development item of the rule is formed. Custom implementation development items can be formed if the rules are specific to the current business scenario.

To sum up, through capability maps and configuration maps, we can connect business scenarios and business rules in a system-structure-level manner. According to the structuring method of requirements, we will first sort out the scenarios, capabilities and configurations to be used for specific requirements, and then sort out the new development scenarios, capabilities and rules to be added on the existing system to form the items to be developed and configured for final requirements. The middle stage of business is not achieved overnight. On the one hand, the need for a structured way to facilitate the use of sharing ability easy application, verification of business capabilities; On the other hand, it can not only precipitate more business capabilities, business rule configurations, and extensions. This is also how the business evolves itself.

3.3.3 Capability Configuration

Because business capabilities differ, business rules are not all the same. For example, the same is the ability to order, for ordinary goods, the order action only needs to verify the effectiveness of basic goods, inventory; But for hot commodities, after the completion of basic verification, before placing an order, the system can also increase the verification of commodity purchase limit. According to different use scenarios, there will also be a variety of rules and strategies for commodity purchase limit verification, such as membership level purchase limit, membership reservation purchase limit, etc. It can be seen that the business rules involved in the same order capacity in different scenarios are not exactly the same. Therefore, as a capability sharing platform, how to configure and isolate different business rules for different business scenarios and business objects (such as goods and stores) is a problem that must be solved. On the basis of realizing common service rules, the CTI extracts the variable parts of different service scenarios as service configurable items, and manages these configurable items in a unified manner, thus forming the capability configurable feature of THE CTI. There are two types of service configuration items:

1. Business parameters
2. Business extension point. Business extension defines an interface contract for unifying business logic and business personalization in the middle platform. As long as we follow this contract, we can extend different business rule logic at any time according to business needs. This is another important feature required by the business medium – dynamic scaling.

The construction of the service center is a process of arranging and implementing configuration items. By constantly enriching the configurable capability of the business center and constantly polishing the business ability, the business center will become a sharp tool to support the rapid innovation of front-end business.

3.4 Five-step approach to business medium stage construction

The five-step method of business center construction is the methodology to guide us to build the center. The specific steps are as follows: business planning – “domain analysis -” center design – “Center realization -” business operation. Among them, the process of domain analysis is very key, which is different from the traditional IT system construction.

The five-step business Construction 3.0 is shown as follows:

3.4.1 High-level planning

High-level planning includes macro business planning and macro technology planning, which is a process of aiming at the essentials. Macro business planning is a process of top-level design that analyzes the core business scenarios of an enterprise, dissects the problems and pain points existing in the whole and part of the enterprise, and plans the business blueprint and business solutions from a macro perspective. Macro business planning does not need to go into every specific business scenario. Macro technology planning is the process of deriving macro business fields and business centers through the understanding and analysis of core business scenarios and macro business blueprints, and then designing macro 0-level architecture on this basis. The macro technical planning also outputs the main operational capabilities that the centres need to provide. The Level 0 architecture is a macro application architecture that addresses the problem of how to disassemble systems to take on and support business blueprints. It includes capability centers, applications, and tripartite systems that need to be integrated and their interrelationships. In addition, the level 0 architecture needs to reflect the responsibilities of the layers, the relationships between the layers, and the relationships between the components within the layers. The Level 0 architecture not only defines the boundaries of the central, application, and tripartite systems, but also frames the creation of Code engineering for The Central platform and points the way for subsequent design work for the Central Platform. In addition to the level 0 architecture, the macro technical planning also needs to clarify the design principles of the system to guide the team to keep consistent thinking during the construction of the Middle Stage. The products of high-level planning, especially level 0 architecture, need to be fully discussed and reviewed. A good Level 0 architecture requires a clean delineation of the content and composition of the mid-stage and a good review in terms of system complexity, cost of construction, scalability, etc.

3.4.2 Domain analysis

Domain analysis consists of the following three parts:

1. Service scenario sorting: Sort out the service scenarios of each domain based on the service domains demarcated in high-level planning. Combined with the pain points existing in the scene, the future system functions are planned and the corresponding system prototype is further designed.
2. Domain model bulldozing: Firstly, according to the scene list of each domain, event storm is used to sort out and summarize the domain model list. Then, according to domain events, the domain model is abstracted and summarized, including domain activities, domain events, domain objects, domain rules and so on. Then, based on the domain model, the business sub-domains are derived according to the aggregation relationship between the models. Finally, by analyzing the relationship between the responsibilities of each sub-domain and the overall goal, we can derive the capability center.

Scenario List – “Domain Model List -” Domain Model – “Business Sub-Domain -” Capability Center 3. High-level planning adjustment: After deducing the capability center, it is necessary to compare it with the preset capability center in the high-level planning stage, and then adjust the planning content and level 0 architecture according to the needs.

3.4.3 Center design

Center design includes component planning, level 1 architecture design and center outline design. Component planning refers to specifying which business components comprise the capability center of the planning office according to the domain model. A business component is an encapsulated unit of business logic that contains one or more capabilities that are typically used to accomplish a specific business task and can be reused by multiple business scenarios. Service components are aggregated into capability centers based on logical relationships, and capability centers can be divided into BAL, BCL, and BEL layers based on logical relationships. In this way, a three-dimensional structure of “horizontal and vertical order and reasonable decoupling” has been formed in the business center. If level 0 architecture is the skeleton of the CENTER, then Level 1 architecture is the blood of the center. The skeleton is used for stability and support, while blood needs to flow around the body in order to function properly. Level 1 architecture focuses on how centers and applications perform their respective functions and carry their respective data and business logic in specific business scenarios, that is, connecting the capabilities of centers and domain events through specific business scenarios. In the cascade process, it is possible to discover the missing capabilities of the Level 0 architecture and even adjust the distribution of domain models across the centers of the Level 0 architecture. Level 1 architecture is a key bridge from level 0 architecture design to landing development, and is also a guideline for the central outline design. Central outline design is a transitional phase from system design to development delivery. Through the design of database conceptual model, function package structure, core sequence diagram, interface design, etc., it lays the foundation for the detailed design and development of the center.

3.4.4 Development and delivery

Development delivery is the process of implementing level 0 architecture and level 1 architecture in specific scenarios into code and implementation as a working system. Development delivery includes detailed design of the center, test case design and other detailed design output, as well as code development, continuous delivery, etc. The detailed design of the center includes data physical model design, sequence diagram of specific capabilities, class diagram, etc. It is important to note here that the database model is not equal to the domain model. Development and delivery is a complex project, which needs to rely on a set of technical platform for unified management of design state, management state and operation state. (See Chapter 5) In addition, in the process of using the technology platform, the development team should constantly absorb advanced content, such as management ideas, open source technology, quick tools, etc., which can not only help the team to grow quickly, but also promote the precipitation and evolution of the technology platform. The whole development and delivery process should be carried out under the guidance of the idea of technical autonomy, including iterative planning, requirements return, continuous integration, etc., supplemented by the process control of daily clearance and daily closure. Riqing, help the team to find problems; Day end, sum up experience and lessons in time. Through summary and review, advanced and effective measures can be carried forward, deficiencies and mistakes can be checked in time, to ensure effective development activities.

3.4.5 Continuous operation

Taiwan needs to continue to operate ability to precipitation and development. Continuous operation includes the following four aspects:

1. Business operations
2. Content operation
3. Technology operations
4. The data operation

3.5 Service center integration with other systems

The relationship between enterprise application and China and Taiwan:

1. To create an application on the central platform, replace the original application with a new application
2. Partially transform the original application and connect it with THE PLATFORM, that is, use the tools provided by the technology platform to strip the part provided by the platform from the original application and access the platform, such as access to the users, members and orders of the platform.
3. Enterprise applications may be steady-state applications, or they may not be involved in the current construction phase of Taiwan. The central platform needs to integrate these applications with existing functions or data.
4. In addition, the enterprise also has the docking requirements of external upstream and downstream, external platform and other systems. Therefore, China and Taiwan need to provide appropriate integration mechanisms to “connect the past and connect the future”.

3.5.1 Service Driven Integration

The application integration is driven by the business, but the scope of integration is related to the stage of the enterprise to promote the construction of the medium platform and the boundary between the medium platform and other systems. Moreover, with the development of the construction of the central platform, the fields supported by the central platform will gradually expand, and the original integration boundary will change, or even completely replace the functions of the existing integrated system.

1. External platform services

• Third-party payment
• logistics
• certification
• SMS
• Social sharing
• Electronic invoice
• Electric business platform

2. Enterprise internal system

• ERP
• dms
• crm
• os

3.5.2 Integration Policy

Three principles need to be considered:

• Coupling: Business scenarios in the middle of a business can form complete processes without dependence on external systems or analog interfaces. Loosely-coupled architectures need to be designed to ensure the independence and integrity of the business middleware.
• Intrusive: When the service center is integrated with other systems, it needs to abstract a set of standard interfaces for unified interconnection with external systems to reduce changes to the service center’s functional codes.
• Reliability: During system integration, perfect fault-tolerance and retry mechanisms should be provided to ensure that services can continue after the system is restored to the vehicle, regardless of whether a fault occurs in the middle or other systems.

To sum up, in order to ensure the business independence of the middle platform, reduce the dependence on external systems, improve the integration efficiency and fault tolerance of the system, we need to design a middle platform connector to realize and control the docking with the third-party system in a unified manner. Refer to the figure below.

Introduction of mid-stage connector can be a good solution to the following problems:

1. The mid-platform connector isolates the business mid-platform from external systems, preventing the complexity of external systems from affecting the purity of the business mid-platform itself.
2. The central connector is used for unified data adaptation and conversion to solve the problem of inconsistent data of various systems and reduce data maintenance costs.
3. When there is a data error, the center connector can retry data. The connector provides a default retry mechanism and allows you to manually batch adjust the data state for replay.
4. Reserved expansion is available for the mid-terminal connector when the interconnection data between the mid-terminal and other systems is inconsistent. If you encounter a business scenario that does not meet your requirements, you can simply develop a new adapter.

Common integration methods are as follows:

1. Interface call
2. The message queue
3. The file transfer
4. Shared Database

It is emphasized that the integration between the service center and other systems is not to choose only one of the above integration methods, but to consider the integration scope, mode, strategy, cost and other factors comprehensively from the perspective of the business, and choose the appropriate way according to the system connected.

3.6 Association between Services and data

The business and data centers are independent but complementary. The service center supports real-time online services and generates service data. The data center transforms data into data assets through aggregation and integration, purification processing, modeling and algorithm learning, and provides them for business use in the form of shared services, so as to link with business and generate new data again.

From the point of view of data, the business center obtains a large amount of business data through the output of capabilities. These real-time operation and maintenance data are one of the most important data sources in the data center. Moreover, because the data is real-time, the time delay for model processing in the data is reduced. At the same time, the data center can directly push the data results processed by the model to the business center to enrich the business content of the business center. For example, after the customer labels produced by the data center are pushed to the business center, the business center can show comprehensive customer portraits and provide efficient and high-quality services for marketing and service.

From the perspective of business collaboration, the business center needs the data service provided by the data center to adjust the business capability when it supports the business. The online data services provided by the Data Center can help business capabilities to be more targeted and precise execution. For example, in the interactive marketing scenario, the transaction capability of the business center can be combined with the task portrait service of the data center to complete the differentiated recommendation of thousands of people.

From the perspective of system management, the business center plays the role of unified management of data sources while building the same business center. The data governance of the data center lays the foundation for business and data unification and provides high quality data for the data center. In addition, the metadata definition of business objects can be used by the data center to reduce the workload of repeated definition and management.

Finally, the business center and the data center work together to build a closed loop of “production-consumption-regeneration” of data, driving the digital intelligence transformation of enterprises.