Skip to main content

SOA Governance is Alive, Alive!

defib


Suddenly this year clients are calling me up about SOA Governance, service libraries, service monitoring and control.  First SOA was dead, then SOA governance was dead (even saw an article that SOA governance is more than just dead, it’s a murderer, killing the future by stopping cloud computing).  What’s going on with all my customer calls?

Here’s a simple fact about services.  Until a significant percentage of frequently used business processes have been exposed, and exposed at a relatively granular (detailed) level (without being too granular that they require re-composition and orchestration every use), the major SOA ROI (return on investment) doesn’t happen.  Kind of like a real world physical library, it won’t have much traffic until either it has a large collection or a collection of popular material.

image Most SOA efforts begin Bottom Up, with programmers and projects beginning to use SOA technologies simply because they are available and enable getting the job done (rather than planned, architected, and adjusting development processes to handle the new approach).  Therefore the services exposed aren’t necessarily ones with high (re)use potential, they’re whatever the particular project that was using some SOA tech happened to need for their deliverables.  Even if the enterprise moves to Middle Out, still the SOA development is oriented around the projects driven by the business need of the moment.

This makes traditional SDLC (software development life cycle) sense, IT should be driven by the business needs and goals!  But like a well planned data center doesn’t run new central network wires every time a new rack is installed, nor install a server per application (rather they manage overall “capacity”), and a well planned building doesn’t run new wires to each new office (but has trunk lines and break-out boxes strategically placed throughout the areas), some top down planning is required to QUICKLY get SOA ROI by focusing on the highly (re)useable services and enterprise business processes.

Since few organizations have done that, they don’t start to see real SOA ROI or value until they’ve built 200+ services.  Neither are they seeing significant multiple use (I don’t think “reuse” is the right term for services as reuse implies multiple installation, which services avoid) until they hit that milestone.  And without multiple use they don’t start to encounter SOA complexity, spaghetti integration, library and catalog issues, or governance issues.  Neither does service security become a big issue until key business processes are being exposed.  (Monitoring does become an early issue that most struggle through manually.)

Therefore it takes years for the average IT enterprise 3+ years of SOA and service exposing projects to either start experiencing significant service (re)use and the associated difficulties of managing a large quantity of active services.

graph-o Hence the sudden calls about SOA Governance.  SOA was being declared dead by the pundits as it reached the tipping point of moving from the early adopters to the early majority.  For the IT pundits SOA may be dead…as an area of interest and punditry.  They moved on to TNBG (The Next Big Thing), in this case Cloud Computing – which as far as I can tell is still stuck with the Innovators (as I’m not hearing even early mainstream type solutions from the vendors).

But for the majority, their SOA efforts have been building their libraries and are entering later stages of implementation maturity, thereby encountering the need for services management a.k.a. (also known as) SOA Governance.  Both design time needs in the form of catalogs and repositories as well as some service lifecycle control, and runtime needs in the form of detailed monitoring,  transaction monitoring, root cause analysis, and SLA definition/control/alerts.

Surprise IT pundits, SOA Governance is going mainstream.  Given the responses I saw watching governance trying to be sold two years ago (and my own efforts to implement a SOA Governance tool set 6 years ago), I’m pretty surprised myself.

Fortunately, though it was slow going for sales for the vendors they haven’t been standing still.  Today’s vendor offerings in the SOA Governance space are sophisticated, capable, and offer some surprisingly advanced features.  The vendors have been some very complete governance suites that cover the requirements of the space extremely well.

SOA Governance is alive, alive!

Labels:

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 disast...
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