Linking Information and Data to Processes and Applications
The information and Data layer allows you to model the Information that is used by Business Processes and Applications and also how the Data is stored by your applications. To do this we use relationship classes, this tutorial describes the key relationship classes available:
Linking Information to Applications
We link the Information used by Applications via a relationship class that we call the APP_PRO_TO_INFOREP_RELATION (Application Provider to Information Representation).
Information Representation describes how a view is represented using a specific technology. This representation can be, for example;
- a Database
- a Feed between applications
- a Report, etc.
The relationship class allows us to capture which Application(s) are using which representations, and details such as CRUD and persistence.
To model the relationship:
- Define the Information Representation that is being used (this should already contain the link to the Information View if required).
- Click on the ‘Used by Applications’ slot and select New to create the APP_PRO_TO_INFOREP_RELATION
- Add the Name of the Application that uses this Representation.
- A series of drop-down options are used to capture whether this Information is created, read, updated or deleted.
- Tick the ‘Does this Application Persist the Information’ slot if the Application stores this information in any way. This is very important as it indicates that there is a data store related to this application.
- The ‘Data Representations Operated On’ slot is used to capture how the Data Objects are stored and/or used in the Application. This is also a Relation Class, and the specifics of how to capture it are covered in the next section.
You have now linked your Information Representation to your Application.
Adding Information to Application Dependencies
The Information Representation can also be a feed between Applications. To add this Information to the Dependencies requires the use of another relationship class – the
APU_TO_APU_STATIC_RELATION (Application Provider Usage to Application Provider Usage). To model this:
- Go to the Application Provider or Composite Application Provider class.
- Using the ‘Application Dependencies’ slot, define a Static Application Architecture in the graphical editor.
- Add the Information that is exchanged between the two Applications by clicking on the line connecting them and selecting Edit Usage. From the new form select ‘Information Exchanged’ and select New to create the APP_PRO_TO_INFOREP_RELATION as described above.
Linking Applications to the Database and Database Tables
When an Application uses Information (in the form of an Information Representation) it typically operates on Data Representation (usually a Table in a Database).
The APP_PRO_TO_INFOREP_TO_DATAREP_RELATION (Application Provider to Information Representation to Data Representation) relationship class is used to define the relationship between the Application and the Data the Application is using that is stored in a Table in the Database, for example, Employee Table in Oracle HR Database managed by Oracle HR.
To model the relationship:
- Follow the instructions for modelling the APP_PRO_TO_INFOREP_RELATION as described above, to point 6.
- Click on the ‘Data Representations Operated On’ slot to capture how the Data Objects are stored and / or used in Application and select New to create a new APP_PRO_TO_INFOREP_TO_DATAREP_RELATION
- Click on ‘Data Representation Used by Application’ and select or create the relevant Data Representation.
- A series of drop-down options are used to capture whether this Data is created, read, updated or deleted. Note that an explicit value of ‘unknown’ is used where we have no information about any of these operations, we should only use ‘Yes’ or ‘No’ where we definitely know that this is the case – the default is ‘unknown’.
- Use the ‘Information Representation that is Source of Data’ to define where this application sources this data, for example it may come from a feed from another application. This is also an APP_PRO_TO_INFOREP_RELATION, for example, Application A may remotely connect to the CRM system database in order to find address data. The Acquisition Method field tells us how this data is acquired and includes, messaging, manual data entry, batch file or Data Service. The set of acquisition methods is fully extensible without the need to modify the Essential Meta Model.
The metamodel diagrams for linking data to applications can be seen in the document below:
Linking Information to Business Processes
We can link the Information View to a Logical Process to identify the types of information that a business process will require, for example, the Manage Payroll business process will need Payroll information.
- From the Business Process (or Business Activity or Business Task) select the ‘Information Used’ slot and select New to create the BUSPROCTYPE_TO_INFOVIEW_RELATION.
- Select the ‘Information being Used by Business Process Type’ slot and select the relevant Information View.
- A series of drop-down options are used to capture whether this Information is created, read, updated or deleted as par of this process.
Note that an explicit value of ‘unknown’ is used where we have no information about any of these operations, we should only use ‘Yes’ or ‘No’ where we definitely know that this is the case – the default is ‘unknown’
Linking Information to an Application being used in a Business Processes
We can link the Physical Business Process (the business process being performed by a specific organisation or team) to the application it is using to manage or create Information.
This relationship is called the PHYSBUSPROC_TO_APPINFOREP_RELATION and effectively links the organisation performing a business process (the physical process) using the information provided by an application (APP_PRO_TO_INFOREP).
- From the Physical Process select the ‘Information being used to Support Process’ slot and select New to create a New relationship.
- You now need to either select an existing APP_PRO_TO_INFOREP or create a new one, as described above.
Defining the Physical Data Store for an Application
An Information Store captures the Physical Deployment of an Information Representation and the deployment role for that store. You can also capture the physical data objects that are contained within a particular Information Store.
At the Physical Data Object level we can assign Service Qualities, such as completeness, accuracy or timeliness. Such qualities have no meaning at a logical level, but when we are describing the actual physical data objects in a particular, identifiable Information Store, we can describe the quality of that data, using Information Service Qualities.
To model the Information Store:
- From the Information Representation select ‘Deployed to Information Stores’ and select New to create a new one
- Add the Deployment Role
- You can now add the Physical Data Objects using the Contains Physical Data slot. This is a direct relationship between the Information Store and the Physical Data Objects that it contains.
- You can also define the Organisational Scope for the Information Store by linking the organisation(s) to which this Information Store applies. For example, we can identify that the Information and Data contained in a particular Store pertains to a specific part of the enterprise, e.g. a European CRM database might contain customer data for the Europe division only.
The sort of questions you should be looking to answer from the data layer are:
‘Which business processes and applications use this data?’
‘What is the source of record for the data used by this application and process?’
‘Do we have duplicate information sources?’
Updated 29 November 2023