A Governance Day in May

Just mention the word â€œgovernance,â€ and most people will equate it with auditors or attorneys who scold on all the wrong things youâ€™re doing, or that a gap in the access control system could put your CEO in jail. No wonder governance is such a hard sell, and why Forrester Research analyst Mike Gilpin and Software AG chief marketing officer Ivo Totev concurred that when it comes to SOA governance, maybe we need another name.


It was also a pretty sophisticated audience when it came to SOA background; virtually everybody in the room had already gotten their feet wet with SOA projects, and roughly 60% were already involved in some form of SOA governance effort. We had the chance to moderate a panel with Gilpin, Software AGâ€™s Miko Matsumura and Jim Bole, plus HCL Technologies consultant (and pragmatist) Rama Kanneganti, most of whom had spoke earlier in the morning.

Gilpin and Kanneganti gave the audience healthy doses of realism.

Gilpin maintained that, at least for larger enterprises, the deeper they get into SOA, the more likely theyâ€™ll wind up with four, five, or more enterprise service busses. In other words, don’t fool yourself with the myth that youâ€™ll have a single monolithic grand unification architecture, despite the best efforts of your enterprise architects. Just as most organizations never succeeded with the galactic enterprise data warehouse or that top-down enterprise data model, life in a modern post M&A world is just too complex and heterogeneous. He noted that no vendors have yet picked up the mantle on how to integrate all those integration stacks, but in the next year or two youâ€™ll start seeing commercial product rolling out. Nonetheless, he conceded that selling an integration stack of integration stacks may not be the easiest pitch that youâ€™ve ever made to a CFO. For starters, if you end up using the same rationale that was purposed towards justifying those initial SOA investments (e.g., more reuse, agility, better IT/business alignment), the response is likely to be jaded. Gilpinâ€™s dose of reality was not without its ironies: as you implement SOA to unify your app and data silos, you could wind up with creating yet another Ã¼ber silo.

2. To reduce risk, organize something like an informal Center of Excellence, but pitch it more as â€œa center of getting things doneâ€ that contends with issues such as ownership of data or processes.

In between, Miko (weâ€™re violating our usual editorial convention of last names because, well, his first name is so heavily branded) provided a talk that was, literally, a stretch. Relating some metaphors of evolution (reptilian functions are still present in human brainstems, and weâ€™re genetically 95% equivalent to chimpanzees), he explained how SOA projects must navigate entrenched tribal turf rivalries, such as when services transition from design (software development) to run time (operations). And from that, he launched into a discussion of his latest initiative, looking at the synergies of service provisioning and virtualization â€“ which we feel is the tip of the iceberg of a larger issue. Namely, how can you manage compliance with service level agreements or contracts as part of run time governance without some logical ties with IT operations and IT service management/ITIL worlds. Itâ€™s an area for which vendors on both sides of the aisle â€“ the Software AGs, the HPs, and the IBMs, have yet to provide adequate answers. But, bringing the point back home, itâ€™s a question of dealing with potentially warring tribes, as a debate rekindled by Todd Biske on the future of ESBs brought out a few weeks back.

As if we canâ€™t get rid of this tribal mania yet, well, maybe they’re not a tribe, but a group of (choose one) soothsayers, high priests, or medicine men within the tribe. Weâ€™re talking about EAs here. When we posed the question of what SOA governance is, the panel concurred that it is a combination of people and processes, with technology as tool to apply the processes that people (in or out of their tribes have worked out). Bole volunteered that business processes might be a better way to sell SOA, and ultimately, SOA governance to the enterprise. We pressed again, asking, at the end of the day, whoâ€™s accountable for SOA governance? One of the answers was, maybe, yet maybe, SOA governance could make EAs relevant, finally.