I'm having some issues on correct configuration to set up which application is the source versus consumer.
Ref: information/core_il_data_object_provider_model.xsl
Could someone provide the schema required? I seem to have some cases correct and some reversed as well as some showing the correct colour but no application name showing.
Thank you.
Regards, Rick
Data Provider Model
-
Rick.Allen
- Posts: 23
- Joined: 21 Jun 2012, 18:08
Rick Allen
Enterprise Resource Planning (ERP) Analyst
Hamilton Police Services, Ontario, Canada
Enterprise Resource Planning (ERP) Analyst
Hamilton Police Services, Ontario, Canada
-
jonathan.carter
- Posts: 1087
- Joined: 04 Feb 2009, 15:44
Hi Rick,
Thanks for your post. The Data Object Provider Model is a powerful View but is certainly a View that could do with a View Manual. The objective is to show how Data is managed and shared between the systems in the architecture and can show potential [master] data management issues.
The main elements in the repository that this View uses are:
- Application to Information relationships [APP_PRO_TO_INFOREP_RELATION] which define which Information is being used by which application. All integration messages are captured in the repository as Information Representations, including data integration. However, in the context of this View, mostly we capture the database (=Information Representation, e.g. App1 Operational Database) that is being used by the application.
- The Application slot on here points to the Application Provider that is using the Information that is in the Information Used slot. We can also capture the CRUD for this information in the context of the Application Provider - does the application create / read / update / delete the information (if we know that)
- In the context of these Application to Information relationships, we capture the specific data elements that are being used. However, we don’t connect directly to the Data that is being used, rather we use another relationship to provide the context for how that data is used in the context of our APP_PRO_TO_INFOREP_RELATION.
For the View to work correctly, we only need to specify the Data Representation that is being used (this is the Data that the Data Provider Model centres on) and to define where that Data has come from, we specify the Data Source, again via an APP_PRO_TO_INFOREP_RELATION to show which Application we are receiving the data from and via which Information element (e.g. an integration message).
To show that App1’s database is receiving Product data from App2’s database, we:
1. Create an APP_PRO_TO_INFOREP_RELATION for App1 and App1 Operational Datastore from the ‘uses information slot’ on the App1 Application Provider form. UPDATE: Make sure that the 'Is Persisted' checkbox is ticked.
2. Create an APP_PRO_TO_INFOREP_TO_DATAREP_RELATION on the new relation in step 1 from the Specific Data Operated on slot.
3. Choose the specific Product data (e.g. App2 Product Data) in the ‘Data Representation’ slot.
4. To show where this is coming from create a new APP_PRO_TO_INFOREP_RELATION from the ‘Data Sources’ slot on the relation from step 2. UPDATE: Again, make sure that the 'Is Persisted' checkbox is ticked.
5. Choose App2 in the Application slot and App2 Operational Datastore in the Information Used slot.
- The colouring of the applications is determined by the System of Record slot on each Data Object. We use this to define which system (Application Provider) it is that is designated as the master source for creating and changing all instances of the specific type of data. Good data management practice suggests that there should be a single system-of-record for any type of data but the reality is often that we have more than one system in which e.g. product data is mastered.
If there is no system of record defined for the type of data (Data Object) then the source system(s) are shown in yellow. Identified systems of record are coloured green and red when they are being used as a data source when they are not the designated system of record.
We need to make sure that any Data Representations that we’ve been using in the above relationships are mapped to the relevant Data Object (e.g. in my example above, ‘App2 Product Data’ is mapped to ‘Product Item’ Data Object, which is itself would be mapped to the ‘Product’ Data Subject) to make sure that we can find all of the Data Representations of the selected type in the Data Provider Model and see how Product data is created and shared across the systems.
I appreciate that this is a bit fiddly but it enables us to capture the subtlety of how data is being shared with a high level of fidelity. Let me know if you'd like me to go into any more details on this.
Jonathan
Thanks for your post. The Data Object Provider Model is a powerful View but is certainly a View that could do with a View Manual. The objective is to show how Data is managed and shared between the systems in the architecture and can show potential [master] data management issues.
The main elements in the repository that this View uses are:
- Application to Information relationships [APP_PRO_TO_INFOREP_RELATION] which define which Information is being used by which application. All integration messages are captured in the repository as Information Representations, including data integration. However, in the context of this View, mostly we capture the database (=Information Representation, e.g. App1 Operational Database) that is being used by the application.
- The Application slot on here points to the Application Provider that is using the Information that is in the Information Used slot. We can also capture the CRUD for this information in the context of the Application Provider - does the application create / read / update / delete the information (if we know that)
- In the context of these Application to Information relationships, we capture the specific data elements that are being used. However, we don’t connect directly to the Data that is being used, rather we use another relationship to provide the context for how that data is used in the context of our APP_PRO_TO_INFOREP_RELATION.
For the View to work correctly, we only need to specify the Data Representation that is being used (this is the Data that the Data Provider Model centres on) and to define where that Data has come from, we specify the Data Source, again via an APP_PRO_TO_INFOREP_RELATION to show which Application we are receiving the data from and via which Information element (e.g. an integration message).
To show that App1’s database is receiving Product data from App2’s database, we:
1. Create an APP_PRO_TO_INFOREP_RELATION for App1 and App1 Operational Datastore from the ‘uses information slot’ on the App1 Application Provider form. UPDATE: Make sure that the 'Is Persisted' checkbox is ticked.
2. Create an APP_PRO_TO_INFOREP_TO_DATAREP_RELATION on the new relation in step 1 from the Specific Data Operated on slot.
3. Choose the specific Product data (e.g. App2 Product Data) in the ‘Data Representation’ slot.
4. To show where this is coming from create a new APP_PRO_TO_INFOREP_RELATION from the ‘Data Sources’ slot on the relation from step 2. UPDATE: Again, make sure that the 'Is Persisted' checkbox is ticked.
5. Choose App2 in the Application slot and App2 Operational Datastore in the Information Used slot.
- The colouring of the applications is determined by the System of Record slot on each Data Object. We use this to define which system (Application Provider) it is that is designated as the master source for creating and changing all instances of the specific type of data. Good data management practice suggests that there should be a single system-of-record for any type of data but the reality is often that we have more than one system in which e.g. product data is mastered.
If there is no system of record defined for the type of data (Data Object) then the source system(s) are shown in yellow. Identified systems of record are coloured green and red when they are being used as a data source when they are not the designated system of record.
We need to make sure that any Data Representations that we’ve been using in the above relationships are mapped to the relevant Data Object (e.g. in my example above, ‘App2 Product Data’ is mapped to ‘Product Item’ Data Object, which is itself would be mapped to the ‘Product’ Data Subject) to make sure that we can find all of the Data Representations of the selected type in the Data Provider Model and see how Product data is created and shared across the systems.
I appreciate that this is a bit fiddly but it enables us to capture the subtlety of how data is being shared with a high level of fidelity. Let me know if you'd like me to go into any more details on this.
Jonathan
Essential Project Team
-
Rick.Allen
- Posts: 23
- Joined: 21 Jun 2012, 18:08
Thank you for the explanation it clarified the area.
Initial input by us appears to have taken the slot "Information used" to mean those data attributes used from the internal application rather than acquired from an external information store (I.E. the source/provider).
Your short explanation has stopped a lot of head scratching. Yes, a manual on this portion of the application, data and information relationships would be very helpful.
We have mapped Business Processes and applications from the top down and are continuing down through the various levels with the end goal of doing a much better job of Change Management.
Regards, Rick
Initial input by us appears to have taken the slot "Information used" to mean those data attributes used from the internal application rather than acquired from an external information store (I.E. the source/provider).
Your short explanation has stopped a lot of head scratching. Yes, a manual on this portion of the application, data and information relationships would be very helpful.
We have mapped Business Processes and applications from the top down and are continuing down through the various levels with the end goal of doing a much better job of Change Management.
Regards, Rick
Rick Allen
Enterprise Resource Planning (ERP) Analyst
Hamilton Police Services, Ontario, Canada
Enterprise Resource Planning (ERP) Analyst
Hamilton Police Services, Ontario, Canada
-
jonathan.carter
- Posts: 1087
- Joined: 04 Feb 2009, 15:44
Thanks for the feedback, Rick
Our concept for Information and Data is that the data provides the elements/building blocks that are used to provide the information. Business Processes produce and consume information via 'applications' (which need not necessarily be IT applications). Our interactions with applications (manually or automated integration) operate with information. In this context, the applications operate on the data elements to provide / use information.
Our meta model has evolved to this approach based on delivering solutions to support data management activities and works well, supporting many of the subtleties of the real world. We tend to find that the number of data elements (e.g. Data Objects) is relatively low compared to the information elements which use these data elements, as we define an information element per report, integration message, application 'page'/'screen', applying the maxim that "information is data in context".
As the numbers of elements increases, we make extensive use of our spreadsheet-based integration solution to automate the capture of the relationship classes between applications, information and data and this has proved to be very effective.
Jonathan
Our concept for Information and Data is that the data provides the elements/building blocks that are used to provide the information. Business Processes produce and consume information via 'applications' (which need not necessarily be IT applications). Our interactions with applications (manually or automated integration) operate with information. In this context, the applications operate on the data elements to provide / use information.
Our meta model has evolved to this approach based on delivering solutions to support data management activities and works well, supporting many of the subtleties of the real world. We tend to find that the number of data elements (e.g. Data Objects) is relatively low compared to the information elements which use these data elements, as we define an information element per report, integration message, application 'page'/'screen', applying the maxim that "information is data in context".
As the numbers of elements increases, we make extensive use of our spreadsheet-based integration solution to automate the capture of the relationship classes between applications, information and data and this has proved to be very effective.
Jonathan
Essential Project Team
