Governance rules

Before SOA, governance was implicit in your IT architecture. The way your applications behaved and operated was hard-coded. Loose coupling liberates application behavior, and this makes governance paramount, because otherwise you have anarchy.

But even though this much ought to have been obvious right from the outset, governance as an issue has crept up almost unnoticed on SOA practitioners. They have had to discover the full extent of their need for governance from bitter, trial-and-error experience. Even a company like Systinet, whose registry product sits at the heart of a large cross-section of leading-edge SOA implementations, has been caught out and last month had to announce "Blizzard", a project that won't become a shipping product before the end of the year.

The confusion and disarray stems from a failure to realize that SOA governance has to cover three distinct lifecycle phases, each of which has completely separate needs and requirements. But it hasn't been helped, either, by a lot of muddled thinking about metadata, and whether it should sit in registries or repositories. The registry/repository conundrum is deftly clarified by CBDi in a recent commentary piece, Registry or Repository, so I won't dwell on it here. Metadata, though, presents people with real problems of shared understanding. We've all safely pigeonholed it as "data about data," but as Infravio's Miko Matsumura has pointed out, "one person's data is another person's metadata." In the context of SOA, metadata piles up in multiple layers, until you end up with metadata summarizing average access times to documents that present data about policy to be implemented when creating services (in other words, how long your developers have had to wait when downloading governance guidelines).

Metadata is too big a topic to be dealt with in parentheses, so let me return instead to those three distinct lifecycle phases of governance:

1. Design time. The crucial 'Ah-ha' was when early adopters realized that governance meant laying down rules for developers to follow when designing services in the first place. If you don't do it then, how are you going to track what happens afterwards? You have no chance at all, obviously. But this is harder than it sounds, because developers are incentivized for meeting project requirements, and their natural inclination when faced with a recommendation handed down from on high that makes their job more difficult is to find a workaround that allows them to ignore it. You can read more about this whole topic in our June feature, Weak governance haunts SOAs, which is itself an excerpt from a more detailed treatment in the May 2005 Loosely Coupled monthly digest (which, by the way, for this week only — and please excuse the plug, but you might want to know this — is still available at a $100 discount for new subscribers. The price goes up after Friday 15th July).
2. Runtime. This is what the web services registry standard UDDI was designed to handle, and it manages well enough so long as you're operating in a perfect world in which governance policies never change and you're not bothered with monitoring compliance. That's not you? You'd better get a better registry, then. Jeff Schneider wrote some useful comments about this a while back. He cites Blue Titan, Infravio and Systinet as having viable offerings.
3. Change time. If design time was the 'Ah-ha' moment, then change time is the 'Uh-oh' moment. The thing that everyone forgets about a loosely coupled SOA is that design time is a groundhog day experience; it just keeps on coming round and round again. Your governance not only needs to keep developers in line when they create services the first time. It has to keep on coming back and making sure that they stick to the rules every time they tweak their code when some livewire manager decides to take your 'agile enterprise' rhetoric seriously and dares to ask for a functional update. Or worse, you (or your regulator) decides to change the rules and you have to roll out a new policy enterprise-wide and verify compliance across every one of your loosely coupled services.

Change time governance has everyone in a tizzy because implementing it is far more complex than anyone ever envisaged in computer science class. It's one of the key areas where the costs of operating an SOA could rise up and sabotage all those payback benefits you've been projecting. Think what happened when PC adoption got out of hand, except that this time the manageability nightmare isn't on people's desktops, it's at the heart of your enterprise application infrastructure. Uh-oh.

posted by Phil Wainewright 8:21 PM (GMT) | comments | link