A common message

Last month I did some service modeling work for a well known insurance company in the US. After five years of helping customers with SOA this particular company was very mature in terms of their cultural alignment between their business and IT stakeholders and was also adopting some of the best practices and patterns around SOA enablement.

A little background, this company is typical of so many other Fortune 500 companies in that the business struggles with it silo-ed nature, that has been built up over decades. Two simple silos within this organization are the personal and commercial insurances lines, both offering insurance products to different customer bases.

SOA is all about aligning the business with the IT and for this to happen they have to all speak a common language. To help understand this better lets take a simple analogy of the worlds favorite organization the United Nations. Now I am not privy to the internal working of the UN but I do know that it employs a lot of interpreters to interpret from one language to another. Take the example of an interpreter working for the French ambassador. This interpreter will need to be able to interpret from French to Chinese, from French to English, etc or to whatever the native language of the person the ambassador is talking with. This is clearly a very stressful job for the interpreter. Now lets pretend that I have been put in charge of the UN and have decreed that from now on the common international language will be Irish (this would be a complete disaster by the way, as Irish is notoriously a very difficult language with needlessly complicated grammar and syntax, I know this because I spent 14 painful years in school learning it). Now all the interpreters need to know is how to convert from their host language to Irish and back again.

Scaling this up to the enterprise, let us examine three best practices around a enterprise common message model:

1. The first best practice is simply to have one. The business and the IT need to agree upon an enterprise message format, or lingua franca across the organization. Thus what was traditionally a silo-ed organization in terms of personal and commercial insurance (each has a difference via of what a customer/party is) could now start to share service based on a common understanding about what what was a claim, a policy or indeed a customer/party. This really is not news to anyone starting to mature in the SOA space, however, the next best practice is a bit trickier.
2. The second best practice is not to build this enterprise common message model yourself. This can not be overstated. Building a enterprise strength common message model in a big job. To get a sense as to how big, consider IBM Insurance Application Architecture or IAA models. Now I am not here to plug these models, but they have been built up over ten years worth of experience, of practitioners, in the insurance industry. As a result these models are highly normalized and contain some of the best patterns and lessons learned and are what I would consider a mature enterprise model. There are many other enterprise strength message models out there such as ACORD, SID (telco), STAR (automotive) . One also needs to differentiate between industry standard models and priority models and here again I want to outline a best practices in terms of their usage. Industry standard model such as ACORD have been debated and agreed upon by concerned parties within an industry vertical, these models are there typically to level the playing field and provide a good, typically flat, model structure to enable B2B exchanges between companies in that particular business vertical. Priority models on the other hand such as IAA and IBM Information FrameWork Service Models (IFW), are highly normalized models, and are there to provide a company with core differentiation within the marketplace. The best practices then become to use a priority model internally within the organization, to define the internal services and as a lingua franca for the messaging infrastructure and then to use one or more industry standard models to define services that are exposed external to the organization and typically involved in B2B exchanges and delegate to the message infrastructure to convert between them.
3. Finally the enterprise message model must be managed and governed. New versions of these message model are being released all the time as new markets and opportunities arise and your company needs a coherent and consistent way of managing this change. Let us go back to our UN example and imaging that the Irish language was continuously changing (it is not, the Irish language in a considered a dead language), think of the nightmare for the interpreters having to continuously learn a new version of the common language.

For those you foolish enough to want to learn Irish, to champion the cause of having the UN adopt it as a common international language, if refer you to Des Bishop web site

Slán go fóill...

SOA information as a service pattern specifications

Guenter Sauter et al have three excellent SOA Information as a service pattern specification papers on data federation, data consolidation, and data cleansing. You can find these three papers on developerWorks:

• Data federation pattern: The data federation pattern virtualizes data from multiple disparate information sources. The pattern creates an integrated view into distributed information without creating data redundancy while federating both structured and unstructured information. This article describes the federation of structured information (data) with a focus on the SOA context. This pattern specification helps data and application architects make informed decisions on data architecture and document decision guidelines.
  


• Data consolidation pattern: The data consolidation pattern specification helps data and application architects make informed architectural decisions and improve decision guidelines. In this article you will see how you can apply the pattern in the SOA context. The primary business driver for the data consolidation pattern, also referred to as the data population pattern, is to gather and reconcile data from multiple data sources before this information is needed. To do so, it extracts data from one or more sources, transforms that data into the desired target format, and loads it into some persistent data target. The prepopulation of a persistent target is a key differentiator between this pattern and the data federation pattern.
  


• Data cleansing pattern: The data cleansing pattern specifies rules for data standardization, matching, and survivorship that enforce consistency and quality on the data it is applied against. The data cleansing pattern validates the data (whether persistent or transient) against the cleansing rules and then applies changes to enforce consistency and quality. In this article, you learn to apply the data cleansing pattern within a Service-Oriented Architecture (SOA) context. This pattern specification helps you, as a data or application architect, to make informed architectural decisions and to improve decision guidelines.
  

The value and use of Rational Data Architect in SOA

The IBM Information management yesterday announced that the paper "The value and use of Rational Data Architect in SOA" was published today as part of the series "The Information perspective of SOA design"

Here is the abstract from that paper:

Discover how you can use the IBM® Rational® Data Architect, IBM Industry Models and the unified metadata management of IBM Information Server to align process, service, and data models. Use these tools to accelerate your SOA project. The fifth part of "The information perspective of SOA design" series describes the key features of the products that support the data modeling pattern in SOA.