On the Death of Design-Time Service Governance

Practically on the anniversary of Anne Thomas Manes now-famous SOA-is-Dead pronouncement, David Linthicum suggests we convene the vigil for design-time service governance. Dave maintains that cloud technology is going to kill this canonical aspect of governance because runtime service governance simply provides much more immediate value. Needless to say, rather than a somber occasion, Dave’s started more of a donnybrook. I guess it’s about time to get off of the bench and join in the fun.

The incendiary nature of is-dead statements often conceal  the subtle but important ideas behind them. Dave’s declaration is no different. What he’s really suggesting is that cloud will rapidly shift the traditional priorities with respect to services governance. In the big SOA era (before Jan 1, 2009), design-time governance was king. It fit nicely into the plan-manage-control discipline underpinning a large enterprise-scale SOA effort. And to support this, tool vendors rushed in and offered up applications to facilitate the process. Run time services governance, in contrast, was often perceived as something you could ignore until later–after all, on-premise IT has reasonably good security and monitoring in place. The technology might be old and the process a little byzantine, but it could tide you over. And if any internal staff were caught accessing services they shouldn’t be you could just fire them.

The cloud inverts this priority. If you deploy even one service into the public cloud, you must have runtime service governance in place. That one service needs to be hardened and protected as you would a DMZ-based application. You must have continuous visibility into its operation from the moment you turn it on. Run time governance simply cannot be put off.

The cloud is also about agility. We are attracted to the cloud because it offers rapid deployment, elastic computing, and that hard to refuse pay-for-what-you-need model. This same sense of agility is a leitmotiv throughout the entire development process. When you talk to teams that have been successful with the cloud, they are usually small, they rail against enterprise bureaucracy, and agile development process is in their DNA. They are comfortable and extremely efficient with the tools and process they have, and they don’t see a lot of reason to change this. Do they still need discipline, organization, process, communication, sharing? Absolutely–but they have this; it’s ingrained into their existing process. I see this in my teams developing products every day. It’s the mix of great management, excellent people, process where it’s been shown to be needed, and a basic set of tools we all rely on every day.

Will design-time services governance tools disappear completely? Of course not. But their value becomes apparent with scale, when you begin to approach “a lot of services” (and no,  nobody really knows what this means–probably more than a scoville, less than a parsec). The point is, in the cloud nobody starts there, but they do need to focus immediately on the threats.

In the end, governance priorities in the cloud come down to a pretty simple precept: Duplicating a piece of functionality probably won’t get you fired; leaving an open door that was used to compromise corporate data probably will.