We rolled out the first version of our SOA about a year ago. It was a big effort and a huge change in direction for us as a company. At that point, it was a brave step as SOA was more of a concept than a reality in most people’s eyes. But we did it. V1 of the SOA was just what you might expect, total vertical transparency for a few core systems and data stores. Nothing fancy, just a collection of services exposing consolidated logic. By itself, for us, it was a huge step in the right direction. We now have a single code base with which we can interact consistently with core systems and the interoperability of web services so we can extend this functionality to other platform and vendors.
Sounds great right? OK it is, but it also seems to have its own drawback. You see, now that this SOA, admittedly still in its infancy, is seen as a viable solution, the drive to push applications through it is strong. This is great, save the issue of business intelligence.
There are two sides to the SOA development coin as I see them; Service Orientation (SO) and Business Intelligence (BI). SO represents the vertically transparent services which expose the functionality of a system or individual stores of data within the enterprise as services. There is no defined interactivity between these services, the messages are simple and small, and the service interfaces are very coarse in their granularity: AKA Information Silos.
Business intelligence, however, is the aggregation of these granular services spanning multiple systems. A layer, if you will, that spans these information silos and they are driven by the processes defined by the business. To me, this is the biggest payoff for an SOA concept and where you really start seeing the opportunities to ‘trim the fat’ from the existing processes. Lets say you have a process for customer address change, where there are several key systems maintaining independent profile data on a customer. When it comes time for that customer to change his/her address, it must be replicated throughout many systems, across many departments, by many people. Even better, it needs to be done accurately; Remember, To Err is Human! Add any amount of logic necessary for sending out notification letters or flagging records and you’ve got a process worthy of SOA implementation in the form of BI.
The payoff is simple, once you have this process coded for and exposed; you’ll have a consistent automated process for changing address. The process can then be offered publicly without any worry as to process adherence by the subscribers. It’s all there. Of course there are lots of contingencies to deal with in the real world. For instance, processes change right? That’s where the choice in architecture to orchestrate these processes comes into play. Orchestration is a topic unto itself, one I will be covering in a different entry.
