The Information Layer of the Essential Meta Model is where elements concerning information and data are captured and managed.   This tutorial introduces the Information Layer and gives an overview of the main constructs available for modelling Information and Data Architecture, once you have applied the Information and Data release.

Overview

In Essential we treat Information and Data as different things and we have separate meta classes for managing Information and Data.
We use a simple definition (that may be familiar) for understating the distinction between data and information; Information is Data in context, whereas Data has the same value and meaning regardless of the context in which it is used.

However, it is important to remember that Data is not always just the facts. Information changes over time and its uses differ from one department of the organisation to the next. New areas of the business will require new Information to analyse and understand how this area is operating. The underlying Data, which provides the building blocks for the Information – some of them facts –remains relatively constant.

Data is managed across a number of categories, such as Master Data, Reference Data, Transactional Data, as simple basic data and complex data elements that are constructed from other data elements.

Information is produced and used by business processes and applications, such as reports, Business Intelligence dashboard contents, details on an application screen or the integration messages that are exchanged by applications.

This approach allows us to manage the Information and Data in support of Information Architecture activities, as well as Enterprise Data Management and Enterprise Information Management.

As with the other layers of the core meta model, the Information Layer is split into the following views:

• Conceptual - where we define the ‘what’. In information terms this means ‘what’ information concepts and data subjects are required within each business domain.  Information concepts capture the type of Information items that are used in the course of running the business and data subjects capture the type of Data items that are used to deliver the information that is required to run the business.
  
  • For example, Cost is an information concept and Customer is a data subject.  Both are used by many parts of the business.
• Logical - The logical area is where we define the ‘how’.  In information and data terms this is the next level of abstraction down, where we define ‘how’ the information concepts and data subjects are used, for example Marketing and Production might both require different views of the same Cost and Customer concepts. The logical layer will define how the Objects are stored and the various Views of the concepts in terms of what information each contains.
• Physical - The physical information view captures the store where a particular View of information is managed, and the data that is in that store.

The major constructs for capturing Information and Data Architecture elements are shown in this diagram. The following definitions describe and provide some examples of each construct.

Conceptual Layer

• Principle - High level rules that govern the manner in which information concepts are managed by the enterprise and provide the context for designing and defining how these concepts will be realised, e.g. Single Master Source of Information
• Objective - A strategic goal associated with the Information Architecture e.g. We will reduce the duplication of information stores.
• Information Concept - High level, conceptual elements that capture the type of Information items that are used in the course of running the business. Information Concept provides the semantic grounding for all the logical and physical information items. e.g. Cost, Stock Volume, Production Order
• Data Subject – High level, conceptual elements that capture the type of Data items that are used to deliver the information that is required to run the business. Data Subject provides the semantic grounding for all logical and physical data items e.g. Customer, Product, Site

Logical Layer

• Information View - Defines a refinement of an Information Concept that describes a particular view of that Concept, e.g. Actual Material Costs for Period.
• Data Object - Defines a logical grouping of data attributes that are used across the processes of the organisation to deliver information, e.g. Bill of Materials
• Information Representation - Describe how a view is represented using a specific technology. Gets it definition and attributes specification from the View, e.g. ERP Materials Costs Actuals Europe
• Data Representation - Defines how the Data Objects are stored and / or used in Application systems, e.g. Bill of Materials in ERP

Physical Layer

• Information Store - Defines a physical deployment of an Information Representation and captures the deployment role for that Store, e.g. Production, Development, Test
• Physical Data Object - Defines the physical data that is stored in an Information Store. The nature of this physical data is defined by the related Data Representation, e.g. Customer Master in ERP Data – Production

Relationships

APP_PRO_TO_INFOREP_RELATION
Relationship class that manages the relationship between Application Providers and the Information Representations that are used by it, in terms of CRUD and persistence.

The first two fields define the Application Provider and the Information that is being used. A series of drop-down options are used to capture whether this Information 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 – that is we should only use ‘Yes’ or ‘No’ where we definitely know that this is the case. If the Application also stores this information in any way, then we can capture this by checking the ‘Is Persisted?’ checkbox.

The ‘Specific Data Operated On’ field is used to capture the Data Representations that are used by this Application in the context of using the Information, either producing the Information or processing it. Note that this is not a direct relationship to the Data Representation but rather for each that we wish to relate, we define a new instance of an APP_PRO_TO_INFOREP_TO_DATAREP_RELATION relationship class.

Finally, we can capture any comments about this relationship that we may have.

This relationship is reused – with exactly the same semantics – to capture Information that is being provided by an Application. In addition to the new relationships described below, the APU_TO_APU_STATIC_RELATION uses the APP_PRO_TO_INFOREP_RELATION to specify the Information that is exchanged between Application Providers in the dependencies defined in the Application Provider Static Application Architecture.

APP_PRO_TO_INFOREP_TO_DATAREP_RELATION
Relationship class that describes the specific Data Representation that is used by an Application Provider in the context of its relationship to a specific Information Representation.

When an Application Provider uses Information, in particular when it produces Information Representations, it typically operates on Data Representations. This relationship class is used to define this relationship between the Application and the Data in the context of the Information.

The ‘Information Container’ field defines the Application Provider to Information Representation relationship class that provides the context. The ‘Data Representation’ field specifies the Data Representation that is being operated on. In this context, we can capture whether the Data is created, read, updated or deleted. Note that as with the Application to Information relationship, the default values for these CRUD values are ‘Unknown’. Capturing this level of detail enables us to identify master data management issues that may exist, e.g. where master data is being created by more than one application.

The Data Sources field specifies the source of this Data in the context of the Application-to-Information relationship. That is, we can identify where the data D that is being used by Application A to produce Information I. This means also that we can also capture situations such as that Application A sources Data D from an alternative application to produce Information I2 – and this happens in the real world! The source is defined using an Application to Information relationship as we model integration ‘messages’ as Information that is provided by an Application. E.g. 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.
As with the Application to Information relationship, we can capture comments about this specific relationship.

BUSPROCTYPE_TO_INFOVIEW_RELATION
Relationship class to describe the Information Views that are used by a Business Process, Activity or Task.

The first two fields define the Business Process (or Business Activity or Business Task) and the Information View that is being used by the process, activity or task. As with the Application to Information relationships, it is in the context of this relationship that we capture whether the Information is created, read, updated or deleted by the process. If we have any comments about this relationship, we can add them in the Comments field.

PHYSBUSPROC_TO_APPINFOREP_RELATION
Relationship class that captures an organisation performing a business process using the information provided by an application.

In this relationship we are defining which Information is being used as a specific part of the organisation (e.g. a team or individual) performs a process, using a specific Application Provider. Business Processes always use an Application in order to use Information. Note that this Application Provider does not strictly have to be an IT application. In the Essential Meta Model, a paper form is captured as an Application Provider. The Process Performed by Organisation / Individual field specifies the Physical Business Process (or Activity) that is being performed and the Information from Application specifies the Information that is being used via the specified Application.

Note that this is not a direct relationship to the Information Representation but is an instance of an APP_PRO_TO_INFOREP relation – the Information Representation provided by an Application Provider. In this way, we can model conclusively where the information that is being used to perform a process comes from. Any comments about this relationship can be captured in the Comments field.

Application Deployment to Information Store
As part of the Information and Data Pack, the Application Deployment to Information Store relationship has been simplified to be a direct relationship between the Application Deployment and the Information Store.

Information Store to Physical Data Object
In the Information Store, a new relationship has been introduced to capture the physical data objects that are contained within a particular Information Store.

This is a direct relationship between the Information Store and the Physical Data Objects that it contains. Additionally, we can define the Organisational scope to which this Information Store applies. That is, 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.

It is only at the Physical Data Object level that 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.

Again, we can specify the Organisational Scope to which this physical data object applies – we are describing the nature of the data values (but not the data values themselves) from this organisational perspective. In addition, capturing this scope enables us to provide organisational-specific views of the data from the Essential repository.

Information Views

The Information and Data release provide a number of new views to those already available.  These are related specifically to the Information Layer and are all navigated to via the following catalogues:-

• Information Catalogue by Domain - Catalogue of all the Information Objects in the repository organised by business domain. Selecting an Information Object presents its summary view.
• Information and Data Catalogue by Application - Catalogue of Information and Data Objects, organised by the Applications that use them. Selecting an object presents a summary of the Information and Data that the selected Application provides and uses.
• Data Catalogue by Name - Catalogue of Data Objects, organised alphabetically by name. Selecting a Data Objects presents the Data Object Summary view for that Data Object.
• Data Catalogue by Type - Presentation of the conceptual data model as a catalogue of Data Subjects, organised by type. Selecting a Data Subject presents the Summary view for that Subject.

These new views support or provide answers to questions such as:-

‘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?’

For more information on the views, including screenshots please see the Information and Data release news article or the Information and Data release reports tutorial (coming soon).