Skip to main content

Signs of Industry Governance Failure and Recovery

 

gov 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)

Popular posts from this blog

Integration Spaghetti™

  I’ve been using the term Integration Spaghetti™ for the past 9 years or so to describe what happens as systems connectivity increases and increases to the point of … unmanageability, indeterminate impact, or just generally a big mess.  A standard line of mine is “moving from spaghetti code to spaghetti connections is not an improvement”. (A standard “point to point connection mess” slide, by enterprise architect Jerry Foster from 2001.) In the past few days I’ve been meeting with a series of IT managers at a large customer and have come up with a revised definition for Integration Spaghetti™ : Integration Spaghetti™ is when the connectivity to/from an application is so complex that everyone is afraid of touching it.  An application with such spaghetti becomes nearly impossible to replace.  Estimates of change impact to the application are frequently wrong by orders of magnitude.  Interruption in the integration functioning are always a major disaster – both in terms of th
Read more

Solving Integration Chaos - Past Approaches

A U.S. Fortune 50's systems interconnect map for 1 division, "core systems only". Integration patterns began changing 15 years ago. Several early attempts were made to solve the increasing problem of the widening need for integration… Enterprise Java Beans (J2EE / EJB's) attempted to make independent callable codelets. Coupling was too tight, the technology too platform specific. Remote Method Invocation (Java / RMI) attempted to make anything independently callable, but again was too platform specific and a very tightly coupled protocol. Similarly on the Microsoft side, DCOM & COM+ attempted to make anything independently and remotely callable. However, as with RMI the approach was extremely platform and vendor specific, and very tightly coupled. MQ created a reliable independent messaging paradigm, but the cost and complexity of operation made it prohibitive for most projects and all but the largest of Enterprise IT shops which could devote a focused technology
Read more

From Spaghetti Code to Spaghetti Connections

Twenty five years ago my boss handed me the primary billing program and described a series of new features needed. The program was about 4 years old and had been worked on by 5 different programmers. It had an original design model, but between all the modifications, bug fixes, patches and quick new features thrown in, the original design pattern was impossible to discern. Any pattern was impossible to discern. It had become, to quote what’s titled the most common architecture pattern of today, ‘a big ball of mud’. After studying the program for several days, I informed my boss the program was untouchable. The effort to make anything more than a minor adjustment carried such a risk, as the impact could only be guessed at, that it was easier and less risky to rewrite it from scratch. If they had considered the future impact, they never would have let a key program degenerate that way. They would have invested the extra effort to maintain it’s design, document it property, and consider
Read more