One of the key advantages touted by using SOA is the way that integrated systems are 'decoupled'. When I was chatting with a colleague last week about this I realized that the meaning of 'decoupled systems' is less obvious than I originally thought.
When I was reading Roeland Loggen's Process transformation - perspectives on "BPM" blog this morning something he says around the use of process really helped me put my thoughts about 'decoupled systems' into some sort of order.
The post was From interface spaghetti to process coordination layer. Roeland gives a little of the history we are used to hearing around integration: in the olden-days we thought about integration purely as a technical and data-driven problem; technically how do we connect to each system and then join the operations and data elements of this system, to get another system to store, retrieve, update, delete or whatever some related but otherwise completely separate entity in its world? Through proprietary technical protocols and translating the requirements of one system and coding them directly to the data requirements of another. It works, but do this enough times and you have point to point spaghetti.Its not a new story. What comes next though clearly pushes back on the enterprise application integration (EAI) and enterprise service bus (ESB) approaches to integration. Again, suggests Roeland, these approaches lead to integration spaghetti, just now this spaghetti is standards based (guaranteed pure Durham wheat, made in Italy). Although I would suggest the ESB approach does remove point to point hassles, by at least handling the technical integration layer with each system once only. So rather than needing all the technical integration between each system, the problem is reduced to requiring a transformation of data to be handled for each system to system connection. Doing this we swapped the proprietary protocols with web services (unless you live in the real world of web service interoperability) and made integration more an effort of converting one format of XML document to another.
What Roeland argues nicely is that it is BPM and the management of a process in general, not pure EAI/ESB technology alone, that solves much of the integration problem, especially decoupling systems.
So, what is 'decoupling'? We use SOA principles to access information systems through meaningful business services, rather than system specific APIs; which hides the complexities of the systems themselves. But rather than connecting the output of one service or system directly to the next service request, we decouple them, only making requests to services in the context of the business process - the business process becomes the orchestrator of all activity.
What are the advantages of doing this?
- Process that was originally embedded inside the coding of business systems and services is extracted to a BPM and therefore becomes more manageable and can be updated as needed.
- Integration code does not need to concentrate on a specific process or activity context, since the new business services only rely on the state of the business process to ensure correct operation, not on the hard to maintain state information held inside another proprietary application being in-sync with itself.
- Complex dependencies between applications are broken, making maintenance easier, and the ability to reused services (and their underlying systems) far more likely.
- Process that was previously embedded, that mixed coding specific requirements, integration activities and true business process can focus on the specifics of each in the most appropriate tool: the business process in BPM; integration in code or an ESB; application specific state in the application code.
So I think I can finally communicate what 'decoupling' is, and why its so important...
Business level interactions with other services should not be coded within the systems themselves, since this makes it impossible to use them in a different context or even variation of the same process. Decoupling of systems is about removing representation of business process state or cross service interactions from underlying applications, so they generally only interact as part of the business process managed by BPM.
Maybe someone out there has an even better description of decoupling. Let me know.
So after all that, we come back to the convergence of BPM and SOA. It seems that you can not in fact decouple systems and services without BPM - true SOA can not really truly exist without some form of business process orchestration. So why not use the strongest business process management technology, which enables the use and hosting of services straight out of the box? SOA and BPM need each other, and decoupling is just one example of this.
Technorati tags: Financial Services Technology SOA BPM decoupling
A post from the Improving New Account Opening blog
