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.
|