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.

About these ads

4 responses to “On the Death of Design-Time Service Governance

  1. While I agree that run-time governance is absolutely critical if you are consuming or providing services from the public internet, the notion that cloud computing “kills” design time governance is a bit of a stretch. Clearly, if you’re not building the service, only consuming it, then most policies focused on design and development won’t be applicable. At the same time, however, the activity of selecting a service provider, which is not a run-time activity, must be governed to make sure that different parts of the organization don’t pick different providers for the same service (if desired) and that as part of selecting a provider, the contract with that provider, including the functional interface, is thoroughly reviewed to make sure that it doesn’t cause and undue amount of work for the consumer to use. That’s still “design-time” governance, and the need for that doesn’t go away.

  2. Pingback: Governance Needs for Cloud Services | SOA Governance - Service Oriented Architecture - SOA Business - SOA Design - SOA Services - SOA Software - SOA Solutions - SOA Security - SOA Web Service

  3. Pingback: William Vambenepe — Generalizing the Cloud vs. SOA Governance debate

  4. Pingback: Design-Time Governance Lost in the Cloud? The Great Debate Rages | SOA Governance - Service Oriented Architecture - SOA Business - SOA Design - SOA Services - SOA Software - SOA Solutions - SOA Security - SOA Web Service

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s