The follow question was recently passed along to me by a peer:

"…There seems to be anecdotal evidence that moving a system to SOA, or creating a new system using that architecture is the right way to go but she was looking for something with numbers of metrics that she could use for her boss…"

This is a really important question because I believe that the person seeking this information is not alone in attempting to identify real value of investing in Service Oriented Architecture (SOA). The problem is that a properly done SOA should be unique to the mission, goals and processes of the organization making it of limited relative use to another organization. That is, SOA offers a framework for identifying, isolating, delivering and servicing a consumer need, and, while all businesses have some common aspects, the resulting business services should be unique to the needs of that business' consumers.

So, what then is the real value proposition for SOA? The answer to this question is the age-old consulting answer, "it depends!"

For one thing, SOA is so poorly-defined that just about any IT project can be labeled SOA, which means that anything you want to place an SOA label on that enhances productivity, reduces costs, increases profitability or otherwise has delivered value to your business. One of the yardsticks I use to measure an SOA by is that the effort has produced "product"—by product I mean a tangible and achievable asset has been defined—that consolidates execution of a business function within the business in one of two ways; a) a consistent process that may be replicated but is executed identically, or b) the function is executed by a single unit within the business. Note, in some discussion of SOA you may see this represented as a requirement for reuse, but reuse is not our goal as reuse implies a choice to use or not use. We are seeking consistency and, what I call the need to have something built once-and-only-once, ergo, no choice; the service must be designed in a way to support its consumer audience completely.

In (a) above, it's important to remain flexible in design. Some businesses are designed around their customer need, which means that a business function may need to be replicated due to privacy or confidentiality concerns. However, that does not mean that, where replicated, the function should not follow a consistent approach. The benefits and value of this to the business are significant. It allows employees to more easily be moved around, it reduces the costs associated with downstream processing and it simplifies the operations of the business for planning purposes. With regard to (b) above, that's fairly self-explanatory. By consolidating multiple, different approaches to delivering the same business function within the organization, e.g. receivables handling, it will result in lower expenses and overhead.

I believe the key take away from this blog entry is that you can explore how others have succeeded in applying the steps I have outlined above, but you will need to seriously consider what it will take for your organization to leverage SOA design concepts to deliver value to your business. Moreover, the first decision you need to make is what improvements or value propositions matter most to your business, and NOT what SOA metrics exist to justify moving in that direction. Or, to rephrase that famous Kennedy quote, "ask not what SOA can do for you, but ask what you can do to improve your business!"

Read the original blog entry...