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.
Nonetheless, on a beautiful day in May, roughly 150 customers and prospects showed up for a SOA governance summit presented by Software AG at a hotel in the heart of Times Square. Maybe the turnout wasn’t so surprising given the locale. With the financial sector having seen Enron and corporate options scandals, not to mention the subprime meltdown, if there was ever a sector that begs governance, this oneâ€™s the baby.
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.
When it was Kannegantiâ€™s turn, his talk was a welcome departure from the usual SOA-and-see-the-light presentations in its acknowledgment that in the trenches, SOA may seem so abstract that it may difficult at first to gain support through acclimation. He presented several lessons, such as:
1. â€œDumbing down the technologyâ€ by eliminating the aura of mystery and the abstractness of service abstraction. Take advantage of social computing tools to tell stakeholders what’s really happening on the project and what it means (a challenge because architecture is not as easy to explain as, say, implementing a functional module of a business application), develop common plumbing services to get some quick wins (things like error handlers seemed a bit low level to us, and he later admitted to us that, no, those are not the first services you should develop, but they’re useful when you want to scale out the project) and then show how an approach that stays close to the basics can result in predictable production of services.
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.
3. When it comes to the usual role of EAs, which is to promote better, consistent architecture, use a carrot rather than stick approach.
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.