Message Modelling

From MIKE2.0 Methodology

Activity: Message Modelling

Objective

Message modelling is done to model "data in motion" and reduces the complexity of the integration layer between different components in the architecture. There are 3 main types of techniques for message modelling:

• A "top-down" approach where messages are defined through a process of gathering requirements -> conceptual design -> logical design -> physical design -> implementation. Oftentimes, this can be done in parallel with data modelling.

• A "bottom-up" approach where messages are built by reference from atomic elements. Multiple sources are used to seed a common repository of reusable building blocks for messages.

• A standards-based approach using open industry standards. This will include gap analysis to determine fit for purpose.

All approaches are valid; using any of the 3 techniques is better than the approach that is followed on many projects, which is to not model messages at all.

The advantages of the different approaches depend primarily on the scope and objectives of the project. Sometimes, a combination or mixing of the 3 approaches may take place. Whereas the "top-down" approach makes the most sense from a purist modelling perspective, the "bottom-up" approach may be the best fit if an organisation is undertaking an infrastructure programme to model messages that will complement their existing data models. The use of standard models can provide an excellent starting point and is generally the best approach for defining message structure for external communications.

As the top-down approach is quite similar to that for data modelling and the standards-based approach provides some starting assets, this activity explains the bottom-up approach. The bottom-up design approach uses a 3-tier, hierarchical architecture with messages developed using open standards XML Schema technology. The foundation of the Common Message Model (CMM) are the Common Data Elements (CDEs) which ultimately define each individually required data element used across the organisation. The CDEs are organised into message subjects that form re-useable groupings of data elements. The message subjects can then be combined to form messages.

Whereas relational modelling techniques are well-established, there is no agreed-upon approach for message modelling other than the core technology (XML). Therefore, it is important to keep in mind that message modelling techniques will impact both the design process and the architecture. The tasks below outline the 3 major tasks of the implementation process for the bottom-up approach. The architecture design is assumed to be done as part of the overall solution architecture process. The Services Oriented Architecture Design Activity illustrates how CMM Messages are used as part of the overall solution.

Major Deliverables

• Definition of Common Data Elements, uploaded to metadata repository
• Definition of CMM Subjects in metadata repository
• Definition of CMM Messages in metadata repository

Tasks

Define Common Data Elements

Objective:

The Common Data Elements provide the atomic set of building blocks for building CMM Subjects and CMM Messages by reference. The key aspects related to the creation of the Common Data Elements are as follows:

• Multiple sources may be used to seed the library of CDEs. Examples of typical sources include operational systems, information systems or even existing messaging standards. The first step is to identify the key sources and define a normalised model to be loaded into the target repository.
• CDE input is prepared by using an input metadata file. Input structures can include data models or files put through a pre-processor. The metadata file will be the input to the CDE Builder application that will build the Common Data Elements repository.
• Logically the CDE will be a list of hierarchical data elements in XSD format. Physically the CDE will be represented by a file system directory structure which will contain XSD files for each data element type/class. A CDE Builder utility is used to create this directory structure and to populate it with XSD files and CDEs are stored centrally in a metadata repository.

After CDEs have been loaded to the central metadata repository, they are reviewed by the Information Development team. Population of CDEs is an iterative process and new sources will be added over time.

Input:

• Logical/Physical Data Models of Candidate Source Systems
• Data Specification Standards
• Data Modelling Standards
• Data Security Standards

Output:

• CDEs loaded into target metadata repository

Develop CMM Subjects

Objective:

In this task, CMM Subjects are built to provide logical building blocks for creating CMM Messages. CMM Subjects are reusable assets that can be used in different CMM Messages (e.g. Address Subject, Customer Subject). These subjects are collections of CDEs that represent a business entity. The rationale behind CMM Subjects is to promote reusability within the system and simplify maintenance for the creation of CMM Messages. Building CMM Subjects involves the selection of the CDEs to be encapsulated in each logical entity into the metadata repository. The key aspects involved in creating CMM Subjects are as follows:

• Definition of the CMM Subject starts by specifying a name for referencing the CMM Subject in other CMM Subjects or in CMM Messages. An empty schema file is first created for the placeholder for the CMM Subject.
• CDEs are added to the schema for the CMM Subject by reference. Whilst they may not originally be from the same source system, all CDEs will come from the same centralised environment.
• CMM Subjects should be built to be environment independent. This ensures that the CMM Subjects are independent of the developing environment and will allow us to port the CMM Subjects to other environments (Testing, Staging, Production).

CMM Subjects should be refined and reviewed by the Information Development team before being made accessible for message creation.

Input:

• CDEs created in Metadata Repository

Output:

• CMM Subjects created in Metadata Repository

Develop CMM Messages

Objective:

Once the CMM Subjects have been identified, a CMM Message is created which encapsulates the required CMM Subjects and additional CDEs that may not be part of a Subject. These CMM Messages model the information that will flow between systems and will be used by Services in the run-time environment.

The key aspects of CMM Message creation process are as follows:

• Definition of CMM Messages starts by creating an empty schema file from which we reference the CMM Subjects and/or CDEs. An empty schema file is first created for the placeholder for the CMM Message.

• The CMM Message references the CMM Transaction Header. Every CMM Message must have a transaction header included as this holds message specific information such as transaction time, an identifier for the message and so on which are required as metadata for a message.

• The Message enlists CMM Subjects and/or CDEs required for the CMM Message CMM Subjects and/or CDEs are chosen that relevant in creating the CMM Message. To create an Address Change CMM Message, for example, a Customer Reference Subject that holds the customer identifier, Account Reference Subject that holds the account identifier and Address List Subject which holds the new address would be used. We then create grouping/hierarchies using the enlisted components.

• CMM Messages should be built to be environment independent. This ensures that the CMM Messages are independent of the developing environment and will allow us to port the CMM Messages to other environments (Testing, Staging and Production).

After CMM Messages have been loaded to the central metadata repository, they are reviewed by the Information Development team. They can then be made available to the integration environment, where they can be used to build Interface Services, Business Services and Data Management Services.

Input:

• CDEs created in Metadata Repository
• CMM Subjects created in Metadata Repository

Output:

• CMM Messages created in Metadata Repository
• CMM Messages available for use in integration environment

Core Supporting Assets

Yellow Flags

• Message definition not using an open standard such as XML
• Message modelling not related to data modelling activities

Key Resource Requirements

• Information Architect
• Data Modeller

Potential Changes to this Activity

• This activity is potentially too specific. It could possibly be generalised to cover taxonmical development and may also be expanded to cover unstructured content models. The content model may also be better defined in a separate activity.

• Taxonomy Design, Data Modelling and Message Modelling are currently defined as separate activiites. It may be better to converge this to a single activity.