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, weve 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.
The Golden Rule Of Business Technology Investments
How To Avoid An IT Project 'Death March'
IT In 2007: Budget and Trends
Virtualization: Xen vs. Microsoft vs. VMware|
This more flexible strategy a street-level strategy requires developers to tolerate architects who say, Well, I dont know. I dont know what were going to be doing about that but thats okay, because today were not going to be doing anything about that. Were going to be doing something about this other piece. And we do understand what were going to do over here.
And what about those questions the plan doesnt 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: Well 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 were not ready to buy one today, lets let all that develop, then well 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 Heffners predilection for a specific, pain point focused approach, does he favor focusing on project-level SOA implementation over enterprise level?
Actually, lets 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, its best to combine short and long term vision.
What Im 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, its 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 hows 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 weve got the 50-page strategy, because weve 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 were 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.