The SOA Approach to Integration: Using Business Drivers

Let us now examine the SOA approach to integration and optimization -- from a business perspective.

One approach is to create a gatekeeper, if you will. The gatekeeper "says", in effect, "I've got a process. And I'm not going to let services into production unless they're compliant with this process ..." and, furthermore, "I'm going to have some type of process to enforce that compliance."

But there are problems with this approach. First of all, this potentially a manual and, thus, time-consuming and error-prone, process. It may not be bulletproof. There may be ways of getting around the process … So, let's dig a little further into SOA governance, reminding ourselves of some of the business drivers, like: "Why are we doing this in the first place?" Clearly, we want to align IT with the business. That's certainly one of the key drivers for SOA in general. And if we are designing our services in an appropriate way, for example, with the right granularity and the right classification, then we're going to have a much better chance of being aligned to the business. We want to obtain a positive return on investment (ROI) from our SOA. However, an ungoverned SOA can actually place limits on ROI potential.

The SOA Approach: Using Business Drivers and Objectives

Business Drivers, Goals and the SOA Approach

There are many business drivers -- regulatory, for example. These include HIPAA and Sarbanes-Oxley. Security, too, is important to everyone, along with increasing the efficiency of integration. There's a whole series of business drivers. As we move along and ask the question, "How are we going to actually govern this process?" ... there's a set of things we need to think about.

As services are being created, we want to implement policy enforcement. Particularly when these services are in operation. Perhaps we'll use a business service registry to validate compliance with various policies at design-time. During runtime, we'll start to rely on policy enforcement points. And so, perhaps we'll put an intermediary in place, which will sit between the service consumer and the service provider; the web services intermediary, in this case, can be used to enforce security, routing, mapping rules, and so forth. There are different ways to accomplish these things, but these are typical methods of enforcing policy at various stages from design-time to runtime.

For More Information

Want to know more about the SOA approach to integration and policy enforcement? Register to watch the free webinar, Optimizing the SOA Lifecycle from Design Time to Runtime with Comprehensive SOA Governance from Progress Actional.