Abstract: In order to break down the technical and business barriers and build Bridges between technology and business, the following process is used to implement applied business model management ROMA ABM.

In the era of digital economy, data is becoming an extremely important strategic asset for enterprises. For the government, data is for the first time a new factor of production, as the “fifth factor” alongside land, labor, capital and technology. As more data comes in, it gets harder to figure out what it means, which raises some questions:

  • In the era of big data, the amount of government and enterprise data has exploded, so it is not satisfactory to search data quickly and accurately in the mass of information.
  • Inconsistent understanding The difference in business understanding makes IT and the business become “two skins”, resulting in a lot of duplication of work, and even affect business decisions.
  • Employees with high learning costs have certain mobility. For example, they lack business management methods and need to spend a lot of time and cost to train new employees, resulting in serious knowledge loss and money consumption.

To solve the above problems, we should build a business model to break through the semantic barrier, operation management to drive high-quality development, and build a set of sound asset management methods.

To break down and bridge the technical and Business barriers, implement Application Business Model Management ROMA ABM (Application Business Model) based on the following process,

The key processes are explained and interpreted as follows for better understanding:

1. Model standards

A model is the data that describes the data, also known as metadata, such as the table of contents of a book (author, ISBN, price, etc.), simple table fields for physical tables, API input and output, etc.

The industry OMG specification group has a specific definition of a model, in the MOF 2.5 specification the model term M1 layer.

  • M3 is the metamodel used to define the metamodel, providing the basic model to quickly assemble a metamodel package, such as defining the required domain, class, attribute, relationship, etc.;
  • M2 is a metamodel, is an instance of M3, is a model specification, specifically, is to describe the elements of the model and the relationship between elements, such as relational database metamodel, from library to table, instance, table, field, index relationship;
  • M1 is a model, which is used to describe data, such as the catalog information of a book (author, ISBN, price, etc.), generally corresponding to the table fields of the physical table, the fields of API response, etc.
  • M0 is an object based on this model, that is, data in the physical world, which generally corresponds to data in a physical table.

2. Model classification

ROMA ABM defines an industry-recognized taxonomy of technical models and business models.

  • Technical models include: field name, field length, database table structure, API description, message description, file description and so on. Technical models are usually collected by automated tasks, and models can also be acquired by other means such as file import. Examples of relational database and microservice model package are as follows for reference.

  • Business model includes: business name, business definition, business description, security policy and other business attributes that can be understood by other users. Users can quickly locate the data model they want to obtain according to their own business line or domain. The following is a sample package of business model for reference.

3. Model design

ROMA ABM’s metamodel visualization enables rapid design of a metamodel that demonstrates the designer’s understanding of the business system as a whole, the classification of data from a business perspective, what we can call a business model, that allows the entire organization to unify the data language. It is the key factor to open up the service flow, eliminate the information island and improve the service flow integration efficiency. Before designing business model, need to do to the organization’s business end-to-end comb, such as what are the scope of business, business process, business subject, business events, etc., and then finishing the content above to sum up, designed in accordance with your own organization unique business model (model), wisdom city scene, for example, here The business model of digital government is summarized by sorting and designing:

Through an ABM visualization model configuration ability complete digital government business model M2 meta model configuration, the configuration properties, in order to help people better understand the design of the meta model, through digital government business model in detail, the M2, and M3 layer M3 for M2 layer modeling provides a common meta-model design elements, specific reference is as follows:

The design structure of M3 layer is shown as follows:

The design structure of M2 layer is shown as follows:

M2 layer not only abstracts the business lines, but also defines business attributes to help users obtain additional business attributes that the underlying structure depends on, such as library tables and APIS. These types of content cannot be obtained by the underlying system. The specific additional attributes need to be sorted out by data managers in combination with business scenarios. The following are the common attributes provided in the Digital Government Business Model package for your reference;

Through the above digital government business model, it is not difficult to find that the core ability of model management is to gradually decompose from abstraction to realization. The relationship between M0, M1, M2 and M3 objects in the real system can be summarized as follows:

  • M1 is M0 layer abstraction. M0 represents the actual stored data and M1 represents the structure needed to store this group of data, which usually corresponds to a set of table structures, a set of apis, a set of files and so on in business systems.
  • M2 is the abstraction of M1 layer, M2 represents the storage model of M1 table structures, apis, files, etc. Although M2 layer is a metamodel, M2 is also data, so the metamodel also needs a unified storage structure and scalability.
  • M3 is the abstraction of M2 layer, M3 represents the abstraction of M2, with a general type, similar to the design tool, can design a variety of metamodel;

4. Model association

Through the above design completed the design and configuration of the business model and technology model, but this time did not happen any relationship between two kinds of model, so we need to relate the business model and technology model, let technology to business language, through the tool provides a quick and stable, multiple correlation is very important.

In the whole MOF framework, M3-metamodel is the core of the whole model management, so how to build the “configurable + diverse + stable” model collection framework is very key, we can refer to the following principles: · M3-metamodel capability graph component, complete the construction of the metamodel package through drag and drop;

  • Multiple sets of acquisition adapters under the same type of metamodel share “one set of program” to realize the collection and analysis of models and relations in various media, which is mainly used for diversified collection of technical modules. The following is an adaptation sample diagram of relational database:

  • Cross-package association is supported in the design process of metamodel package, that is, the current metamodel can depend on other metamodel, and the cross-package association can be automatically realized after the model collection is completed.

Based on the above principles, the following model acquisition process is formed:

After the processing of the above steps, the unreadable table, field, API and other information are all converted into a model with business semantics, so that each department, each system, each developer in the use of the number of search more simple, more efficient, completely realize the technical model to business model.

5. Model ecology

Application Business Model Management (ROMA ABM) as a vehicle for metamodel-driven development, with surrounding systems or partners in a good ecological cycle:

  • Automatic extraction of library tables, API, files and other technical models in the stock system, through the visual metamodel designer, so that all technical models can be unified storage according to the business domain, so that developers or users do not need to care about the actual details, shielding the differences of the underlying system;
  • The technical model is automatically associated with the business model through model reversal, so that the underlying database tables, API and other data models that cannot be understood have business semantics, and at the same time, all the underlying data models are returned to their own business scope, so that developers or users who understand business can be in their own business scope. Use familiar business language to complete the data model search;
  • Third party applications or the system can get technology through a unified interface model, business model, further complete model of consumption, the third party application or system model based on the existing stock of the new model was generated by combination, arrangement and so on, in the back to the application management services business model, let all models like the blood flow in the system, Finally, a complete model ecology is formed.

This article is shared by huawei Cloud community “MOF-based Application Model Management”, originally written by: Middleware brother.

Click to follow, the first time to learn about Huawei cloud fresh technology ~