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.”

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?’”

Yet in the complex world of SOA, this partial plan may be best. The reason: many of those 400 pages are obsolete by the time they get implemented. “Particularly in a world where things are changing as fast as they are for SOA and Web services,” Heffner says.

“Instead, maybe you do a 30-page, or the 20-page strategy document that outlines: what are the major concepts here? What are we going to focus on now?”

“Now, we’ve got some focus, we can see: is this thing going to move us closer to that picture? But the picture remains kind of fuzzy and vague.” And that lack of clarity is okay, although that may seem counterintuitive to the well-organized platform planner.

This more flexible strategy – a street-level strategy – requires developers to tolerate architects who say, “Well, I don’t know. I don’t know what we’re going to be doing about that – but that’s okay, because today we’re not going to be doing anything about that. We’re going to be doing something about this other piece. And we do understand what we’re going to do over here.”

And what about those questions the plan doesn’t answer? How is an enterprise – which needs to budget dollars in advance – suppose to come to terms with street-level strategy?

With the following attitude, notes Heffner: “We’ll figure out that answer when we get there. And the industry will have changed, Web services specs will have changed, the product offer will have changed.” When it comes to SOA, staying loose has its benefits.

“And since we’re not ready to buy one today, let’s let all that develop, then we’ll dive into more detail and figure it out.” A better, more all-encompassing decision can be made downstream, when there will be better information at hand.

Project Level vs. Enterprise Level SOA

Given Heffner’s predilection for a specific, “pain point focused” approach, does he favor focusing on project-level SOA implementation over enterprise level?

“Actually, let’s present the question this way,” he says. “Should we do a project-level architecture, or an enterprise level architecture? And the answer is: yes.”

Humor aside, the point is that instead of choosing between long- and short-term vision, it’s best to combine short and long term vision.

“What I’m saying is, the 30-page architecture strategy for SOA serves as the enterprise architecture.” This fairly brief document can lay out the overarching plan. “And the project architecture” – each individual instance of it – “should be fully consistent with that.”

“And in the best case, it’s going to be developed with the cooperation of the enterprise architects, so that we get the best ideas from the “what do we need right now’ perspective, and also from the ‘how’s it going to feed the long term’ perspective.”

The ideal strategy is to extract the details learned from this one project, and use this knowledge to expand the larger enterprise plan. Now, instead of the preliminary 30-page SOA plan, “maybe we’ve got the 50-page strategy, because we’ve developed 20 pages of understanding it more on this first project.”

Not that any of this is simple, Heffner concedes.

“Of course it gets complicated because we’re not doing just one project at a time. So it gets to be a matter of understanding and developing and maturing your governance processes, and version control, and better platform management – but these are all good disciplines that we should be developing anyway.”