Are Enterprises Meaningfully Applying SOA Governance Practices Across Their Environment?

Wonderful question!

One of the things about SOA Governance is that it requires modification to behaviors. This is why there's so much risk associated with adoption but at the same time why the payoff is so high.

After all, if you look at the cost and complexity of Enterprise IT, most organizations are crying "uncle".

At the risk of making a plug, my book SOA Adoption for Dummies is about proper adoption methodology.

Today, the "install software and it just works" concept is all but moot. Despite the desire of software that "just works", the value obtained by software is pretty much only attainable when the organization changes its behavior, for example in a business process.

Visibility solutions are very powerful in this regard, in that you cant change, align or transform something that you cant see.

My 2 cents,
Miko

Yes!!!! But then you would expect that since WebLayers provides a design time governance platform for the management, enforcement and reporting of policies and best practices across the service development lifecycle.

WebLayers has many customers that have implemented governance at various points in the development lifecycle, all of them have seen meaningful results, lower costs, because they are applying governance early. It used to be that most of our customers would think of governance only as a part of a registry/repository now they are realizing that to gain “real value� you need to employ governance at the earliest stages of the service development lifecycle. For example, our customers can govern their requirements environments, development environments (eclipse, source code and build systems)and of course the reg/rep. Basically making sure the right policies and best practices are adhered to throughout the lifecycle not at one point in the lifecycle.

Since the question was about “meaningful application of SOA governance� the example that comes to mind is Thomson-Reuters who has seen an ROI from their governance solution of $1.4M in the first year.

I do not think that many organisations "truly leveraging SOA Governance principles across their entire design, development and delivery lifecycle" because if they do this, they have lost already.

Truly SOA Governance MUST start in the Business, with "modification to behaviors", as Miko has said already. The first thing to happen is that the business requirements have to be service-oriented. SOA is not about HOW, it is about WHAT, WHY and WHO.

For example, to leverage Testing and Validation (for iTKO), those who execute User Acceptance Testing and those who manage business services have to know what they deal with and what it requires to work with services.

In my book (I do make a plug) 'Ladder to SOE'(http://www.troubador.co.uk/book_info.asp?bookid=917) (due in weeks), I explain what does mean SOA in business and what SOA requires to be changed in business to make it effective; then it goes to testing in IT.

I believe a lot of implementations give "lip service" to governance and will implement the registry as part of the ESB support requirements, but do not have a plan for how to move beyond this phase of implementation.

As any good consultant would say, "It depends." There are organizations that are getting it right, but they're likely in that minority of well-managed companies that are in the leading edge in methodologies and approaches. There are many others that have fragmented efforts, or islands. I agree with Miko and Michael, in that you can have the greatest tools and technologies in the world, but if the business is on the wrong course, it's for naught. Remember, the Titanic had the most advanced engines and infrastructure of it's time, but that didn't really seem to matter.

We see every possible level of SOA governance – from those organizations that start, or align, their SOAs with mature enterprise and business architecture practices to those organizations that use SOA approaches in a much more ad-hoc, tactical fashion.

For those firms that begin, or align, their SOA efforts with a well developed enterprise architecture much governance comes along for the ride as does business-level governance of SOA practices.

For example, if service definition begins with defining the goals, requirements, and process of an organization well before the technical definition of the services, then SLAs, validation, and management of services is already well described. On the other hand, where technical services are defined absent these related factors and drivers, you often end up with a poorly governed and ultimately poorly focused set of services.

This is timely for me to weigh in on as I just spent a couple of hours on the phone yesterday with several of our key customers and we talked in depth about their progress in implementing governance and what they were doing. The good news is that we are seeing meaningful use cases being implemented with measurable results. Some central themes emerged.

--the most successful examples start with an organizational commitment to governance and an empowered team with both the means and the accountability to make it successful

-- successful implementations also result from a very clear understanding between the business sponsors and the governance owners of what problems they are trying to solve first and the measures of success. If the problem is increasing compliance by developers to key design-time policies, then the team agrees to which policies are worth investing in governing first (as the result of not adhering to such policies is of high cost) and the team agrees on what the action is if non-compliance is discovered, how it will be measured and how compliance should be rewarded/supported.

-- The most successful examples also do not try to boil the ocean but focus their resources on a boundable challenge that will show both short term and long term benefit and then give them a springboard (a.k.a organizational support) to the next challenge... some of our customers are focusing on certain policy management challenges -- design time or run-time, some are focusing on standing up the system of record to solve the visibility issue, some are focusing on lifecycle management and driving better hand-offs between teams, but the common thread is that the initial use case is clear, agreed upon, and measurable.