Data Architecture - Design memo
Issue 1 - Master Data Strategy.
Vessel Master has been designed to hold all Attributes related to vessel - regardless of whether the attributes are Master Data or Extended Master Data. This does not comply with the Master Data Strategy. For guidance, the Master Data Strategy splits master data into 2 categories, being Master data used by multiple portfolios/platforms (Master Data) and master data used by a single platform (Extended Master Data).
Extended Master Data is to managed in the platform that requires that data, providing autonomy to the platform in terms of design and governance.
Issue 2- Vessel master application design.
The current design of Vessel Master is highly denormalised and any changes to the solution or addition of attributes requires engineering effort. There are no configurable options for the Master Data Owner to add attributes.
Faced with these 2 issues and looking to ensure Vessel Master application is built to support the 2030 integrator vision, this memo lists out the options available and the recommendation of how to progress for the future.
Option 1 - Continue with current design as is
The 2025 OP approved work, would continue to be designed/implemented based on the current Vessel Master setup. This would enable ontime delivery of OP2 work, but would be building further capabilities into a design which is not strategic and not aligned to the Master Data strategy. Future requirements would require engineering activities for all future work.
The redesign of Vessel Master solution would occur at a future date.
Option 2 - Redesign Vessel Master, and split Master Data and Extended Master Data - but keep all data within SMDS
This design would keep the Master Data and Extended Master Data together and would benefit the report/dashboard requirements as well as providing a single user interface for Maersk employees to view the combined data..
Martin Houmoeller the user interface can be seamless to the user even if the Extended Master Data is split out to the fleet platform - as the SMDS UI could call both the SMDS API and the Fleet API. It will be more complex to deal with the report/dashboard requirements.
This would require additional resources to re-build Vessel Master. There would be a further choice to either delay the approved OP2 vessel work until after the rebuild or incur the technical debt and complete the OP2 work on the legacy solution. It would provide the correct foundation for all future work - and would reduce effort in future deliveries.
Both Master Data and Extended Master Data would be managed by GDA team. During the development, this could be addressed with agreement from Fleet platform on the Extended Master Data resources allocation. However for any future maintain effort, this may cause resource allocation challenges for Extended Master Data.
option 3 - Split out the Extended Master Data and Fleet to build a platform solution to manage this data
This would require additional resources in Fleet to build the platform solution, as well as additional effort in Vessel Master to deprecate all the Extended Master Data attributes, and would delay delay the approved OP2 vessel work until the Fleet component is built or incur the technical debt and complete the OP2 work on the legacy solution.. This is aligned to the Master Data strategy and will ensure that the fleet platform is autonomous for its own requirements.
With the splitting of the data there is concern regarding the report/dashboard capabilities as well as the user experience.
GDA would then only be responsible for the Master Data, and Fleet platform can build and resource the Extended Master Data solution at their discretion.
| Option | Pros | Cons |
|---|---|---|
| Continue building on VMD with current design. | Meet OP2 priorities | Not aligned to Master Data strategyBuilding more on top of inflexible designSolution requires engineers for any future change |
| Redesign VMD and separate Master Data and Extended Master Data and optimise the design | Partially aligned to Master Data strategy Design will allow configuration for future changes | Either delays OP2 priorities or add to technical debtRequires additional GDA engineers to rebuild VMDGDA resources would be used to manage Fleet platform changes. |
| Redesign VMD to only hold Master Data, Fleet to build solution for Extended Master Data. | Aligned to Master Data strategyDesign will allow configuration for future changesPlatform is autonomous and manages the Extended Master Data | Delays OP2 prioritiesRequires additional GDA engineers to rebuild VMD.Require Fleet engineers to build Fleet solution |
Recommendation
Option 3 is recommended by EA, however it is recognised that this will have the largest initial impact and will require the most resources.
Option 2 will ensure that Vessel Master data solution is fit for the 2030 integrator strategy, however it will require additional engineering resources and may cause resource allocation challenges for Extended Master Data maintenance in the future.
Option 1 will ensure delivery of the OP2 work. In the future VMD can be redesigned and the recommended architecture can be implemented. This deviation from Master Data Strategy will be recorded in the Technical Debt register.