Register Data Consumption

Abstract architectural entity for the register data consumers, all user interfaces and data integrations are an master data consumer

Package Objects
Author Bert Dingemans
Alias --
Stereotypes ApplicationFunction

Diagrams

Scenario models consumer perspective

In this master data consumer model a limited view of the relevant architectural entities are displayed. Here you see a high level model of register data consumption. Via different application functions data is consumed. For example via user interfaces like reports, portals, geo viewers etc data is directly consumed by various end users. A detailed inventarization of these end users and user interfaces will be modeled.

Scenario model data collaboration

In this scenario the master data register collaborates with the various data producing application functions. This means that when data is modified in one of the systems these modifications are shared between all collaborating functions. Therefore the integration between these data producers is essential in this scenario
An interesting scenario in this is where the Data Register is only used as a key store or key cabinet and the detailed data is kept in the other source systems

Advantages
- Data is gathered directly from source systems and thus it is always accurate and real time.
- Data can be stored within the source systems in a specific format supporting the business processes within these systems
- Differences in availability between consumers and sources can be handled by the Data Register
- Reuse of screens, workflows and validations in the source systems
- Data standardization within the Data Register
- Introduction of a key store or key cabinet.

Disadvantages
- Managing the synchronization between systems is an extra piece of work and complexity.
- Replication of data
- Complex data transformations from sources to register and back

Scenario model data collector

In this scenario data is collected form the various data producing applications and combined and standardized in the master data register. This means that data is modified in one of the data producing applications and eventually enriched in the data register. The data register is mainly a data replication with a standardized data model of the other data producers. An example is a datawarehouse

Advantages
- All data directly integrated at hand.
- Standardization of data is possible within the Data Register
- There is a possibility to enhance data by intelligently combing it to new information.
- High availability only for the data register when consumers need a high availability
- Data validation can be implemented in the system where it is most advantageous/efficient
- Reuse of screens, validations, existing data integrations and workflows
- Supports a iterative migration to a more centralized (register) scenario

Disadvantages
- When integration of data is asynchronous the data is not the same as in source systems on every moment. This will not be a problem if timing is not an issue.
- When synchronization of data is synchronous high availability requirements for the registry systems is necessary
- Data replication and need for extra storage
- Fetching and distributing data back and forth is equally much work as with an MDM solution
- Possible very complex data transformations necessary

Scenario model data registry

In this scenario there is only one master data producing application. That is the data register. It can also be one of the existing source systems. All other applications are consuming this data from the data register and use this in their application processes. This includes the application functions for ERP and geo etc.

Advantages
- The service design is directly mapped in the data register.
- Possibility to standardize the information model and service interfaces
- Verification and business rules are implemented only in the dasset data register.
- Real time alignment of the data only upon read/request
- High availability only necessary for the data register.
- Eventually no replication of data (depends on the maturity of the consuming systems)

Disadvantages
- Any change in data model in consumers leads to change in service, this should be aligned or require a large standardized datamodel in the service interface.
- Information provisioning to applications needs to be redesigned which is a lot of work
- Redesign of the full application landscape
- High demand in performance and availability for the data register
- Introduction of a single point of failure so extra non functional requirements in AIC

Scenario model data service

In this scenario there is no data register but all master data is stored within the data producers like ERP and geo functions. However for the data consumers the data is available via the asset data services in a standardized manner. This means that when a consumer needs asset data this is requested via the data services and collected from the various data producing applications. The implementation of the data services handles the standardization of the master data model and the data exchange protocol

Advantages
- Real time alignment of the data.
- Single Point of Truth and Maintenance
- No replication of data (and the involved complexity)
- Reuse of existing user interfaces, validations and (hidden) integrations

Disadvantages
- The service design should not enhance the data so the application might have to be redesigned.
- Any change in data model in sources leads to change in service, this should be aligned.
- Verification and business rules are implemented in source systems.
- High availability and performance needs for all the producing systems
- Complex model transformations within the service layer to transform for specific producer system model to the required model by the consumers
- Releases of the source systems become more complex because of the new dependencies in the data services

Copyright © Interactory