What do you mean when you say policy needs a declarative construct outside Java and .NET?
Yeah. It gets even more complex as you move to enterprise SOA. Not only do you have federation of different lifecycle constituencies but you also have federation of completely different business interests. What happens in that situation is that the policy of one unit has to interact with the policy of the enterprise. Can you give an example of that?
For example, it may be the policy of one business unit to have a certain level of security encryption. But it may be the policy of the enterprise to have an even stronger level of encryption. So the notion that you can take policy inside a single platform container is not that functional of an approach as you start to scale. An example would be a bank where they have CORBA services, .NET services, Java services, mainframe CICS services, services of hundreds of different types. The notion that you want to embed the logic of policy in a container or platform is not going to work. So where does the policy logic sit then?
There are two answers. Today there is policy logic around each of the different lifecycle constituencies. A very simple example is runtime policy. A lot of the runtime policy falls into the governance system, the new registry/repository policy system, but it turns out that other forms of policy logic exist in a lot of other types of systems. What I think is going to happen around policies of all different types is there is going to be a need for policy federation. That's the future scenario. Would this be part of the registry/repository, but separate from what was developed with Java or .NET?
Yeah. Because what we're really talking about is the ability to externalize policy. The point that is essential is that in order to automate and federate governance, which basically means in order to take someone else's concerns into account, you actually need some kind of system that allows you to manage that. And the system that allows you to manage that isn't the system that's contained within the system that created it. The metaphor is you can't really QA your own stuff. The system that created something can't be the same system that manages something because they're controlled by the same person. That's actually the wrong approach.
The right approach is there are people who create things and there are other people that manage the things that are created. That's where you start to see the need for externalizing policies into declarative systems and manage these systems through systems of record. It's a complex argument but what I'm trying to say is there are rules and logic that transcend development. Is the tooling to do policy by declarative construct is that available now, or is that something we're moving towards?
I think we're at the very beginnings of this art. What we've done is taken a few examples of these externalized enterprise logic scenarios, such as runtime policy. We've crafted very nice user interfaces based on things like Web browsers. And we've called the result something like policy system of record, registry/repository. But instead of saying lets make a way of declaring policy that's only meaningful to a developer, let's make a way of declaring policy that may be useable by a business unit constituency, someone who is sophisticated but not necessarily in development. That enables a lot more dynamic and agile change management. It's easier to change a parameter on a running service than it is to change the source code for the service, compile it, QA it and redeploy it.
In part two of this interview tomorrow looks at the future of SOA policy implementations that go beyond development platforms.