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

SOA: Responsibilities of Service Providers (Part 8)

Responsibility 7:  Provide business eventing, where applicable (e.g. asynchronously via JMS).

This blog post is one in a series.  An overview and general outline of this series is linked here.

Background

In a nutshell, according to Wikipedia, an Event Driven Architecture (EDA) is one that promotes the publication, consumption of, and subsequent reaction to events.  Publishing applications are independent and decoupled from one to many consumer applications.  And consumption is usually performed asynchronously after the producer's unit of work is complete.  Java Message Service (JMS) is a common asynchronous messaging specification.  An emerging asynchronous messaging specification is AMQP.  While it is possible to implement synchronous event processing, tread carefully.

EDA is complementary to the objectives of SOA but this is sometimes misunderstood.  The complementary relationship might be best described with an example:

• An AccountService is invoked to Open an Account.
• Once all the required attributes are validated, the account is created.  The customer proceeds to use the account to transact business.
• As part of creating and committing the Service's unit of work, a "business event" is published to JMS.  The event contains the channel (e.g. 800 number, sales person, or website) used to open the account and other basic meta data about the account that was opened.
• Asynchronously and in parallel, one or more separate consumer applications receive the business event as a notification that an account was opened.

Let's continue the example and assume two applications receive the event that was published and process the event independently and in parallel.

Application #1 receives the event and sends a "thank you" email or letter via Postal Mail, depending on the customer's contact preferences.  This correspondence may include invoice and payment terms, return policies, etc. that are specific to the account.

In parallel, Application #2, a SalesForce Automation (SFA) application, receives the event. If the account meets certain criteria (e.g. it is for a corporation) the sales person assigned to the customer's city, state, region, etc. is notified.  The SFA application might analyze/classify the account and make key details readily accessible to the sales person--examples include:

1. This is an account for a customer that has never transacted business before, or this is a second account for a customer that has not transacted business since X date.
2. The customer's business is in industry Y per SIC code 1234.

The SFA application might even alert the sales person's Blackberry if the account meets criteria specified in his/her alert preferences within the SFA app.  If so, this could be done automatically in a matter of seconds or minutes after the account was opened.

An event driven approach is more effective than the SFA application waking up on a timed interval to poll the customer service database for new accounts.  Or the customer service database creating a daily extract of new accounts to send to the SFA application.

A few benefits of asynchronous messaging include:

1. An Event driven architecture provides the ability to react to business events as they occur.
2. Consumers are decoupled from producers.  Events will simply queue up for one specific consumer application if a planned or unplanned outage is experienced.  When the application becomes available again all messages queued during the outage will be processed.
3. An application may process messages off the queue in parallel.  This is achieved by creating multi-threaded consumers that connect to the queue.  This is a simple means to achieve increased throughput.

Considerations

Typically, business services parallel a durable business process it supports. As part of analysis, it is useful to identify the actors that initiate or interact with the business process and also the events (outcomes) that result. Events are often described as a noun plus a verb (or vice versa if you prefer). It is useful to identify and catalog these events as part of business process analysis, capability mapping, etc. Examples of business events:

• Account Opened
• Customer Order Placed
• Customer Order Shipped
• Inventory Replenished

When required, the service provider carries the responsibility to successfully publish the appropriate business events to the messaging infrastructure.  The general objectives and challenges are very similar to SOA.  There should be a common approach/strategy to do this.  For event/messaging to be effective as an enterprise resource, publishing business events that are of high-value across the enterprise requires planning and coordination across the organization.

While we've only covered some basics, an effective approach for business eventing is required to spring board into other areas such as event correlation, complex event processing, etc.  In using a football analogy, it is important to get blocking and tacking right before focusing too much on the other complexities of the game.