SOA the Easy Way (If That's Possible)

That is undoubtedly true, as plenty of companies have learned. Attempting to implement a ‘grand vision’ for SOA can be unwieldy enough to swamp the enterprise in myriad complexities.

For many companies, the question becomes: how can we realize the promise of SOA without developing and following an exhaustive 400-page platform plan?

In the word, Heffner says, the concept to keep in the forefront is “evolutionary.”

The entire infrastructure doesn’t need to be ripped out and rebuilt. Instead, it’s helpful to focus on a specific problem, then find a specific SOA implementation that fixes that problem.

To be sure, it’s helpful to dive into the deep dark waters of SOA theory. But as big as SOA can potentially be, you don’t have to plan every step of your SOA makeover before you take the first step.

“So you’ve got to stop that cycle – ‘we’re going to get everything ready to do SOA’ – and instead focus more on: ‘what’s the next solution we need to build, and how does SOA apply to that solution?’” Heffner says.

“Using that solution as your first step” – he hesitates to use the term ‘guinea pig’ – “then say, how can we make this project better, and [use it] to move us toward the longer-term, big picture that’s the grand, theoretical pretty picture of everything you might want to do with SOA?’”

Along with keeping your approach evolutionary as opposed to revolutionary, Heffner recommends two key tenets in developing your SOA infrastructure:

1) Let the pain drive SOA investments. Service Oriented Architecture is a means to an end, Heffner notes – it’s not an end in itself. Focusing on the “pain point” – the very real problem that needs to be fixed – helps engender a productive conversation within the business that’s less likely to get bogged down in theory.

2) Use street-level strategy to tie near-term implementation to long-term vision. Notes Heffner in his report: “Rather than trying to decide upfront on a myriad of SOA strategy issues (e.g. repository strategy, enterprise service bus (ESB), SOA management), create a lightweight strategy that outlines and structures the range of SOA issues without deciding on specific answers to any of them.” In other words, a “street-level” strategy is one that stays loose – it has a direction but it’s not tied down. It’s ruled by pragmatic concerns that can change over time.

Platform Architects vs. Application Developers

Platform architects tend to be big thinkers. But they may need to curb this instinct when approaching SOA.

“The thing is, architects are theoretical and they want to dot every ‘i’ and cross every ‘t’ before they go talk to a developers about something,” Heffner says. “So they might do the 300- or 400-page strategy document – and believe me, there’s plenty of stuff to go into in writing up a SOA strategy.”

In most cases, there’s good reason to go into this much detail – or at least there was pre-SOA. ”If they go to application developers with a partially drawn conceptual architecture, the application developers look at them and say, ‘What? What do you mean by that?’”