SAP (ODM) One Domain Model – what’s in it for Enterprise Architects
For sure you already have eared about SAP One Domain Model, also known as SAP ODM.
SAP One Domain Model is a single and coherent domain model for SAP’s intelligent suite.
Check also my blog post about how customers can implement a microservices oriented architecture for their extensibility strategy with the help of SAP One Domain Model: SAP One Domain Model – powering microservices architectures
What exactly this means?
When you think about the Intelligent Suite as a set of solutions that will enable SAP customers to become more Intelligent Enterprises, by integrating data and processes with an holistic integration approach, this goes far beyond technical integration of applications, integration of both technology and business processes will be the only way to deliver significant value to customers businesses.
What SAP Customers are asking for…
The integration of business processes relies always in compatible data models, and here is where SAP One Domain Model plays a big help by delivering an harmonized domain model for objects that are distributed to all the different solutions, it provides a basis for a consistent view on master data across the entire hybrid landscape, by mapping objects to a central domain model.
What it’s in it for Enterprise Architects
But, let’s see what it delivers for Enterprise Architects (EA). When trying to help companies thinking about the best solutions to support their business and thinking about what should be the way forward for future architectures, the Job of an EA is to look to the customer landscape, to the business needs and provide the best guidance. For addressing hybrid landscapes and hybrid clouds, the right integration strategy is the focus of more and more decouple architectures.
For us (Enterprise Architects) the SAP One Domain Model helps to address several challenges in our day-to-day conversations and work:
- It helps to eliminate the need of point-to-point integrations, by providing the basis for the master data.
- It allows customers and partners to develop extensions, that can be more stable in future backend updates/upgrades.
- It motivates partners to develop more and more applications and extensions based on a “standard and stable” data models, to be leveraged in different LoB and Industries.
- It enables the existence of consistent data models, so that the suite feels as one product.
- It provides the foundation for a virtual (logic) data model that can be used for different uses cases, for example, simple analytics uses cases or for more advanced analytics scenarios.
The last point is very relevant and helps to addresses cross customers needs. Customers demand more flexibility in accessing SAP data, being able to relate the data with the rest of their ecosystem bring value to companies. Typically customers replicate the data to analytical repositories (DW, DataLakes, etc.) and there, they build their own unified data model. SAP data represents a big chunk of the business data in SAP customers, these data is in most cases the core data that after will be enrich by other data sources, by customers. The application data models are too complex and product oriented, this brings a lot of complexity. By providing an harmonized and aligned data model of SAP solutions based on known business processes like Recruit to Retire, Lead to Cash, Source to Pay and Design to Operate with a semantic more business oriented, will help customers to be more agile and flexible when addressing new business needs and developing extensions.
SAP’s Integrated Intelligent Suite
The extension and integration capabilities of SAP Business Technology Platform (BTP) enables developers to implement loosely coupled extensions and integration of decoupled applications securely. Easy integration of SAP and non-SAP, cloud, and on-premise applications and process messages in real-time scenarios spanning different companies, organizations, or departments within one organization is in the core of SAP Integration Strategy, supported by solutions like Cloud Integration, API Management,Open Connectors,Integration Advisor and with SAP One Domain Model, customers will be able to see the real value of having aligned and stable domain data models, business process oriented.
Please have a look at Intelligent Enterprises are Integrated Enterprises for an update on SAP’s integration strategy.
Now, something very important …
SAP One Domain Model is not a data model that aims to represent all data entities and relationships of SAP Solutions, as an Enterprise Architect, you might be tempted to be pushed to conversations about a canonical data model for your customer systems’ interfaces.The notion of a canonical data model is not aligned with a distributed data patterns in a microservice architecture and integration patterns.
Check also the blog post from Juergen Heymann, “SAP’s One Domain Model and Domain Driven Design”, about why a canonical data model – doomed to fail?
Why the “lingua franca” (also known as a bridge language).
SAP One Domain Model enables applications to synchronize with each other although they speak different languages, aligns configuration and transactional data, and sets the foundation for integration and extension scenarios.
With so many different SAP solutions supporting end-to-end business scenarios a “bridge” between all of them is need, to abstract the complexity and the different data models, technologic platforms, protocols, etc.
Imagine a business process where you need to access dat from different applications, you need to have a coherent enterprise data model with common semantics, to support the exchange of data between business applications of the intelligent suite and its ecosystem.
Lets use the example of SAP Lead-to-Cash, normally Lead generation is managed in SAP Marketing Cloud and sales and customer relation ship is managed in SAP Sales Cloud, in SAP Commerce Cloud is where the customer engagement takes place and the invoicing and post-order fulfilment is then supported by S/4HANA.
As a developer on top of SAP, you will need to … know which business systems are installed in the landscape, know where the data is, and what it looks like, know all the APIs, how to connect to and access all systems, understand how to associate, combine and join data from different systems.
With SAP One Domain Model and SAP Graph you can use OData to access data via the unified One Domain Model, navigate the data regardless of where it resides and build the same application for different landscape configurations.
How can you as an EA explain to customers how they can consume the ONE Domain Model?
- Browse the model structure and access the documentation of the model.
- Check the APIs provided by SAP Graph and SAP Master Data Integration and access to the documentation.
- Enables a central synchronization for master data objects along end-to-end business processes.
- Delivers a central entry point for master data integration within the Intelligent Suite.
- Enables customers to specify a distribution model that allows you to identify which systems have access to view or modify specific data.
- Extend the aligned business model with fields and entities to support business requirements.
Via SAP Graph
- Consumption (CRUD) of master data objects and transactional entities of 3rd party / partner applications with direct integration with SAP Graph APIs on SAP Graph runtime (acting as a proxy).
Future analytics scenarios are being evaluated, but not yet clarified.
How can you as EA explain the advantage for Partners …
Partners that want to be able to develop applications for supporting customer needs, but also aim to reuse the applications for next projects, building more generic applications are a way to reduce the cost of development and in each new project the application can be enriched, they need to focus on SAP One Domain Model.
Your role as an SAP EA …
Customers are looking to new ways for extending the core solutions in a fast and agile way, for that they need to access to the core systems via standard interfaces to provide an exchange of data, every Enterprise Architect needs to be able to explain to customers the importance of the below, when engaging in architectures and roadmaps discussions.
- SAP One Domain Model provides the compatibility layer for data exchange.
SAP Cloud Platform Master Data Integration enables the data replication speaking One Domain Model and serving integration.
SAP Graph is the unified API layer exposing One Domain Model to the outside world.
Thanks for your reading,
António Nunes, SAP Enterprise Architect.
For more details about SAP One Domain Model please refer to:
SAP Help Portal: SAP One Domain Model
SAP One Domain Model API explorer
SAP API Business Hub
SAP One Domain Model Explorer
SAP Cloud Application Programming Model – CDS