Want Your Mobile Apps to Work Better? Start with Canonical Services in Your Enterprise Architecture

To leverage legacy systems so they can be "mobilized," consider adopting an approach that aligns canonical data models in service oriented architecture (SOA) with your message models. Such a data model may be developed top-down based on business requirements or, alternately, through reverse engineering of existing data structures. This is the approach I've used most frequently.

So how to do this?

While it sometimes is difficult to create pure system-independent canonical models, aspiring to that in the context of SOA is a worthy goal. It helps to define data types (think of them as the "leaves" on the tress of your XSD, an XML schema or road map for the XML document). This structure could be similar to data types which are used in the RDBMS in your master data sources.

Next, find the differences -- map the supported data types in other systems and databases within your infrastructure. Typical conflict arises in types like "STRING" or "FLOAT". It pays to use more restricted form of this data type. If the databases contain something atypical -- for instance number of decimal places is lower than number which is required by your legal requirements (especially financial transactions) -- you can then disable that column to do critical transactions by creating a branch in data types. This can then be programmatically set during translations from system-specific data types in your Common Data Model, where you can use common static tables translating. The end result will be a set of data types compatible with your systems and also usable via in semantic standards over your ESB.

The next step is to define basic business objects representing entities within the semantic standard which will have structure, that will be understandable for you business and will be valid for consumers of your services. Of course, you will reuse data types from your data types set and business objects should be dependent on domain. For example, business objects for contract details in different domains if those domains require unique fields. Caveat: data types should be the same; look for archetypes in existing models such as Dublin core.

Finally, define the service interfaces. Are you utilizing a standardized form of message for request and response? Within this form you should use business objects, used whole prevent to fragmentation of interfaces, which could decrease the potential for reuse.

At Bluedog, we have found that canonical data model can provide a common format for the information content of the messages of the individual services, leading to a horizontal alignment of message formats across services.