Have you assessed your investment in SOA lately?

Is your SOA project running over budget? If so, is it because you have overstaffed to meet your deadline? Or have you just made poor budgeting decisions? Or, is it both? Are you delivering quality and speed? 

Over the past few years, I’ve seen SOA projects run over budget and over deadline and still deliver poor quality. I don’t find my observations surprising. In fact, they are right in line with Gartner’s prediction two years ago that unplanned downtime in SOA-based business applications would increase by 20 percent because of application failures.

Shouldn’t SOA be enabling faster time-to-market and lower costs instead?

As we all know, software development projects have four basic variables:

  • Scope
  • Time
  • Budget
  • Quality

Change is the only 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 was so that we could rapidly respond to changing business requirements, i.e., The Business Agility!
The three other basic variables are impacted because of changing scope and the project manager’s inability to think out-of-the-box. Yes, I said it.

Let me explain by using a manufacturing plant as an analogy to the SOA development process. Interestingly, there is a striking similarity.

The manufacturing industry has come a long way. Japanese competition forced the rest of the world to learn and adopt advanced management techniques that would allow them to operate a production plant effectively and efficiently. One of the main reasons manufacturing plants had budget overruns and delayed production schedules was their inability to understand the phenomenon of “Dependencies and Statistic Fluctuations,” which occurs when the delivery of a single product depends on several components, each dependent on the other.

Dr. Eliyahu M. Goldratt explained the Theory of Constraints (TOC) in his book, “The Goal.”

“The theory of constraints is the application of scientific principles and logic reasoning to guide human-based organizations.”

Unfortunately, software project managers do not yet fully understand that a similar phenomenon is now at play in the world of loosely coupled architectures. Their inability to see the full picture is the product of an architecture paradigm that allows companies to build software that depends on services manufactured by multiple organizations and third-party suppliers and partners.

One of the basic principles of TOC is Convergence, which states that the more interconnected the organization is, the lower the number of constraints it will have. When we apply this to SOA, the reverse is true. We know that the number of components and teams is growing, and that they are also loosely connected, which means the number of constraints is growing.
SOA architectural dependencies spill into team dependencies, which in turn lead to redundant implementations and lack of trust. These dependencies, when combined with business agility requirements, lead to constraints. Some of these constraints are mere manifestations 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 yet implemented. It results in downtime or forces downstream teams to build 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, it also makes the data brittle.
  • No Control on the dependent service time line.

Taking a closer look, we see that these dependencies and constraints work against the overarching business goal: To be agile.
In order to deliver SOA projects on-time and under budget, we must devise a process that will eliminate the dependencies and constraints imposed by the side effects of loosely coupled architectures. And that something is Service Virtualization.