Governance and SOA

I was having a great conversation with someone over Business Process Modelling tools last night and ultimately got into the discussion around Governance (the other side of his role).  So I thought I would open the conversation a bit and share some thoughts.

One of the things I like about Service Oriented Architecture (SOA) is it’s flexibility.  As we joked last night, if the business ever figured out how flexible and fast this approach can be we could be in trouble.  But there is some truth there and that’s why we ended up on Governance.

We both agreed that Governance is not about Policing.  It’s about setting Guidelines, not rules.  I think in the world of Governance the following is EXTREMELY crucial (more so than normal):

  1. Guiding Principles – these should be facilitated when created by key end-user stakeholders so there is involvement and buy in.
  2. This is not an Accenture PowerPoint that lives in the stratosphere, so you need to be close to the action, both in the business and technology.
  3. Communication standards are crucial.  I don’t mean technical, I mean talk, …  For example I was on a project where someone had sent a design document about how their service should be called and the format of the output.  Nothing wrong there.  But the external system went and hard-coded the parsing of the xml file that was returned and so when a technology upgrade happened and the XML file changed, the hard-coding created to firm of coupling.  This may have been done for some good reasons, but the source service didn’t know and should not have needed to care.  Some good communication would have helped.
  4. Registries – I really don’t care how many you have, but make them accessible and use these as your access control.
  5. Capacity Monitoring and Planning – one of the recurring themes I hear is if I build this sevice for my needs and then someone comes and starts to consume the same service who will pay for the increased hardware to meet the levels of performance.  This is a bit of a red herring.  If you have a couple of good guidelines here you will note that if that consumer of your service had had to build it there would have been a cost.  So lets be real.  Which leads me to…
  6. Cost per transaction management – we joked last night that we are back to mainframe MIP buying, but truely you have the ability to cost allocate on a transaction basis to recover your cost and maintenance.
  7. Mediation and Flexibility – As the role of governance like architect does not come with a wack of money that you can give someone when you tell them that the corporate standard is XYZ and this is 2x the cost of another platform.  That doesn’t sit well.
  8. Speed – in the SOA world there is opportunity to really drive evolution and align ourselves even tighter to the business.  So the governance model needs the speed capability.

Some thoughts for a very early Friday morning.  What have I missed…

Leave a Reply

captcha *