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