Meta Data Demo Cases | Demo Case DaMAcademy | Objects | ERP |

ERP

ERP (or EAM) functionality for the registration of data within a number of highly standardized processes using asset data.

Package Objects
Auteur Bert Dingemans
Alias
Stereotypes ApplicationFunction

Diagrammen

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
Diagram in repository

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
Diagram in repository

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
Diagram in repository

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
Diagram in repository

Gekoppelde elementen

Objects

Links 2 Tags

Archimate Architect Architectuur Architectuur document Architectuur repository Ario Azure Big data Bouwblokken en patronen Bpmn Criteria Custodian Data Data architectuur Data governance Data kwaliteit Data management Data modelleren Database Datamodelleren Document Enterprise architect Enterprise architectuur Idea Image library Instruction Intervisie Logisch applicatie model Master data Matrix Mdg Metadata Metafoor Metamodel Modelleren Open source Principes Register Releasemanager Repository Simulator Software Sparx enterprise architect Sql Stakeholders Stappenplan Time aware modelleren Tips en tricks Training Videokanaal Viewpoint Webvideo Werkproces Whitepaper Wpp