Architectural Pattern – Information Models

This is the first in a set of related architectural patterns for software architects. Most software patterns are very specialized – for example the GoF patterns are aimed at fixing shortcomings in the C++ family of languages (in which I include Java) that other languages may or may not suffer from. The POSA patterns are aimed very specifically at the implementation of efficient server architectures. An architectural pattern, on the other hand, ought to provide a higher level of abstraction that could find applicability in many languages and/or physical architectures.

This first pattern is a keystone for patterns that follow and is directly referenced by several of them. The others (so far) are:

  1. Policy
  2. Capabilities and Requirements
  3. Control and Notification Channels
  4. Context
  5. Relationships


Provide a documented definition of entities – including their properties, relationships and the operations that can be performed on them – in an abstract but unambiguous manner.


There is often a dichotomy when defining an entity where, on the one hand, you need to not constrain how an entity is implemented, but on the other hand you need to be sufficiently precise so that the definition is unambiguous – and thus can be implemented.

The entities being modeled may be real-world, such as devices on a network, or they may themselves be abstract, such as the entities used in a billing system.


Define an information model of the entities. An information model includes:

  • All of the components
  • Their properties
  • Their relationships
  • The operations they expose

This model can then be mapped to one or more Data Models that define how the information model is represented in a concrete implementation: such as a set of C++ classes, a relational schema or an XML schema etc.

Information models are used to model a constrained domain that can be completely described by a closed set of entities, properties, relationships and operations.

Any formal language can be used to define the information model. For example you might use UML, WSDL or IDL. The key, though, is to make it quite clear that the model does not imply a mapping to a data model. For example the use of UML does not imply a C++ implementation.


Documentation: especially requirements specifications.

The need to define a data model late, or to use multiple data models to meet orthogonal criteria such as performance, scalability, maintainability etc also make the pattern applicable to design specifications and reference documentation.

Known Uses

The Distributed Management Task Force or DMTF provides a standard set of information models for various domains under the general title of the Common Information Model or CIM. Specific information models are derived from CIM for particular management domains.

Comments are closed.

Judge’s Random Ramblings