A number of industry analysts have been speaking of SOA Design Time Governance failure for some time. As I’ve written previously, primarily this was because the majority of enterprise IT shops hadn’t reached either the SOA maturity level to deal with it or had a large enough service catalog to have a need to address it with tools.
I’ve seen a lot of change in this in the past year, as many organizations are suddenly asking for help in defining requirements for SOA governance tools.
But what of the cutting edge IT shops, the early SOA adopters who ran into SOA governance needs years ago and started working with SOA Design Time Governance tools of earlier generations? (I admit to being one of these, having led the purchase of a design time governance tool for my U.S. Fortune 50 employer at the time, about 7 years ago.)
Most of these projects FAILED! (Including the one I ran.) The tools were complicated and somewhat rigid, the processes to make it successful (the IT people-process changes necessary to successfully incorporate the tool) weren’t well understood. As a result most design time governance projects morphed into simple service catalogs. The complicated and expensive design time governance tools turned into a simple library website. And sometimes not for services (as asset management tools with flexible templates, they easily serve the needs of other reusable IT assets – such as architecture designs).
So today I find this interesting announcement in my inbox:
SOA Software Announces Repository Federation Solution
Repository Manager supports downstream, horizontal, vertical, and custom federation scenarios
July 26, 2010 – SOA Software, (blah blah blah), today announced the availability of comprehensive SOA federation capabilities in its…product. These capabilities help customers share software development asset information effectively within and outside the enterprise, govern how this information is shared, and integrate this information (blah blah blah).
Downstream Federation: (products) federation capabilities for leading service registries, including SOA Software’s Policy Manager, IBM WSRR, HP SOA Systinet, TIBCO ActiveMatrix and SAP ESR, automatically synchronize service definitions, supporting information and governance states both to and from the run-time environment. This is unique in the market and provides customers with granular control of their various registries from a single platform…
What strikes me about this? Now we have a vendor who’s going to cross-load information from previous (failed) installations of design time governance tools. I mean, why else would an enterprise have multiple design time governance tools (or even instances of the same tool)? These tools, by nature, handle multiple libraries or catalogs of information.
So multiples means previous failures have devolved into niche catalogs of select assets, become departmental tools or limited in use by a few major project teams or architect led projects. (Given the price structure of these tools enterprises do not choose them as departmental solutions. These are enterprise-wide priced tools.)
All this says to me that governance is making a comeback. However, the key to any governance project is not the particular capabilities of the tools, but the processes and methodologies necessary to get a successful implementation and tool use acceptance. Incorporating design time governance into the software development lifecycle is the key success factor. How a vendor is going to help the customer to make that happen is the first question any customer needs to ask.
(Photo credit – SOA World Magazine)