Could outsourcing be a big mistake when it comes to service-oriented architecture?
Michael Poulin argues it is, particularly when you're dealing with big, overseas consultants. He says in a recent post that outsourcers are more concerned with what works for them in the short and long term than in helping you achieve a service-oriented architecture that will meets your business and architecture needs:
Apparently, such outsourcing companies try ignoring or omitting the aspects of service orientation in their implementation to minimize their hassle despite you have provided them with concrete and clear documentation on what you need and how you want it to be done (in SOA). They even ready to use (pay for) their architects to re-write your architecture and the high level design; they do anything just to simplify their work.
If you've never heard or read Poulin, he's an interesting fellow. He's an enterprise-level solution architect who works in the financial industry both in the UK, where he lives, and here in the United States. He's well-versed on SOA and contributes to OASIS SOA standards as an independent member. He is also, without a doubt, highly opinionated and unafraid of controversy. What's more, he knows his stuff : He can back up those opinions with his technical expertise that can be a bit hard to follow if you're not a techie yourself. So, be forewarned.
The ebizQ post goes into detail about why outsourcers won't necessarily keep your interests in mind when it comes to SOA. A need to control the work they do, a resistance to customized work, and knowing that service-oriented style could reduce the need for future outsourcing work are among the reasons he lists. I think you'll agree, none reflect well on outsourcers.
All is not lost, however: Poulin offers seven steps you can take to protect your SOA efforts.
This isn't the first time we've heard warnings about <strong>consultants and outsourcers failing to deliver on SOA</strong>; in some cases, outsourcing SOA has even lead to legal battles. In a way, services should be viewed as something customized to your organization and its needs. This doesn't make it easy to outsource. As Poulin writes:
As we know, SOA is not a technology; it is a methodology that requires a particular approach and operational discipline in implementation. Moreover, nobody can buy SOA; it must be build internally because it has to reflect real needs and tasks of the enterprise's business.
Of course, not everyone has a bad experience with outsourcing aspects of SOA. Today, TechTarget recently ran an interview with a consultant on the Department of Defense's SOA effort. He offers great information about using SOA to modernize legacy systems. He also discusses how his company uses SOA-based semantic services to handle unstructured data.