SOA the Easy Way (If That's Possible): Page 2

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