If SOA is back, as many have been arguing in recent months, then it’s different now – it comes with more flexibility and choice than before and it’s not just the preserve of the big corporate; this time around it’s not one size fits all, but it’s for everyone.

Let’s take a concrete, real-world example, which we come across all the time. If you’re working in a small IT department that finds it has to integrate its back-end systems to Salesforce.com., what are your options to put that integration in place in a standard-based, service-oriented way?

First, there’s the question of what you use to build the integration. Most people in order to implement SOA have some form of ESB from one of the big vendors at a cost of hundreds of thousands of dollars. They might only be connecting to Salesforce.com to their SAP back-end, a simple problem that they don’t really need a whole ESB to solve, but that’s what they end up with.

The alternative is to have the developers write a point-to-point integration, but that’s what we are trying to get away from in building a service-oriented architecture in the first place.

But rather than implementing a full ESB SOA, something that is clearly a sledgehammer to crack a nut, why not contain that within an adapter? Or, to pick up on an analogy I have used many times, why not piece together your SOA out of the specific building blocks that you need, at a particular time, and in the way you want them delivered?

If you’re building a simple Salesforce integration, you can pick up the blocks that work with your back-end system such as SAP, and those that work with Salesforce and plug them together to make a connection. You still have all the benefits of SOA – the reuse, the service orientation and the open standards – but without the cost and hassle traditionally associated with architecting and maintaining an SOA.

Second, alongside what you run, there’s the question of where you run it. If you don’t want a big monolithic system running on-premise, there’s the further option that you can federate it out to the edge of the network and run it in the cloud.

Then it becomes a question of building that cloud-to-cloud integration in a way that doesn’t leave you open to changes in the cloud vendor’s service and how that is exposed.

Cloud vendors, such as Saleforce.com, are all pushing their own APIs and in recent years have been continually updating their API, in contrast to the more traditional vendors like SAP whose interfaces are more static. Changes in APIs are coming thick and fast, almost too much to keep up with, and they’re also exposing their applications in different ways with different types of APIs for different purposes.

For the business manager that just wants to get at a specific piece of information in a database or expose a particular piece of functionality, this rapidly changing landscape of APIs can seem quite daunting. Speak to IT and you will find a developer eager, as developers are, to write a piece of code that does exactly that piece of integration – but it does only that, and may not be adequately supported as the developer moves on to the next project.

What the business is looking for is a packaged solution that’s supported no matter what changes occur at either end. This is where the adapter framework hosted within the cloud comes in – it just works and continues to be supported, and the organisation’s IT department is shielded from the complexity and the shifting sands of API management.

Finally, just as the model of what you use and where it sits is changing, so is the model of how you acquire the service – and again this is now designed to provide more choice to the customer.

It’s similar to how you buy a mobile phone. You might want a pay as you go service, where you just pay for what you use, or you might want to go on a contract, which specifies how many minutes, how many text messages and much data you have, then if you want extra minutes, text or data you can buy it.

Similarly with the integration frameworks, you can buy the pieces you need right now and buy more as you go along, or you can sign up to a subscription model and build it out as you need it.

This really plays to the realities of customer choice: some people want to buy the least expensive integration available that does the job; others want to buy the most high performing integration engine. It’s not just about providing a cheaper alternative to building the entire SOA stack, this is about providing more flexible ways of building it so you can modify, add and scale depending on what the budget allows or the business demands.