When SOA becomes SOS

by Conor Toal

The early promise of service-oriented architectures (SOAs) was that the creation of a flexible and interoperable process layer would make it much easier for companies to meet ever-changing operational requirements. Broadly speaking, by enabling businesses to create, adapt and orchestrate new processes without making expensive changes to back-end systems, it promised a panacea for seamless process integration.

In practice, however, many organisations have seen this technology fall short of delivering on its promises. Technical challenges have occasionally been to blame; but in most cases, the fault lies with a failure to balance architectural considerations with business needs.

There’s been a tendency for IT teams to focus too narrowly on designing a ‘perfect’ architecture, walling themselves up in an ivory tower that doesn’t offer any immediate, tangible value to the business. By the time their new architecture is ready for deployment, the business – faced with an urgent need to deal with real-world challenges – has often already implemented a tactical solution that doesn’t match up to the technical standards. Not to mention the difficulty, once this has happened, of encouraging the business to adhere to corporate standards in the future.

But infrastructure and energy companies – perhaps more than most – must manage innumerable drivers which demand flexibility from in-house and legacy systems. The continual drive for improved customer service, new regulatory and compliance requirements, the needs of contractors and other stakeholders, can create huge headaches for those tasked with delivering these complex solutions.

Perhaps as a result of this disconnect between IT idealism and business pragmatism, what once seemed like a silver bullet is now viewed with deep suspicion. The true cost of poorly thought out projects, which in many cases fail to deliver, or end up costing the earth to support, has left many disenchanted.

Our experience working with clients suggests, however, that the truth comes down somewhere between the original over-optimism and the later cynicism – these projects can provide immense value if a couple of key principles are observed:

1) Engage the business early and often
SOA isn’t a technology initiative – it’s a business enablement initiative. Service orientation needs to be a means to an end, not the end in itself. You need to get the business involved at the start of the process, and make sure you’re very clear about the deliverables, budgets and time-scales required. Strong business engagement will encourage a holistic design which strikes the right balance between automation, integration and human input. This will help to ensure that the new architecture delivers real value as early as possible, and reduces the risk of the business abandoning technology strategy in favour of short-term tactical solutions.

2) Choose a technical partner that understands your industry
Choose your implementation partner based on more than just technical criteria. A vendor may be able to point to lots of experience on similar projects, but do they have a successful track record in the essential industries? Do they really understand the systems, data structures and business processes required to enable world-class asset management or customer service? Will they be able to bridge the gap between business processes and information and the underlying data?

SOA can no longer be seen as a magic wand that can transform inflexible legacy systems at the flick of a wrist. Nevertheless, with the right partner, the right approach and the right investment, it can help solve your immediate business challenges while creating a more supple, adaptable and sustainable framework for future needs.

Contact the author