Do service oriented architecture (SOA) projects consist of too much guesswork that misses a lot of the intricacies and quirks that define enterprise processes?
At his LessAccounting blogsite, Steven Bristol reflects on the challenges of service-orienting complex systems, noting that many such efforts in recent years have made very complex systems even more complex. His reasoning:
"The reason SOA goes badly so often is the same reason that architecting a large project, and implementing the architecture without real world goes bad so often, and is the same reason that estimating projects so often leads to missed deadlines and budgets: while it’s relatively easy to see the forest through the trees, it’s almost impossible to see the forest, the trees, the leaves, the dirt, the twigs, the mountain side, and the people that will be driving or hiking through forest all at the same time. Seeing that level of detail, breadth, and depth requires the same clarity, insight, and wisdom that’s required to properly architect SOA or correctly estimate a project."
Agreed, it's very difficult to design services that anticipate who will ultimately be using them and how they will be used -- especially in large organizations that may look entirely different a year from now with different lines of reporting and new lines of business (and perhaps a merger or two thrown in).
The ultimately successful service oriented architecture is not designed with rigid constructs, susceptible to miscalculations at the beginning of projects, or to changes in underlying technologies as time goes on. Rather, SOA is built to allow for maximum flexibility and change. That's what the "A" in SOA is all about -- it's an architectural approach that accounts for the inevitability that projects and technologies will inevitably shift course.