This article is part of an Essential Guide, our editor-selected collection of our best articles, videos and other content on this topic. Explore more in this guide:
2. - Top trends to watch for in BPM and BPEL: Read more in this section
- The state of BPEL in 2013
- The case for cloud-based DCM
- Most important customizations for SOA governance
Explore other sections in this guide:
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.
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.