Concept: Information Model
This concept introduces the concept of the information model, which is also referred to as a conceptual data model.
Relationships
Main Description

To understand the concept of an information model, we need to take a look at the hierarchy of knowledge:

Data

  • A fact in its raw form
  • Asset based
  • Always persistent (stored somewhere in some form)

Information

  • Has semantic context and meaning
  • Based on understanding
  • Can be either persistent on transient (to a degree where potentially it only exists in the mind of someone)

Knowledge

  • Information applied in process context
  • Always transient

Classically, IT has mostly had its focus on data, typically with a management perspective. With SOA and the resulting need to structurally understand relationships between services, processes and information, all in a business value context, the focus is shifting much more towards knowledge. From a business process perspective, what is produced and propagated through the process is knowledge - knowledge that has a symbiotic relationship to the underlying information. All of this means that information in general, and information life cycles in particular, is important to the SOA practitioner.

In the same way that a data model is built from data entities, an information model is built from information entities, representing "atomic" pieces of information as well as the relevant relationships and dependencies. What is different is that where a data entity must have some real shape or form, an information entity might not (yet) exist as anything but an architectural abstraction. A few examples:

  • At the early stages of a project, an information model is developed in order to capture the reporting requirements of the solution. We do not yet have any idea how to derive the information entities from data, nor for that matter whether it is even realistic, all we know is that there are the information requirements raised on the solution.
  • An information model is developed to capture the information entities being leveraged in a sales process. Some of these information entities might later be based on data, others might be provided by people interacting in the process, never captured as data at all.

What we can deduce from these examples is that the concept of an information model is a logical, architectural concept, and that not all information entities ever end up being supported by underlying data. In order to provide a business solution, we typically always are in need of an information model. In order to provide IT enablement of that solution, we will need a data model corresponding to only that part of the information model that is in fact IT enabled.