One of the realities of SOA is that even in the most enthusiastic organisations not all services can or will be delivered by discrete services written in .NET or Java. For historical or pragmatic reasons, some of the functionality is likely to be delivered by business applications. These may be legacy systems that have been bought or developed pre-SOA. In many cases new applications have been brought in post-SOA, much to the architects’ dismay.
Whatever the reason, the integration of new and existing applications into SOA is an essential requirement to retain any architectural control of the application environment. Why do we need to care?
A number of companies I have talked to that have started on the SOA journey have ended up with SOA being a niche part of their estate as business areas become fed up with the perceived delays in delivering business functionality and buy a package solution to meet their needs. In many cases this distorts the architectural standards that have to be modified to accommodate the new technology introduced. At other times an agile initiative has quickly moved from a prototype development and proof of concept to a critical business system before it can be standardised and incorporated into a proper service oriented architecture.
There can be an ongoing tension here as the agile advocates view your SOA as a legacy challenge that is just slowing them down. Controlling ad hoc development is a continuous governance process that if handled properly can harness the benefits of agile development within a standard framework. What they can fail to realise is their agile development is also likely to become a legacy maintenance headache if not built to agreed standards using shared technologies. Way back in the mid Eighties, when prototyping and rapid application development started taking off, 4GLs offered agile development, but in non-standard and non integrated technologies that eventually fell out of favour and are now a significant support headache for many large companies (how are your Mantis and Linc skills?).
Addressing the control of packaged software is more difficult as the primary decision is usually taken by business executives out of the control, sorry influence, of the architecture or IT management. Often there is a clear business imperative to buy in a solution – time to market, or for a completely new line of business. Often, however, it can be driven by personalities, politics or pride. In a few instances the vendor has just pulled a fast one through a great demo or tickets to the rugby.
Given the impossibility, and possibly the desirability, to prevent package acquisition, some order can still be imposed on this potential chaos by applying some guidance and engagement during the package selection process. By specifying some additional selection criteria covering the interoperability of the package, it is possible to ensure that the new application will have minimum disruption to the existing infrastructure and service architecture. These criteria should not be onerous otherwise they are likely to be ignored or challenged by the business. The key criteria should cover access to specific key functionality and information through standard service calls. Based on your desired architecture you can also request that the application uses open standards (WS-*), specific operating systems (Windows or Linux), operate in virtualised environments or support key DBMSs.
Most medium to large package vendors (including SAP and Oracle) offer options of this nature, so you need to ensure these questions are asked. The concept of Service Oriented Business Applications (SOBA) is promoted by some industry watchers as a concept that should be adopted by vendors, and they are encouraging companies to push their suppliers for this. It has not traditionally been seen by the vendors to be in their interest to open up their package as they want to maximise the return on their investment: a ‘black box’ or walled garden approach is seen as more profitable, as IBM, CA, Microsoft and Apple have shown. However, in the long term all previous attempts at lock-in have failed and the unresponsive vendors have been superseded by new players willing to be more open, at least to start with.
SOBA should not be just be considered for new applications. Any planned package upgrade is also an ideal point to press for adoption or adherence to your preferred service standards. As the desired interoperability features become available, any planned upgrade programme should be mandated to look for better adherence to the corporate architecture standards. Conversely, beware the stealthy inclusion of new technology by a package upgrade that could upset your technology mix or lead you down a restricted choice technology avenue.
To get some business buy-in for your typically unwelcome involvement in package selection, you will need to develop a clear business case, detailing the projected costs for different configurations so that the total cost of ownership for the business is highlighted for each choice, and well as the benefits of opening up potentially closed applications for future flexibility and growth. Ultimately a commercial argument rather than an architectural one will win the day. You need to make the case for SOBA-ness…
