(WIP) SMDS - Target Architecture
3.2 Standard Pattern
[Action]: ADD Target State Architecture.
Below are key patterns [AH1] and guidance on master data
Context
Enterprise Master Data: Domains within the scope of Enterprise Master Data with clear business alignment such as Customer, vendor etc should follow centralised MDM Hub approach (Image below) where data mastering can be federated and initiated from different systems in a centralised system SMDS. This approach can support single and multiple data model, however, at present we use single data model. To support additional functionalities such as Internationalisation requirements, data residency as per various regulatory & compliance requirement such as GDPR, CCPA, PIPL etc the existing data model can be augmented with model extensions.
Platforms (spoke in a Hub and Spoke model) with specific local business process requirement (e.g. Business partner relationship mapping done in S4 MDG) should be maintained local to the system and register the unique reference ID back to the central Hub. This will establish a link between Hub and spoke systems. All downstream systems will find relevant information from one central system which can be stitched in the service enrichment process owned by the consuming system. Attributes and logic that is exclusive to the platform usage will be managed and maintained within the platform/system and need not be synced into the central Hub (Image below). This approach would require a federated Governance tightly aligned to the central governance policies to address any gaps.
Pattern
· Legacy Customer Master Data: The Legacy CMD repositories MUST however go into a mode of stasis with respect to their current subscribers. No further new consumers are permitted. The proposed patterns will not itself resolve certain process errors that are potentially occurring across the estate (CMD Status being changed to an invalid flag in CMD whereas downstream system are still treating customers as active. This needs a thorough process review at the start of the planning of downstreams rollout to ensure an aligned policy is used across the enterprise as much as possible and tech consolidation implemented keeping that in mind
· Platform vs Enterprise master data: platform master data is created, managed and consumed within the same platform, typically this mastering is part of packaged solutions. Enterprise master data is created (multi-platform possible) and managed in a central platform which publishes to several consuming platforms. CLARIFY ON ATTRIBUTE LEVEL. Metric:
· Maersk Domain Model: We have a number of monolithic and COTS implementations across the estate that continue to depend upon, and use their own internal representations of Master Data (SAP/SAP MDG, CargoWise etc). However we must align to a common definition that is MDoM aligned for master data golden record attributes ( in line with MIP principle 4)
· Golden record (on attributes): Enterprise master data will be mastered in SMDS and dublicate masters eliminated. Metric: % customer master data records e.g. mandatory attributes for customers.
· Platform extensions (beyond golden record): platform specific master data can be added to the SMDS golden records, however, needs to be synchronized for consistency e.g. finance specific attributes only used inside F&T such as bank details for consumers
· SMDS data models: will be optimized for mastering i.e. customer, consumer, and suppliers should be different masters as overlap of attributes is low. Explain how DMDM works (really a slave, not master) to ensure that logic across systems works as intended
· Customized topics: SMDS will publish agreed variations of the master data (TO BE DISCUSSED) e.g. Business Partner will be enabled from SMDS by combining customer and vendor masters, thereby eliminating the need for Chassis and platform specific customization.