Internal Structure
Overview
Depending on the exact business requirements, market approach etc. there are a lot of different ways to structure a DCM application.
The following lists of questions should help you to make an informed decision:
-
Am I implementing both business roles?
-
Am I implementing only the business role customer?
-
Am I implementing only the business role supplier?
-
Do I have users that require both business roles?
-
Do I want my users to explicitly switch between business roles?
-
Do I have a common business partner data management?
-
Or is it split between customer and supplier base data?
-
Am I capable of automatically generating demands?
-
Am I capable of automatically generating capacities?
-
Do I want my users to to be able change generated demands and capacities by hand or does this have to happen in the actual data source?
-
Am I capable of automatically linking demand series to
WeekBasedCapacityGroup
-
Do I want my users to be able to manually change those links?
-
Am I capable of automatically structure
WeekBasedCapacityGroup
using the nesting capability? -
Do I want my users to be able to manually nest
WeekBasedCapacityGroup
? -
Am I creating a custom solution for just a single company or a product that could be used by many different companies?
-
Am I targeting a specific market segment or am I creating a solution that "does it all"?
Assuming a standard three tier application:
Presentation tier or user interface
# | GUI Module/Component | Sub-Component | Function | Remark |
---|---|---|---|---|
1 | Material Demand View | Overview / Search | Allows users to find, access, edit and create material demands they are responsible for. Show users which material demands are linked and which are not linked yet. | Creating and editing material demands might not be necessary, depending on the depth of integration. |
2 | Material Demand View | Single item View | View table, graph and timeline of and interact with a single material demand. | |
3 | Material Demand View - Single item View | Table | Access and edit demand values for an individual time series. | Demands do not need to match WeekBasedMaterialDemand and the demand series one to one. Instead they could be grouped as such: MaterialNumberCustomer - CustomerLocation - DemandCategory |
4 | Material Demand View - Single item View | Graph | Visualize demand values. | Since demands are always added together to present a total demand per week, it is recommended to visualize them as bars and capacities as lines. |
5 | Material Demand View - Single item View | Timeline | Interactive object, that shows weeks with their relative demand values and allows users to easily set the start-week and end-week of the data they wish to see in the graph and table. | |
6 | Capacity Group View | Overview / Search | Allows users to find and access capacity groups. Allow suppliers to create and edit capacity groups. Allows suppliers to link capacity groups to material demands. | Creating and editing material demands might not be necessary, depending on the depth of integration. |
7 | Capacity Group View | Single item View | View table, graph and timeline of and interact with a single capacity group. | |
8 | Capacity Group View - Single item View | Table | Show data for a capacity group, as well as all linked capacity groups and material demands. Also show data calculated from WeekBasedCapacityGroup and WeekBasedMaterialDemand data. | Hierarchical grouping highly recommended. |
9 | Capacity Group View - Single item View | Graph | Visualize demand and capacity values as well as calculated data. | Since there are multiple relevant capacities per week, it is recommended to visualize them as lines and demands as bars. |
10 | Capacity Group View - Single item View | Timeline | Interactive object, that shows weeks with their relative demand and/or capacity values and allows users to easily set the start-week and end-week of the data they wish to see in the graph and table. | Usually a shrunk down version of the graph, with an interactive focus that can be zoomed, stretched and moved. Since DCM focuses on data the stretches from today up to 104 weeks into the future the default timeline should reflect this. |
11 | Inbox | Comments | Usual Mailbox functionalities and should allow the user to jump to the material demand or capacity group or specific weeks a comment is referencing | |
12 | Inbox | Disruption Notifications | Usual Mailbox functionalities and should allow the user to jump to data relating to the specific product, production site, business partner, etc. effected by the disruption. | Disruption notifications offer a unique chance to interface with other data and processes |
13 | Business Partner Base Data | There are whole applications dealing with this. All DCM requires are BPNLs and BPNAs and a way for the end user to know what the specific BPN* stands for | ||
14 | Admin Interface | Configure assets, policies, contract definitions, connector endpoints, application setting, extract logs, etc. |
Application tier or business logic
The business logic implements the functional capabilities of the application. In our case this mainly means three things:
- Consume data from and provide data to interfacing systems.
- Execute orders issued by the users via the user interface.
- Calculate results from data and provide those results to the user interface.
It would be sensible to split the business logic into the following components:
- One orchestrator per technical interface type
- One component per interface
- One component for every aspect model to handle
- One component to combine aspect models into capacity groups
Data tier or data storage
Since all business relevant data within DCM is exchanges as serialized JSONs one of the main concerns should be how to store and process JSON data efficiently and audit proof. Storing the actually exchanged JSONs and only reading them session-based on the fly makes audit proof storage easier.
As a rule of thumb:
- Data exchanged between companies through the EDC should be stored as ready-only.
- Applying load factors, delta-production etc. to a demand series must not change the corresponding
WeekBasedMaterialDemand
- Applying load factors, delta-production etc. to a demand series must not change the corresponding
- Other data can be stored in order to provide functionality to the user, manage roles and rights, etc.
# | Data to store | Storage requirement | Remark |
---|---|---|---|
1 | Serialized WeekBasedMaterialDemand | Mandatory | Both provided and consumed data must be stored, in the most recent version |
2 | Serialized WeekBasedCapacityGroup | Mandatory | Both provided and consumed data must be stored, in the most recent version |
3 | Serialized IdBasedComment | Mandatory | Please note that a RequestDeletion functionality exists and must be adhered to, superseding the storage requirement. |
4 | Serialized IdBasedRequestForUpdate | Optional | It can make sense to store RfU for debugging or even auditing purposes. But since it does not contain any data with business relevance there is no hard storage requirement. |
6 | Serialized DemandAndCapacityNotification | Mandatory | After a disruption has been resolved, the deleted notifications can be safely deleted, superseding the storage requirement. |
7 | Non shared MaterialDemand | Optional | If you want to give users the option to manually make changes to certain data, it is good practice to let them save their work in progress without having to share the serialized aspect model. |
8 | Non shared CapacityGroup | Optional | If you want to give users the option to manually make changes to certain data, it is good practice to let them save their work in progress without having to share the serialized aspect model. |
9 | Non shared Comment | Optional | If you want to give users the option to manually make changes to certain data, it is good practice to let them save their work in progress without having to share the serialized aspect model. |
9 | User settings | Recommended | Customizable UI settings, Favorites, User Roles, Company the user belongs to, ... |
10 | Company settings | Recommended | Connector-Address, BPNL, Assets, Policies, Contract Definitions ... |
11 | Application settings | Recommended |
Notice
This work is licensed under the CC-BY-4.0
- SPDX-License-Identifier: CC-BY-4.0
- SPDX-FileCopyrightText: 2025 Bayerische Motoren Werke Aktiengesellschaft (BMW AG)