This content is part of the Essential Guide: SOA BPM guide: Mobile, cloud drive BPM, BPEL changes
Problem solve Get help with specific problems with your technologies, process and projects.

SOA governance: What customizations are important

It's important not to let solid governance practices be limited to SOA, because deficiencies in other areas impact efforts.

What customizations are important for SOA governance and why? (BAM? BI? CEP? Others?)

At first glance, customizations and governance would seem to be counter-intuitive. After all, isn't governance about enforcing policies and keeping things as black and white as possible? Let's first put the term "customization" into context.

Todd BiskeTodd Biske

Customization of policies usually only occurs in one situation, and that is in service contracts. A contract is a set of policies specific to one consumer and provider. While there may be policies in common between one contract and another, each contract can be unique to the consumer and provider involved.

Let's put this customization into a different context. The question asks about BAM, BI and CEP. We're not talking about customization of SOA governance anymore; we're talking about expanding the scope of governance efforts beyond SOA. This is actually a perfectly normal occurrence for companies that don't have a strong architectural governance practice.

Design-time governance practices for services are often focused on the service interface. Sometimes those interface decisions are based on elements behind that interface, such as underlying database structures. Is that a SOA governance concern? Well, if it results in a poor service interface, it is. Even from the run-time perspective, there are parallels.

A run-time concern for SOA is ensuring that one consumer's requests don't starve out requests from other consumers. Conceptually, this is very similar to concerns in the BI world of ensuring that the analytical analysis and report generation for one customer doesn't impact the performance for others.

Don't let solid governance practices be limited to SOA.

In the CEP space, we also have parallels. In the SOA space, we need to have a catalog to raise visibility of services that already exist so other projects don't rebuild them. The same thing holds true with events. We don't want multiple business processes all generating their own version of what should be the same event. Cataloging your events, just as you would your services, will provide visibility that will hopefully keep redundancy out of your enterprise.

Regarding BAM, this is about metric collection. Clearly, metric collection is a critical component of run-time governance. If you have policies based on those metrics, you must be collecting them to enforce those policies, whether enforced passively (e.g. an uptime guarantee per month) or actively (e.g. an allowed request rate).

Run-time SOA policies are just a subset of the overall run-time management of all your systems. If you have poor run-time management practices in place today, an attempt to implement run-time SOA governance will probably expose those weaknesses, but also provide an opportunity to impact much more than just SOA.

The message to be taken from this is as follows: Don't let solid governance practices be limited to SOA. If you don't address governance weaknesses in other areas, those deficiencies will wind up impacting your SOA governance efforts, thus putting a ceiling on potential benefits. Instead, use successful SOA governance efforts as a stepping stone to improving governance, whether design time or run time, in other areas.

Follow us on Twitter at @SearchSOA and like us on Facebook!

Dig Deeper on Application performance management and testing

Join the conversation

1 comment

Send me notifications when other members comment.

Please create a username to comment.

Certainly one of the ways of introducing local, customizable variations ... especially those likely to change over time ... is to use BPM to implement the control of processes and BRM to provide decision rules. Not only does this keep one from dipping constantly back into the code ... a governance nightmare ... but the cost to modify drops precipitously and the confidence of the stability and correctness of the solution skyrockets.