“My SOA is Bigger than Your SOA”

Lately I’ve noticed a lot of SOA envy as organizations begin to roll out their new, and typically first, SOA projects. I hear things like: “How many services you got in your SOA?” or “We employ 10 WS-* standards, you?”

Not sure I get all that, I mean the success of any SOA is really its ability to live up to the business expectations set. Here are a few ways that others are measuring SOA, and the realities:

Services Under Management – Or, the number of services that a SOA will manage, abstract, orchestrate, and govern. While you can certainly have an impressive number of services, the size and complexity of your SOA really depends on the size and complexity of your services. Thus, the number of services really has little to do with the amount of work it took to develop or abstract those services or the value those services bring to the SOA. So, number of services at the very least, is a primitive metric.

Standards Employed – There has been so much of a push to use standards that I often hear SOAs measured in the number of standards they employ. While standards are a good thing, the use of standards really has little to do with the success of a SOA, indeed I’m finding in my practice that those who insist on using too many standards may actually scuttle their projects in an attempt to adapt to any number of standards, some not baked yet or in conflict with other standards. I don’t think this is a good metric at all.

So, what’s the best way to measure you SOA?

First, how effective is your SOA considering solving the stated business problems? Your SOA should provide agility witch means you business runs better, you make customers happier, or you enter new markets expeditiously. You should be able to demonstrate the value there easily. This is the best way to measure.

Second, how much development is avoided, or how much reuse? What is the number of services that are leveraged in more than one place within your architecture? That number should tell you how much development has been avoided. Considering development costs, you should be able to put a number on that. This is the second best way to measure.

It’s not rocket science to measure the success of your SOA. However, we seem to pull out illogical concepts when we look at the size of something. At the end of the day, SOA is not about “number of services,” or “standards employed,” it’s about being an effective business solution…albeit that’s not as much fun.