Conceptual Modeling – Introduction
Conceptual Modeling is not really a new idea. One of the most popular examples is the Entity Relationship Model, which has been mentioned by Peter Pin Shan Chen in the 1970ies. And from there on it has continuously evolved and has become a modeling paradigm, which has been broadly adopted by many companies.
In this blog I would like to give a short introduction on the conceptual modeling by talking about the motivation and definition, but also how SAP is approaching this modeling paradigm and which benefits we can derive out of it.
In the example of a house building project, there are usually many stakeholders involved, e.g. client, building firm, bank, notary, electrician, etc. Each stakeholder has different interests and technical skills – nonetheless, they have to work and collaborate together to arrive the very same goal.
Especially the stakeholders client and building firm have to agree and get a common understanding on the requirements of the new house.
Typically, this is documented in the floor plan, which helps on the following aspects:
- Aligned and standardized format
- Get a common understanding between stakeholders
- Enables the communication
- Documents the essential requirements and agreements
The floor plan is what can be associated as a conceptual model.
It is important to understand, that the floor plan won’t be sufficient to build the house. The building firm has to derive a much more detailed construction plan to execute.
Same applies for the electrician who need to create a wiring circuit diagram describing the physical connections and layout of the electrical system.
However, the floorplan remains always the leading document for all stakeholders. Whenever essential changes on the house has to be made, that has to be documented in the floorplan first.
Conceptual modeling is the activity of formally describing some aspects of a real-world system and domain for the purposes of understanding and communication.
A conceptual model’s primary objective is to convey the fundamental principles and basic functionality of the system which it represents. Also, a conceptual model must be developed in such a way as to provide an easily understood system interpretation for the model’s users. A conceptual model, when implemented properly, should satisfy these fundamental objectives:
- Enhance an individual’s understanding of the representative system
- Facilitate efficient conveyance of system details between stakeholders and provide a means for collaboration
- Document the system for future reference
- Alignment and standardization of the format and terminologies
- Provide a point of reference to derive system requirements
In the Data Modeling context, we usually distinguish between 3 modeling types:
- Conceptual Model
- Logical Model
- Physical Model
The borders between the model types are often very blurry, which means there are no strict and absolute rules. In reality, the level of details and specification of each model type vary from company to company and from use case to use case. In extreme case, the model definition might even overlap each other.
What is more important to understand is, that the Conceptual Model targets more the persona of a business user. While the Physical Model aims typically the IT and developers.
Furthermore, the conceptual model serves many purposes and use cases. Hence, for one and the same conceptual model there could be multiple logical and physical model existing, e.g. the concept of a “Sales Order” can be represented in SAP S/4 HANA via CDS Views, while it could be interpreted in Arriba using a Java class definition.
Thereby, the conceptual model contains only the definition and semantic, that are agreed and aligned across all applications. This approach results into a so called common model (non-canonical model).That implies, that each application might have its own additional specifications and attributes, which are specific to the purpose and which is not aligned among other applications.
The alignment must be governed ideally by one central team, which would be responsible for:
- Review, Approval
- Life Cycle Management
SAP One Domain Model
The result of such an alignment process on conceptual level is a catalog with standardized and curated business domain models: the SAP One Domain Model. It encapsulates Business Semantic and Domain Knowledge (Entities, Attributes, Relationships, etc.) which are aligned, shared and trusted across all SAP applications.
Not only that, it serves as a basis and reference point for the adoption and implementation, for which public APIs and services must be provided.
Applying the conceptual modeling properly will generate great values and benefits on the customer side. Let me highlight some of them in the following:
- Reducing frictions between teams and departments through standardization and alignment
- Saving time and lower cost across the organization
- One “semantic” for all business applications with harmonized interfaces and services
- Fosters integration between SAP and Non-SAP applications
New intelligent modern applications
- Unified meta data to drive IoT and interactions between any devices
- Utilizing the business semantic for running Machine Learning, Data Mining and Predictive Analytics
- Using the business language for Natural Language Processing (NLP) applications, such as chat bots
- Enabling Business Users a stakeholder
- Modeling with business language and terminology
- Standardized catalog of Business Domain Objects
- Maintaining legal compliances and securities
- Business Process integration
- Data Driven Decision Making by utilizing the deeper understanding of data
With that I hope I could give you a rough idea on conceptual modeling and its benefits. Especially in the heterogenous cloud landscape, we need an approach which is adoptable in order to build integrated applications at scale. Looking forward to seeing this modeling paradigm applied in more SAP applications.
SAP One Domain Model: https://api.sap.com/sap-one-domain-model