Inside Architecture

Notes on Enterprise Architecture, Business Alignment, Interesting Trends, and anything else that interests me this week...

Redefining SOA Governance

Redefining SOA Governance

  • Comments 11

My third post in a row about the notion of SOA Governance.  You'd think I was planning to speak about Governance this week.  (I am).

In general, Governance is a set of processes, responsibilities, and tools that reinforce good behavior and help avoid bad behavior.  With SOA Governance, we want to build a useful SOA environment, prove the ROI, and insure we don't screw up security.  We do this with policies and processes (mostly process).  Policy can only be applied to a small fraction of the governance problem.

Now, break it down further.  Only a fraction of SOA policies can be verified or reinforced with tools. 

Therefore, while SOA tools are useful, they don't deliver governance.   In my honest opinion, it is not rational to use the word Governance to refer to a tool at all.  After all, we don't refer to to Microsoft Operations Manager as a "systems governance tool," and SQL Server is not a "data governance tool." 

Here's a novel idea: Let's use similar words that have been successfully applied in other areas, so that the meaning is clear.  If MOM is a Network Management tool, then Systinet, IONA, and Amberpoint are Service Management tools. 

Tools manage.  People govern.

  • Perfect. I suggested "Direction" because I'm a movie fan, but in this business "Direction" has a different connotation than in the Movie business. "Management," however, is a much more generic term, and which has already been applied in similar ways in the software business. In addition, it exactly applies to the Governance process.

  • The term "Management" in this context is not anything new. Amberpoint and Actional and the line of products come to be known as WSMs or Web Service Management products.

    Most enterprises are currently concerned about runtime governance (monitoring, managing, accessiblity, urilization etc) and its just gonna  be a while before design time governance gets more focus than it currently has.

  • Hi Ram,

    For a moment there, I thought you were agreeing with me, and then you did it.  You said 'runtime governance' and then you said 'design governance'

    There is no such thing.

    Tools Manage

    People Govern.

    Let me be explicit:

    Software does not govern.

    Anything.

    Ever.

  • Is this rant because Microsoft doesn't provide a Governance solution of its own?

    Gary E. Smith

  • Hi Gary,

    Look at the definition (and at the prior two posts) and tell me of ANY software vendor that covers Planning governance, Funding Governance, Construction Governance, and Operations Governance.  

    I dare you to find a complete solution.  

    If everyone is at the first mile marker in a 500 mile race, the fact that MS is at the starting gate isn't all that worrisome.  When we do come out, we usually do well.

    --- Nick

  • I think there is a definite distinction between Governance best practices and then tools that enable you to apply Governance to an SOA. You are right, there are few vendors that unify everything. But then I would encourage you to ask where are companies having the biggest pain today?

    We are now embarking on new territory where IT & Service Management is being upgraded to SOA Management; IT Governance is now applying SOA Governance, and soon we'll start to see CIOs be replaced by CSOAs.

    Definitely I would like to see how you define SOA Management as a key integral part of collecting run-time information for closed loop SOA Governance, I think a lot of folks are heading the same direction!

  • Hi Dain,

    You said "there are few vendors unify everything."  I'd say that there are no vendors that complete the loop.  Perhaps I'm being harse.  After all, some vendors try to do various bits.

    However, it is difficult to speak of "closed loop governance" with a straight face when speaking of the SOA model.  

    It's a difficult model to imagine given the maturity of the industry right now.  We are still in "vendorland."  No ones software shares planning data using standards.  (Few people even collect planning data).  

    You ask a key question: where is the pain?  The answer is "depends on the model you have in place."  Many folks, desperate to see value in the model, opened it up to become a "wild west" where every service in the world emerged, and nothing is reused.

    If your model is "wild west" then the pain is "I need a sheriff".  But is that the right model?  

    Not everyone needs to go through the "wild west" stage.  Some of the rest of us are trying to jump straight to "a community of respect where we listen to one another."  If you look at it from that perspective, then the problem of "where is the pain" takes on a new meaning.

    Perhaps the pain is in the model, and the answer is not to get bogged down in the short term crisis, but to look to the long term "new era" where services are created because we need them... and not because we think we should.

  • Hi Nick

    Everyone seems to have a different view as to what SOA governance is for. This link (if it works) goes to a Plexo vote on the purpose of SOA Governance.

    Click'>http://www.squidoo.com/soagovernance/#module2374269

  • Hi Nick,  I find this discussion interesting from a variety of perspectives but one of the main ones for me is around your point that there is a difference between 'governance' and 'management'.  I've been spending a lot of time lately with our IT service management people in order to line up our ducks around management of a services environment within the ISO 15000 (nee ITIL) set of best practices and their experience seems to be similar to ours (perhaps because the concept of 'service' is nebulous and thus hard to pin down on the desk with a heavy tool).  In summary they complain that ITIL is actually a set of best practices around service management whereas customers are constantly asking for an ITIL 'certified' tool (which of course can't exist).  In our own sphere we have people looking for tools that can be 'certifed' to provide governance.  In both cases, however, I believe that you are correct in your assertion - i.e. that governance is about deciding on what's important i.e. intent, policies, best practices etc. whilst tools are about ensuring that such decisions are enforced.  As a result I think that there is a subtle but critical difference that you've highlighted - 'governance' is about capturing, codifying and realising intent whilst tools are about encoding that intent in a way that makes it more immediately enforcable for the practitioner at the point of need (at whatever point in the lifecycle they happen to be).  I do get annoyed with people saying that not having an EA tool/ESB/Registry means that you have poor governance - many organisations I've worked with actually run very good governance with just spreadsheets and judiciously codified review processes.  Sometimes I feel as if people just want to get 'the tool' because it's easier than addressing the real cultural issues that surround - particularly - IT governance.

  • Thank you, Ian.

    Well said.  Yes, tools should make the governance processes simpler.  That's their role.  But good governance doesn't come from good tools.

    It comes from well understood and simple decision rights.

  • Financial and Banking I work with a bunch of people that used to work in Collateral at ABN Amro, so it

Page 1 of 1 (11 items)