I have been working in Service Oriented Architecture for almost a decade. During that time, as a trainer, architect or consultant – I have probably worked with over 100 businesses and government agencies to address their SOA needs. In every case, as we looked at adopting SOA, the perceived benefits were always somewhat theoretical, not that they weren’t real, rather they would not be realized until sometime in the future. For example:
As our SOA implementation matures and we develop a number of reusable enterprise services — new business processes can be created and existing business processes can be modified quickly, with reduced costs and minimal disruption to the enterprise.
Recently I had the opportunity to work with a bank that was looking at SOA in a very different way. Like other organizations looking to adopt SOA they saw the future, long-term benefits. The difference is that this bank also had a very real, tangible short-term goal for their SOA implementation — a goal that gave them no alternative but to succeed, and they were willing to bet their business on it!
Like many organizations, the bank has a few key enterprise systems that are core to their business. One of these systems (we’ll call it ALPHA) provides access to customer account information. Over the years more and more applications in the bank have become dependent on ALPHA. Unfortunately the integration strategy used with ALPHA has been point-to-point. So even if applications need the same data from ALPHA they each use different code to access it. So ALPHA-specific integration code is spread throughout applications from all the bank’s different businesses. While this architecture has supported the bank’s operations until now, there is a crisis on the horizon.
The bank has decided that ALPHA has outlived its usefulness. It has been upgraded, patched and modified as much as it can be and it is time to move on. On their IT roadmap, they have a project called Core Replacement scheduled for 2016 at which point they will replace ALPHA with a new modern system. Unfortunately, with the point-to-point integration and ALPHA specific code all over the organization this could be a nightmare.
In order to reduce the risk associated with replacing ALPHA the bank has decided to implement SOA. In the near term the plan is to expose the functionality of ALPHA through SOAP Web services. Clients will use an Enterprise Service Bus (ESB) to connect to and request services from ALPHA. ALPHA specific integration code will be moved into an Application Service layer on top of ALPHA. When the replacement occurs the new application (let’s call it BETA) will use the same service contracts as ALPHA. Clients will access BETA through the ESB in exactly the same way. Ideally this change will have no impact on existing consumers of ALPHA. Of course the reality will be different, the SOA implementation will not be perfect. There will be issues. But in the case of an impending replacement of a core system that is critical to its business, the bank has chosen SOA as the most rational risk mitigation strategy. So much of their business depends on ALPHA today and will depend on BETA in the future — they CANNOT fail. Looking at the impending deadline, the complexity of the task and the possible impact on existing systems and the business — they chose SOA.
