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.
Related Q&A from Todd Biske
The emergence of the stack brings up an important question: Are app servers dead? Contributor Todd Biske examines the future of the app server in a ... Continue Reading
Everyone has a different viewpoint on SOA, but three key differences between SOA and microservices architectures can help you determine which is best... Continue Reading
Why do we need mircoservices architecture? How can we benefit from it? Continue Reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.