In last couple of years, I have not only seen SOA projects overrun both budget and time but also deliver poor quality. It is no surprise that my observation around quality is inline with Gartner's prediction, according to which the unplanned downtime in SOA-based businesses would go up by 20% because of application failures.
So why are SOA projects overrunning budgets and time, while delivering poor quality? Shouldn't SOA be enabling faster-time-to-market and lower-costs, instead?
As we all know, any software development project has four basic variables: time, budget, scope, and quality. Change is the only thing that is constant in a typical SOA project, which means that the scope cannot be the culprit. Remember, the reason IT adopted SOA in the first place is to be able to respond to changing business requirements... i.e. The Business Agility!
Rest of the three basic variables (time, budget and quality) are impacted because of changing scope and project managers inability to think out-of-the-box. Let me explain by using a manufacturing plant as a analogy to a SOA development process! Interestingly, there is a striking similarity.
Manufacturing industry has come a long way. Japanese competition forced Americans to learn the advanced management techniques of how to run a production plant effectively and efficiently. One of the main reasons plants use to overrun budgets and delay shipments was their inability to understand the phenomenon of “Dependencies and Statistic fluctuations” which exists when delivery of a single product depends on several components, which are dependent on each other. Dr. Eliyahu M. Goldratt explained this theory of constraints (TOC) in his book entitled "The Goal".
The theory of constraints is the application of scientific principles and logic reasoning to guide human-based organizations.Software project managers, however, have not yet fully understood the fact that a similar phenomenon now also plays in the world of SOA based development. This is mainly because the architecture paradigm allows companies to build software, which depend on services manufactured by different organizations or even third-party suppliers and partners. One of the basic principles of TOC is Convergence. According to convergence, the more interconnected the organization is, the lower the number of constraints it will have. When we apply this to SOA, we know that the number of components and teams are growing and they are also loosely connected, which means the number of constraints are growing.
SOA architectural dependencies spill into team dependencies, which in-turn lead to redundant implementations and lack of trust. These dependencies when combined with the business agility requirements lead to constraints. Some of these constraints are mere manifestation of dependencies themselves, whereas others are a direct result of multiple teams and limited resources. Here is a quick list of some of them:
- Dependent service unavailability. This is the case when the dependent service is not implemented yet. This results in the downtime or forces downstream teams to built redundant components.
- Resource unavailability. Multiple teams going after the same set of resources.
- Time constraint. Dependent services and resources are available, but time-sliced to accommodate multiple teams
- Intermittent availability even when dependent services are available. No SLA applies in the Dev/QA environment.
- Changing behavior of the dependent service. This not only invalidates current workflows, but also makes the data brittle.
- No control on the dependent service time line
Therefore, in order to deliver SOA projects on-time and under budget, we must devise a process that will help eliminate these dependencies and constraints imposed by the side effects of loosely coupled architectures.
