When large models sweep the B-end, enterprises find that “naked swimming” – data islands, different calibers, and fragmented scenes, and AI cannot run at all. The middle platform, which was once criticized as “heavy and useless”, heated up again due to AI’s rigid need for unified knowledge precipitation and scene entrance. The article gives the latest methodology of “master data middle platform”: standard design + model layering, making the middle platform the first springboard for AI landing.
Recently, I communicated with a few friends in the circle, and in the field of B-end products, especially in the field of digitalization, we have a common consensus, that is, we found that the concept of middle platform, which was popular in the first two years, has slowly regained its popularity this year, and it is still insisting on the updated B-end product number, and we have also talked about the middle platform more or less again.
01 When it was AI, it was found that it was all naked swimming
Why is there such a change?
As the first author of Zhongtai Books, in my opinion, it is actually brought about by our current new AI wave.
Wait, you might say what the AI wave has to do with the middle office? In fact, the relationship here is great, the current round of AI wave is actually to put it bluntly, we all know that it is based on a round of development based on large models, if we look at the graphic and text large model with the highest production rate now, that is, based on a round of technological revolution driven by knowledge and corpus to convert human natural language into machine instructions.
And more importantly, with the explosive development of large models in the past two years, we have reached a state where we can use new technologies to achieve large-scale industrial applications, and we already have the technology to allow enterprises to produce exclusive AI employees at low cost – RAG+ open source model (qianwen/deepseek/k2/…… ) combination.
To achieve these three challenges, product managers will only continue to appreciate
Good product managers are very scarce, and product managers who understand users, business, and data are still in demand when they go out of the Internet. On the contrary, if you only do simple communication, inefficient execution, and shallow thinking, I am afraid that you will not be able to go through the torrent of the next 3-5 years.
View details >
There are two very big hidden conditions here:
Does the first enterprise have enough knowledge for AI to train and generate content?
Second, are there enough scenarios for AI to reach?
These two things essentially require enterprises to precipitate internal data into the digital assets of the entire enterprise, and to unify the entrances of various scenarios of the enterprise, to unify small engineering capabilities, and as a new public capability, to reverse access to various front desk terminals.
After reading what I said, do you feel very cordial?
That’s right, isn’t this the specific problem that the middle office architecture has hoped to solve for enterprises since its inception?
The reason why many states failed to establish before was because there was not so much data, it had to be precipitated and there were not so many scenarios that had to reach these two
But this AI change is different, it is a time to really test how many foundations a company has!
But as the saying goes: only after the tide is low, you don’t know who is swimming naked.
Judging from the several companies I visited in the first half of the year, when these companies wanted to go to AI, when they did internal data inventory, they found that the internal enterprises were not islands, but independent worlds.
For example:
A business unit can have three or four versions within the enterprise, and even the basic caliber is completely different once it leaves the business line, and even contradicts itself.
Moreover, the ultra-low multiplexing ability between domains, the same query interface has to be done 3 times in different domains, and even each domain has to crawl the database by itself.
The performance of front-line business actions cannot be pulled back, and the function stacking causes the front line to play the first line, and the background plays the background.
……
Do you still want to train AI? Dream!
02 Middle office construction for the AI era
So how should we build what enterprises need to support this round of AI revolution?
In my opinion, the first step in the development of the middle office for so many years is the middle platform that can see results in the short term is the middle platform of the master data management system (MDM).
First of all, we need to understand that the essence of master data centralization is a shared service platform for data assets, and in this process, we need to solve three core problems:
- Break down business system barriers: avoid duplicate definition of master data in each system (such as customer data in different formats in CRM and ERP);
- Support flexible business expansion: When new services (such as new channels and new product lines) appear, master data can be quickly adapted.
- Provide standardized services: Output “ready-to-use” master data to the front-end business system through APIs, data interfaces, etc.
Therefore, the entire design needs to revolve around “platform-based precipitation + service-oriented output”.
Specifically, how to do it? Let’s take a look at master data management first.
In the field of master data management, in fact, the vernacular is to do two things: standard design and model design.
Standard design and model design are essentially the core foundation for ensuring that master data is “consistent, accurate, and available”.
The two support each other to realize the implementation of standard guidance models and the implementation of model solidification standards.
Let’s look at them one by one.
Step 1: Master Data Standard Design Methodology
Because master data standards are cross-business and cross-system “data contracts”, standards are designed to solve the problem of “unified terminology, unified format, and unified rules”.
So the core methods include the following, let’s first update the table just now:
Method 1 Business scenario analysis method: Calculate the standard backwards from the business requirements
Logic: The value of master data lies in supporting business collaboration, by clarifying the use of master data in various business scenarios (who uses it, what is used, and how to use it), and then refining common requirements as standards.
Steps:
- sort out the business scenarios involved in the master data (such as customer master data involving sales orders, customer service follow-up, financial reconciliation);
- Collect the “required items, format, and meaning” requirements for data in each scenario;
- Merge common needs and resolve conflicts (for example, sales should be “customer abbreviation”, finance should be “customer full name”, and relationships need to be retained and defined at the same time).
Example: The “Contact Us” standard for customer master data
Business scenarios: sales need to be contacted by phone (mobile phone number required), customer service needs to send email (email required), finance needs to send invoices (landline phone required);
Common requirements: contact information needs to be “verifiable” (to avoid invalid data);
Standard Outputs:
Field definitions: mobile phone number (required, 11 digits, the first 3 digits correspond to the operator number segment), email (required, format is “xxx@xxx.xxx”), landline phone (optional, format is “area code – number”, e.g. 010-12345678);
Validation rules: The mobile phone number passes the regular expression check (^1 [3-9]d {9}$), and the email address passes the format check (including @和.).
Method 2 Compliance mapping method: anchoring regulations and industry norms
Logic: Because master data often involves sensitive information (such as personal information and corporate qualifications), it needs to comply with laws and regulations (such as the Personal Information Protection Law and the Data Security Law) and industry standards (such as customer identification specifications in the financial industry) to transform compliance requirements into data standards.
Steps:
- Identify sensitive fields in master data (e.g., customer’s ID number, bank card number);
- Mapping regulatory requirements (e.g., “ID number needs to be encrypted and stored”, “bank card number needs to be desensitized and displayed”);
- Formulate corresponding standards (storage format, masking rules, access rights).
For example, the “ID number” standard for customer master data in the financial industry
Compliance requirements: The Personal Information Protection Law stipulates that “sensitive personal information must be encrypted and stored, and must be desensitized when displayed”;
Standard Outputs:
Storage format: Encrypted and stored using AES encryption algorithm, field type varchar (128) (encrypted length);
Display rules: After desensitization, it will be displayed as “110********1234” (keep the first 3 and last 4 digits);
Access control: Only authorized positions such as risk control and customer service can view the plaintext (log recording required).
Step 2: Master data model design method
The master data model is the “physical carrier” of the standard, which needs to be transformed into a structured data structure (entities, attributes, relationships) to ensure that the data can be stored, correlated, and scaled in the system.
The core approach includes the following three:
(Core Methodology of Master Data Management)
Method 1 Entity Relationship Analysis Method: Identify core entities and associations
Logic: The core of master data is “entities” (such as customers, products) and “relationships” between entities (such as “customers purchase products”), and it is necessary to first clarify the entity boundaries (what are master data entities) and then sort out the association rules between entities.
Steps:
- Identify core entities: Based on business scenarios, filter entities that are “shared across systems, long-term stability, and have a wide range of influence” (e.g., customers and products are master data, and orders are transaction data).
- Define entity attributes: Convert the “field rules” in the standard into the attributes of the entity (such as the “mobile phone number” attribute of the customer entity, corresponding to the formatting rules in the standard);
- Sort out relationships: Clarify the relationship between entities (for example, “product” and “product classification” are “many-to-one” relationships, and one category contains multiple products).
Example: Entity relationship design for a product master data model
Core entities: products, product classifications, and brands (all stable entities shared across systems);
Entity Attributes (based on criteria):
Product: Product ID (compliant with coding standard: classification code + 6-digit serial number), product name (compliant with naming standard: brand name + model), specification;
Product category: category ID, category name (e.g., “Home Appliances – Refrigerator”);
Brand: brand ID, brand name (e.g., “Haier”);
Relationship:
Product → Product Category: Many-to-One (one category contains multiple products);
Product → Brand: Many-to-One (one brand contains multiple products).
At this point, we seem to have finished our work, right?
Wait for the above is just to complete the plan, and we still have a very specific step in the specific implementation.
It is the mapping of the model, here we can use the hierarchical design method to practice the gradual implementation from concept to physics
Logic: Model design needs to take into account both “business understanding” and “technical implementation”, and ensure that business personnel can understand → technical personnel can implement it through the hierarchical design of “conceptual modellogical model→ physical model”.
Steps:
- Conceptual model: Describe entities and relationships in business language (e.g., “customers include individual customers and enterprise customers, and individual customers have contacts”), without technical details;
- Logical model: Refine entity attributes and define data types (not bound to specific databases), such as customer ID (string), name (string)).
- Physical model: Define field types (e.g., varchar(32)) for specific databases (e.g., MySQL)
So we get the complete layout of the entire master data table
After understanding the logic of master data management, let’s look at the master data management of the middle platform.
The standard design of master data management in the middle office needs to take into account “global consistency” and “business domain flexibility”, and is implemented through the two-layer architecture of “core standard layer + business domain expansion layer”, and at the same time relies on middle office tools to achieve standard full life cycle management.
Step 1: Core standard layer: Unified “data contract” in the middle office
Logic: Refine the core fields common to each business domain (such as the unique identifier of customers and the basic attributes of products) to form a cross-domain unified “benchmark standard” as the “minimum data set” of the middle office to ensure the global consistency of master data.
Middle platform method:
- Sort out commonalities based on the “business domain map”: Identify the common requirements of customer, product, organization, and other master data in each business domain (sales, supply chain, finance) through the business domain modeling tools (such as the metadata management platform) in the middle office (such as the “customer ID” must be unique and common across systems);
- Platform solidification of standards: Enter core standards into the “Standard Management Center” of the middle office, bind verification rules (such as format and uniqueness), and automatically synchronize them to various business systems through the middle office engine (avoiding manual maintenance).
Example: Customer Master Data Core Standard (Unified Layer of Middle Office)
Core fields (cross-domain required):
- Customer unique identification (CUST_ID): The global ID automatically generated by the middle office (rule: prefix “C” + 8 digits, such as C10000001), is ensured by the ID generation service of the middle office.
- Customer type (CUST_TYPE): Enumerated values (individuals/enterprises), defined by the middle office standard center, and do not allow business system customization;
- STATUS: Enumerated values (valid/invalid), and the status change must be triggered by the approval flow service of the middle office (e.g., “Invalid” requires double confirmation of sales + finance).
- Middle office support: The core standard is provided externally through the “standard verification API” of the middle office, and when the business system enters customer data, it needs to call the API verification format (if the CUST_ID does not meet the rules, it will return an error).
Step 2: Business Domain Expansion Layer: Flexible Adaptation Supported by the Middle Office
Logic: According to the personalized needs of each business domain (e.g., sales need a “customer channel label” and customer service needs a “customer preference tag”), “domain-based expansion” is allowed on the basis of the core standard, but the expansion rules need to be filed in the middle office and accepted unified management to avoid the standard from getting out of control.
Middle platform method:
- “Application-Approval-Release” process for extended fields: The business domain submits requirements through the “Extended Field Management Platform” in the middle office (for example, the sales domain needs to add the “Customer Source Channel” field), and after the approval of the middle office governance committee, the extended field is added on the basis of the core standards.
- “Inheritance constraints” of the extension standard: The extension field must follow the basic rules of the middle office (such as data type and desensitization requirements), such as the optional value of “customer source channel” (official website/offline store) must be registered in the middle office to ensure that it can be recognized during cross-domain queries.
Example: Customer Master Data Extension Standard (Business Domain Layer)
Sales domain extension field:
- Customer source channel (SOURCE_CHANNEL): The value set is applied for by the sales department on the middle office expansion platform, and takes effect after approval (such as “official website”, “Tmall”, “store”);
- Follow-up sales ID (SALES_ID): Associate the “employee master data” of the middle office, and ensure that the ID exists in the employee master data through the association verification service of the middle office.
Customer Service Domain Extension Field:
- PREFERENCE: The text type (e.g., “Preferred Online Communication”) is defined by the customer service department, but the storage rules (e.g., length ≤ 100 words) must be registered in the middle office.
It can be seen that when managing in the middle office, the work of master data within each domain is pulled up to a public place for unified management, so as to promote the implementation of the specification in each domain.
