SOA "G-Bombs" (Part 3 of 3)

This concludes a three part series on SOA governance--here's a link to the initial blog post titled "SOA 'G-Bombs' ".

Thinking of Services as a "Center of Excellence and Expertise (CoE)"

In reading Beth Andres-Beck's blog post the other day, I was reminded the W3C notes the purpose of a service is to "provide some functionality on behalf of its owner -- a person or organization."  This is a nice parallel to considering a service as a "center of expertise" for functionality it exposes.

In continuing the prior post in this series, when "Feature "X" (as shown in the diagram) is rationalized across Apps A, B, C the corresponding functionality is moved to a shared service.  By way of example, if "Feature X" is currency conversion, there are a few implications of moving this to a service:

1. Apps A, B, C will use the same logic and mechanism for performing currency conversion
2. I.T. and Business stakeholders for Apps A, B, C will no longer need to be experts in Currency Conversion.  Implies human expertise for this function could be realigned.
3. I.T. and Business stakeholders for Apps A, B, C will need to be consulted if there are changes to the Service, particularly ones that are impacting.
4. "Silos" are minimized or eliminated.
5. I.T. and Business stakeholders must align on priorities.  At times, the service owner might not be able to enhance the service for multiple applications and multiple stakeholders at the same time.

A common question: "Who should own the Currency Conversion Service?"

Step back and think about what a common, shared service really represents.  A service represents "expertise"--both business expertise and I.T. expertise--provided for others to leverage.

When a piece of functionality once replicated across the organization is moved to a shared service, ownership questions naturally abound.  In a silo'd organization in particular "who should own shared services?" can become an ever present question.

One approach could be to move these shared services to a single support organization.  This can be an issue due to sheer scale.  It is not necessary or required to move all services to a single support organization (it is quite important for responsibilities of a service owner to be clear as this is critical to success).

If functionality is duplicated across the organization this implies human expertise is duplicated as well.  When applications are reoriented to use a shared service to minimize duplication it is possible the organization should consider reorganizing in some manner.  The purpose of this would be to maximize benefits of the service--business and I.T. experts supporting the service and the entire organization effectively.

It is not always practical to shift functionality to a shared service with no regard to the associated human expertise.  In order to maximize benefits it is necessary to ensure I.T. and Business experts have ownership and provide necessary support.

Rather than ask "Who should own the Currency Conversion Service?", ask a slightly better question: "Where is the expertise for Currency Conversion?".  From this hopefully ownership can be identified more effectively.

Why Focus On Expertise?

As a logical construct, a business service embodies the associated business and I.T. expertise.  And exposes functionality to share across apps and business teams.  A business service without its backing expertise does not maximize benefits.

Bottom Line:  If the company's experts are organized "behind" the service, why use anything else (such as building your own duplicate functionality) to deliver a solution?  If you find yourself in a debate over ownership or adoption, step back and see if there is a bigger picture.

SOA "G-Bombs" (Part 2 of 3)

This is a continuation of thoughts on SOA governance from a prior blog post titled "SOA 'G-Bombs' ".

I was inspired to jump back into this series after reading Beth Andres-Beck's blog post today.  Thanks :-)

The "Silo Effect" Revisited

I had planned to dive into some additional thoughts to parallel Services and Centers of Excellence as it relates to SOA governance.  But I thought it would be useful to drill down a bit more on the "Silo Effect" first.

To maximize benefits of SOA at enterprise-scale, it is important to consider how an existing organizational makeup (silos) can positively or negatively affect, impact, or support the defined objectives of the SOA program.  Ineffectiveness will challenge an organization's ability to maximize benefits through SOA.

Let's not immediately jump to the topic of "reorgs" to reorient silos.  Let's think about this SOA governance topic from a slightly different angle.  And if this leads to thoughts of reorgs, alignment, or improved coordination across organizational units, then for our purposes here that's simply a result of a bigger idea and mission.

And another reason to not immediately jump to a topic of "reorgs" in this blog or in your mind right now...I'm simply a technical guy. :-)

Figure 1: "Silo Effect" across Business & IT (click to enlarge)

Maximizing reuse and reducing duplication are among the general objectives of a SOA program.  Typically this is viewed from a software functionality point of view.  As illustrated in Figure 1, "Feature X", might represent currency conversion and collectively involve duplicate vendors (to source the conversion rates).

Not only is there duplication in terms of software and vendor-enabled capability, but there is duplication of human resources--or more specifically expertise  related to "Feature X".  Ahh, an organizational question.  Jump back.

The third and final contribution to this series will consider each shared, common service as a "Center of Excellence" for functionality.  Or given the elaboration here, maybe it's more appropriately considered a "Center of Expertise".