Information and Data Modelling

10 min


The purpose of this layer is to manage knowledge about the Information and Data required and used in your organisation.

A common question asked is ‘when is something information and when is it 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.

Information is used by Business Processes to perform the process. Applications use and produce information in the course of supporting the business processes.

Examples of Information include:

  • Reports that are produced, e.g. by the BI solutions in the enterprise
  • The views that are presented to us by our applications, and
  • The messages that are exchanged by applications in integration solutions.

Data, on the other hand, is the building blocks that are used to deliver Information. It is stored and managed by Applications. It has no context, having the same semantics in any situation that it is used.

Examples of Data include:

  • Master Data such as Product, Customer;
  • Reference Data such as Currency, Country;
  • Transactional Data such as Sales, Invoice


In Essential, we treat Information and Data as different things, and we have separate meta classes for managing Information and Data. As with the other layers of the core meta model, the Information and Data Layer is split into the following views:

  • Conceptual – where we define the ‘what’. In information/Data terms, this means ‘what’ Information and Data are used or required by the business.
    • For example, Cost is an information concept and Customer is a data subject. Both are used by many parts of the business.
  • Physical – The physical view captures ‘where’ the Information and Data are stored.

 Vgumhxzqoypgwj5fvnjj Informationlayeroverview

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

Conceptual Layer

  • Information Architecture Objective – Captures the objectives that exist for the Information and Data Architecture.
    • Example – We will reduce the duplication of information stores.
  • Information Architecture Principle – High-level rules that govern the manner in which Information and Data are managed by the enterprise. Provide the context for designing and defining how these concepts will be realised.
    • Example – There will be a single master source of information. Data is an asset.
  • Information Driver – Describes internal and external influences that motivate the development of the organisation’s Information objectives. Can impact the drivers in the application and technology layers and be impacted by those in the business layer.
    • Example – One View of Customer (Info Driver) supporting Multi-Channel Customer Interaction (Business Driver)
  • Information Concept – the fundamental information 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.
    • Example – 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.
    • Example – Customer, Product, Site, Employee
TIP: At the conceptual level, it is common to have many more Information Concepts than Data Subjects.

Note: The Information Architecture is focused on understanding the information elements and the architectural dependencies between them, and not detailed Entity Relationship modelling.

Logical Layer

  • Information View – An Information View is a refinement of an Information Concept that describes the ‘type’ of information used, for example in support of a business process. By default, we show the name as Information Concept:Information View so that we can group the Views by the Concepts they are refinements of.
    • Examples:
      • Customer::Customer Services View
      • Customer::Marketing View
      • Customer::Warehouse View
      • Product::Marketing View
      • Product::SKU
      • Client Risk::Compliance View
      • Client Risk::Marketing View.
  • Information View Attribute – Defines an attribute of a View including the specification of how that attribute is derived or calculated from data. In practice, it is often enough to capture at the Information View level, without modelling to the View Attribute level.
  • Information Representation – Describe how a view is represented using a specific technology. Gets its definition and attributes specification from the View. An Information Representation can be, for example, a Database, a Feed between applications, a Report etc.
    • Example, Oracle HR Database; Payroll Spreadsheet
  • Data Object – Defines a logical grouping of data attributes that are used across the processes of the organisation to deliver information.
    • Example, Employee Contact Details
  • Data Object Attribute – Defines individual elements of data. Each attribute has a type that can be primitive or of another Data Object.
    • Example, Employee First Name
  • Data Representation – Defines how the Data Objects are stored and / or used in Application systems. Typically a Data Representation represents a Table in a Database.
    • Example, Employee Contact Details in Oracle HR DB; Employee Name in Payroll Spreadsheet
  • Data Representation Attribute – Captures the individual data attributes in the implementing system for each Data Object Attribute
    • Example, EmployeeID

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.
    • Example – Marketing Customer Database::Production, Order Database::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.
    • Example, Customer Master in ERP Data – Production
TIP: When you bring in the relationships to other layers such as Application and/or Business (see later tutorials), this layer can seem complex, but draw out a few examples on paper first and it soon becomes clear. You will see how the questions you can ask are quite extensive and allow you to answer some key enterprise architecture questions around efficiency, risk, etc.

Updated 21 May 2024

Contact Us