With the current hard times continuing to challenge IT budgets, I fear that all the good effort that is going into SOA currently could be squandered by ill-conceived or rushed outsourcing of the wrong services and wrong responsibilities at the wrong time to the few remaining IT service companies.
It is worth pointing out that the analyst community have consistently promoted SOA and outsourcing as being good bedfellows. There are two main models here:
Do-It-Yourself:
Having defined your key processes you will find and buy the best services to meet your needs on the open dynamic market in business services – this describes the Software as a Service (SaaS) movement. This could be categorised as out-tasking. This, of course, requires you to have worked out your key processes and services and have implemented a hardened (logical or physical) service bus capable of handling external services. This will apply to about 5% of organisations so far.
Give it to the Experts:
All the main outsourcers are promising to Service Orient their infrastructure to provide you with all the benefits of SOA (agility, cost, speed) without you having to worry your pretty little head about the what/where/how of SOA. This relieves the great majority of companies (the other 95% who have so far failed to either ‘get’ or implement SOA) of the perceived pain of trying to do it themselves.
If you are not a DIYer in the first category (no point fibbing – you will definitely be found out on this one), then the temptation to dump the problem on the outsourcers will be very attractive. So what are the right services, the right responsibilities and the right timing for SOA outsourcing?
The right services to outsource are dependent on where you have a defined boundary of responsibility between the service consumer and the service provider. For Business Process Outsourcing (BPO) this may be a high level business service such as Claims Processing. As long as you have a clear process and data interface between the business and the service provider, there is no reason why this cannot work well (other than legal, risk management and commercial issues that I hope you were aware of).
For infrastructure services, where you may just want specific environments with established Service Level Agreements, you are more likely to be faced with technical and architectural issues. In these cases the service you received may be severely proscribed (as it is shared with other customers) and you need to be aware that you have little flexibility to change any of the service attributes. I have seen examples where the customer realised after committing to the contracted service that they had been used to more control over the service (monitoring, environmental changes, etc), and ended up spending significant time and effort to modify their development and support processes and tools to meet the contracted service.
The Right Responsibilities
Defining who does what across a contractual boundary for SOA is particularly tricky. Even with a well populated CMDB (which is unlikely to be shared across the two organisations, let alone with any other partners), dynamic Service Repository (ditto) and a granular Service Catalogue (business, IT and component services, complete will all dependencies and SLAs), it is still only the early adopters with the courage (or blind optimism) to wrestle with the practical challenges thrown up on ownership and responsibilities. Creating a set of service management processes that spans organisations is still bleeding edge, as there is not enough case history to rely on yet.
The Right Time
The first rule of outsourcing is “Don’t Outsource a Problem”. With no clear understanding of the issues in the IT infrastructure or application estate you will pay several times over to get it fixed by your service provider. They are not called outsorcerers for nothing.
With a SOA approach this perversely is potentially easier to get right. The reason for this is that by defining services properly, you are creating a contract boundary for the service. As long as both parties have a common understanding of the levels of service expected, this can work quite smoothly. Many of the early SaaS success stories, e.g. Salesforce.com, are based on this clear distinction.
SOA has specific challenges for outsourcing in that it is more a philosophy than an architecture. All many outsourcers can bring is the effective (and profitable) operation of whatever set of services and systems you hand over to them. If these are poorly defined and managed services you will end up paying them for the privilege of documenting your application and infrastructure landscape, pay them again to change your systems to something approximating what they should have been in the first place, and then pay them again to run these (still) inefficient services. Remember outsourcers get typically paid on the work they do, so don’t expect them to remove gaps, bottlenecks and duplication – this is where they will either make their money charging you, or will take the savings themselves by fixing them. Either way you will pay much more if you had not service oriented your organisation before you outsourced.
So my advice is not to jump into such deals. Look at decomposing your organisational needs into business, IT and component service requirements that will define your contract with the outsourcer. Ensure you are clear on the necessary SLAs and ITIL processes, particularly Change Control to allow you to continue to develop your key business processes. Out-SOA-cing can work, but it requires a lot more preparation than I have currently seen. Remember, that for many organisations, or company divisions, better agility can be gained from out-tasking specific services rather than the whole of IT.
