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