Some Gottchas of Estimating Service Oriented Architecture Systems (SOA)
As Fredrick Brooks said “there are no silver bullets.” Unfortunately the software industry continues to tout every incremental step as that silver bullet which will solve the problems of software development. Don’t get me wrong. SOA when applied in the appropriate environment can improve productivity. Galorath analysts have been using SEER to estimate SOA systems for some years now. The basic conclusions are 1) SOA can be the best approach to achieving interoperability and reusability and 2) SEER accurately models the effort, schedule, risk, cost of software development of an SOA system as well as the cost of the IT services and infrastructure to support them. But the reality must be modeled, not just vendor claims.
Grace Lewis, Et Al. of the Software Engineering Institute did a good job of identifying some of the misconceptions of SOA as follow:
SOA Does Not Provide a Complete Architecture: SOA provides a pattern for an architecture, not the whole system architecture itself. Hence you can’t really buy SOA off the shelf. You can buy SOA products to help.
Dan Woods of Forbes points out: “The problem is that most IT departments are used to running applications. We can think of them as automakers assembling a car from many different parts. The auto manufacturer makes sure that all the parts fit together and work as they should so the car runs well. The world of SOA lifts the hood of the car and breaks the rest of the car into parts, that is, individual services that can be reassembled. “
Migrating Legacy Systems Is Nether Automatic Nor Easy… There Are Significant Costs
The Use of Standards Does Not Guarantee Interoperability In An SOA Environment
Testing SOA Systems Is Harder: “Because an SOA environment is distributed, loosely coupled, and asynchronous, testing can be significantly more complex than simply testing a set of known paths in a single system.”
Gartner also raised up the caution flag stating that SOA deployments were slowing down as people begin to understand the real costs.
Also, Forbes Dan Woods post provides a sobering observation: with SOA, IT departments end up bringing much of the work formerly handled by software vendors in house. So for estimation purposes plan on doing more IT development and services in house… And plan on training, retaining, and equipping those personnel.
Related posts
Comments
Leave a Reply
