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".

SOA "G Bombs"

What in the world is a "G Bomb"?

I've added this term to my vernacular in recent months.  And I use it from time to time to describe occasions when the term "governance" is tossed around, sometimes out of nowhere and especially in an unqualified manner:

• "We need 'governance'."
• "We can't do 'X' without 'governance'."
• "Who has 'governance' decision rights (to mediate competing requirements, resources, and priorities)?"
• "Who governs adoption of services?"
• "How do we govern technical implementation?"

These statements can change the dynamics of a conversation or meeting.  "G-Bomb" has proven to be a catchy way to describe these type events or at least it brings about a bit of humor; so-much-so a pair of consultants recently asked to borrow the term.  :-)

Organizational alignment makes governance tricky

Governance of a service-oriented architecture is tricky, especially at large scale.  In my view, at its core this is accentuated by many "silos" typically found across I.T. and business areas in large companies.  Acquisition and merger activity can not only accentuate this but also lead to different types of silos.

In basic form, a silo can be viewed as an application development group tightly aligned to a business unit.  This can be a valid operating model.  But it also has the potential to pull against the goals of a service-oriented architecture.

When a "silo effect" (click for article) is overbearing, over a period of time a multitude of duplicate feature/function across application areas can result--supported by multiple I.T. organizations and used by each corresponding business unit.  Examples include customer contact management, multiple address validation, address geocoding, credit card validation, or currency conversion mechanisms.

Why is duplication problematic?

Typically in a SOA, it is important to consider the functional needs of the enterprise as a whole as a means to maximize reuse.  This is elaborated in a past blog post (click for article).

Ineffectiveness in this regard promotes duplication, which can:

• Yield complexity:  changes must be made in multiple places, sometimes in coordinated fashion
• Increase costs:  hardware, license, labor, and maintenance costs.
• Impact speed to market:  cost of lost opportunities
• Compromise customer experience:  customer encounters inconsistency when interacting across lines of business, touchpoints, etc.

Duplication is counter to SOA.  In my view, one of the key aspects of a SOA is to promote a more cost effective and agile operating model.  And one measure of achieving this goal is by maximizing the amount of reuse per service and in doing so reduce/eliminate duplication.

Thoughts on approaching Governance

In a large organization, working a complex task often requires identifying a communication vehicle to get everyone on the same page and pulling in a common direction.  This seems to hold true in fostering an enterprise SOA program.

In terms of identifying services that need to be built, adopted, and managed (governed), to maximize benefits it helps if the enterprise is on the same page.

I've given some thought to considering enterprise services as a "Center of Excellence" (CoE) for functionality.  It is helpful context to identify a general purpose definition of a CoE.  I ran across this definition in Jon Strickler's Agile Elements Blog (click for article):

Center of Excellence:  A team of people that promote collaboration and using best practices around a specific focus area to drive business results.

In this stream of thought, I am not thinking "SOA Center of Excellence".  This  is something quite different.

But rather each Service in a service-oriented architecture is a Center of Excellence for the functionality it provides.  I'll "brain dump" additional thoughts of drawing parallels between Services and Centers of Excellence as it relates to governance in a subsequent post.

• Part 2 of 3
• Part 3 of 3