The Need for SOA Runtime Management

Wouldn't it be great if, in addition to design-time, development-time and deployment-time management of Web services, there was a way to automatically see what actually happens during production execution -- in a live IT environment -- and then actively steer system behavior toward the right outcome? That's what SOA runtime management is all about.

SOA Runtime Challenge: Incomplete Governance

One of the big challenges that we've seen organizations face is electing to start with just one of these forms of governance. For example, deployment-time governance; an organization may deploy a registry and follow deployment-time governance practices and the challenge they'll face is they might actually have application developers fully develop services, get all the way to being production ready -- only to discover that they have services that are actually not compliant with stated policies and/or regulations.

SOA Management Face-Off: Business vs. IT

In this event, the organization is faced with a major problem: they have invested the effort (and expense) of developing a set of services, and they're ready to deploy them -- yet they realize that to do so would break some of their critical compliance policies. On the one hand an enterprise architect is telling the development team that they're not compliant -- that deploying the services would put the firm at risk -- but at the same time, business stakeholders are saying "Listen, we're losing $50 million every day that this service isn't deployed." ...So, which stakeholders will win out in the end? The answer is not clear; it will vary from company to company. But rest assured, IT departments and business stakeholders are wrestling with these issues on a daily basis.

Challenge: SOA Management Standards

There are a number of challenges that arise when automating governance; these can include development tools, for example. There may also be "standards" that companies set for developing their services: these could be products from Eclipse or Rational -- but not all the developers are going to use these standards because, quite often, the "standards" are just guidelines -- and even if developers do use some of these tools, they may not follow the same deployment processes -- so things can easily slip through the cracks even with the best of intentions. Even when some rules have been put into place, people will tend to do things that they may simply be more comfortable with, use tools that they are more comfortable with -- and often enough these tools and practices will add up to the "internal policy".

SOA Policies in Runtime Must Be Fluid

Policies can also change. Policies can change when services are in production. Does this mean you need to roll out a new version of your application each time there is a policy change?

Or are there policies that don't necessarily apply to the services themselves -- and instead apply to some broader notion? For example, consider an auditing service that gets rolled out into production that follows all the governance and compliance measures and it's used in a variety of different ways throughout the organization to audit various steps of the process. Now suppose that it's used in such a way that there's some sensitive data that is being passed through that service.

SOA Runtime Policy Mismatch

Now there's another policy in place in the company that says that whenever you're dealing with sensitive customer data, it must be encrypted, for example, in the European Union, where privacy is paramount. So this policy exists in the organization but doesn't have any connection to this auditing service, and what's happened now is that someone's taking this auditing service and they're using it in a way where this privacy data is being passed through, but because there was no connection between how to deal with this privacy information and the service itself, this service starts auditing the private data and starts persisting it to a database in the clear.

"Overarching" SOA Management: Design Through Runtime

The above policy mismatch scenario is a typical example of governance procedures being applied and followed yet "something bad" still happens because there is not an overarching view of governance. There is no closed-loop governance in this case.

For More Information

Want to understand the inner workings of SOA runtime management? Download the free Actional webinar, SOA Runtime Governance