SOA and SID

It is not too strong a statement to say that without SOA (or EAI) the SID is little better than an academic exercise. I have spent too many years at Telcos all over the world producing detailed Enterprise Data Models only to see the results filed and forgotten as soon as the project was over. But now that SOA and EAI are well defined and feasible to implement, an Enterprise Data Model, such as SID, becomes much more than a pretty diagram for the CIO to hang on his wall.

In this blog I am going to briefly look at SOA and SID.

A vital ingredient of a successful SOA is a loosely coupled architecture – one in which each component (system) is completely unaware of the inner workings of the other system, and only aware of the services the other systems support (and require) and the information provided or necessary to get the service to work.

A service offered by a component will (unless there is strong architectural governance) offer that service using the data structures and concepts native to that component. Anyone using that service will have to know and understand these structures and concepts – and immediately the goal of a loosely coupled architecture is lost.

For example a service may state that it provides details of the customer’s subscription when provided with the customer account number. But to understand the information provided the service requestor must be aware of the way the service provider defines ‘subscription’ and the definition of each of the products and services listed under that subscription. In other words to use this service you have to adopt its definition of the products or services or alternatively translate that definition into your own definition (which in turn requires knowledge of the service provider’s definitions). Neither approach will result in a ‘loosely coupled’ architecture.

Once this constraint is realised then the Enterprise Architect needs to find a common definition of these business concepts that expresses all the concepts in the enterprise in a complete, unambiguous, agreed and system independent manner – precisely what SID does.

So the SID becomes the language of the SOA providing a vocabulary, grammar and syntax to used by services to provide or receive information. Each service provider is responsible for translating its information into the SID syntax and each service receiver is responsible for translating from SID to its own private syntax. When this is done each service is completely independent of every other one and can be replaced or upgraded without impacting any of the other systems in the enterprise.

Of course it could be that a system decides to adopt SID as its internal syntax, thus saving on the effort of translation – but this is not a requirement of SOA and the use of SID – it is unrealistic to expect Commercial Off the Shelf Technology to adopt SID internally, firstly because some applications within the OSS are not exclusive to Telecoms (e.g. CRM, Finance etc) and secondly the structures within the system will have been tuned to provide the performance and throughput necessary for something like a Billing system.

However one component could have particular benefit of adopting SID as its internal syntax and data model is the Enterprise Data Warehouse as this could significantly reduce ETL effort as all the information providers in the SOA would be providing their information in SID syntax.