SOA projects can quickly get swamped in a sea of complexity, but there are ways to avoid confusion and needless cost overruns, argues a SOA expert.
In a research report about getting started with Service Oriented Architecture, Forrester analyst Randy Heffner warned that SOA strategy carries heavy risks of being overly theoretical and academic.
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 doesnt need to be ripped out and rebuilt. Instead, its helpful to focus on a specific problem, then find a specific SOA implementation that fixes that problem.
To be sure, its helpful to dive into the deep dark waters of SOA theory. But as big as SOA can potentially be, you dont have to plan every step of your SOA makeover before you take the first step.
So youve got to stop that cycle were going to get everything ready to do SOA and instead focus more on: whats 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 thats 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 its 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 thats 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 its not tied down. Its 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, theres plenty of stuff to go into in writing up a SOA strategy.
In most cases, theres 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, 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.
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.