Lifecycle Governance

In a world where SOA means a decreasing amount of control, over an increasing number of heterogeneous components, on an immature and evolving platform, governance sounds like a pretty good thing to have. So it makes a lot of sense for us to be spending time in that area. Unfortunately we are repeating a classic blunder in many cases -- we are trying to measure at the end without providing ourselves with the process, tools, or metrics to get us there. Let me give you a “non-software” analogy: Say I’m running the Highway Patrol. I set speed limits out on the highways, and I equip police officers with radar guns and the ability to write tickets. But the cars on the road were never outfitted with the ability to report to their drivers what their current speed was, and I didn’t design cars that were able to run within the accepted minimum and maximum speed limits of those highways. I would be setting up my drivers for a pretty significant problem. This is why we have cars that are designed to run on the highways that they are designed for, and we have speedometers in those cars -- to make sure that our drivers do know that they are operating within their expected boundaries. In software, governance at the run-time level is the radar gun, but where are the properly designed cars and the speedometers that make sure that the drivers are able to target the right boundaries? We need Lifecycle Governance. Lifecycle governance is the processes and tools that will provide IT with the ability to deliver within the boundaries of run-time governance. Here’s a simple example of this in the performance world: You can establish as a run-time governance policy that a service level for a particular service must perform within 2 seconds for a typical transaction. Great -- but if you don’t provide a process and tools so the development team can ensure that they are going to meet that goal during the lifecycle of development, how can I hold them to any kind of standard in deployment? We need the ability to make sure that they have what they need during the development and maintenance phases of that particular service if we are going to write them a ticket when they break the speed limit out there in production. A more complex example of this is the semantics around functionality. This one gets much tougher. Say for example there’s a policy that all customer creation workflows will happen through a particular service. So a run-time governance policy is put in place to that affect. But what it means to create customer accounts for different divisions in the organization, or for different groups within each division, might be different. We have to make sure that we capture each others’ requirements, and that we enable the system to be rapidly evolved into the whole organization’s understanding of what it means to create a customer account, not just one division. So, we can set a governance policy that accounts must be created only through this particular service. But now we have to enable the process to “drive friendly,” which means we might elaborate on requirements for inter-dependent teams to get together and make these kinds of enhancements and trade requirements with each other to make sure that the system is going to get built for everyone’s benefit. Essentially, we need tooling so that I (as a service provider) am testing the different semantics that I need to support. And those who need to use my service can test my service too. If you need to leverage my customer creation service, you need the ability to test the semantics of my customer creation service pre-production. You need to be able to log bugs against it. At a runtime level, you’ll need to make sure that I don’t make changes that break that functional contract, if you will. And, if I do, we would rather catch the violation with an early warning system, so that we don’t have to get that ticket in production. We can find that out long before we’re on the highway banging into each other. In summary, run time governance is an absolutely great thing. It sure sounds good given the world we’re entering, but lifecycle governance is the only way we’re going to create a predictable, measurable path to get there.