Measuring the agility of a SOA approach

  • Article

I'm thinking about the business case for integration again... (still).  We talk about SOA providing a benefit by being more agile.  In other words, if you have a SOA infrastructure, you can change to meet the needs of the business in an agile way.

Here's how to prove it.

  • Step 1: create a metric
  • Step 2: use the metric against two projects, one with SOA and one without.
  • Step 3: present differences.

Step 1: create a metric

You need to create a metric for the "IT Agility" recognized in the architecture.  This will provide you with a baseline to compare radically different projects on different architecture.

IT Agility metrics are unusual.  In my view, this metric would relate the speed by which a change occurs with the complexity of a change. 

Literally: Agility = Change Complexity / Change Duration.

With a metric of this kind, you can compare the agility of two approaches: say non-SOA distributed systems vs. SOA distributed systems. 

Measuring the speed of a change is not too difficult.  Time of request to time of delivery.  The other half is a bit harder.  Measuring the "complexity of change" is an interesting problem, but not intractable.  Certainly, there is cyclomatic complexity, but I don't think that says anything about the architecture.  It is too algorithmic and quite dependent on the language.

Change Complexity = (architectural depth factor) * (process breadth factor)

Think of this like the area of a rectangle: "depth in the architecture" times "breadth in the process" equals "area of the change." 

Architectural depth is the number of LOGICAL layers of your system that are impacted by the change.  Logical layers could be a simple list.  I like this list: user experience, business process, business rules, information storage, information integration, but you could use your own list, as long as you are consistent.

Process breadth is tricky, since processes include processes.  I'd say that the breadth of a process is a sum of the number of distinct roles involved in the process, and the number of hand-offs of responsibility from one role to the other. 

Process breath = (number of roles) + (number of handoffs between roles)

Now, with a metric of this kind, you need to use it to measure something... that the next section.

Step 2: Use the metric against two projects

Find two projects in IT where you can get your hands on the project requirements and timelines, for each update.  Project 1 has to be a non-SOA project, while project 2 has to be a project that was SOA from the start. 

If you cannot do this, then you need to create a SOA Proof-Of-Concept project.  I'm assuming that you have some SOA systems in place already, but that you need to show value for the approach.

If you have no SOA Proof-of-concepts (POC) yet, stop here.  I cannot help you.  Go get a POC going.

Assuming you have a SOA POC, and assuming you can get the numbers for another system across it's lifespan...

For each type of app, answer these questions

  • How often in the past 5 years has this business application needed an update?  (frequency of change)
  • How long did each update take? (duration of change)
  • How complex was the change? (see above section)
  • Are there other applications that do the same thing in your company?  (If so, include them in a generic category, like "Order Management") 

Step 3: present differences

Now you should be able to make a value-add comparison for the SOA vs. Non SOA projects and, assuming folks like me are right (no promises), you should be able to show that SOA projects are more agile.  That presentation needs to look good, and have the right information in it.  Don't assume everyone will know what to do with your recommendation.

Special considerations for rip-and-replace projects

Note: if the project you picked is part a "rip and replace" space, you need to do a bit more work. 

A "rip and replace" space is any generic category of software (or solution domain) where the business invested, for the past few years, to remove an existing system and replace it with a new one.  Note that a R&R project doesn't need to be successful to be part of the problem, but clearly failures are easier to ignore when calculating the agility of the solution.

For the sake of this comparison, avoid any projects in your comparison that have significant rip and replace projects against them.