Can SOA governance technology be distracting?

In a recent post, David Linthicum asks “Can SOA governance technology be distracting?“. His answer is yes, and he offers the following sound advice:

First, only purchase SOA governance technology, if it’s indeed needed, after you have a complete semantic-, service-, and process-level understanding of the problem domain. Never before.

Amen to that. In my opinion, for all but the most mature and involved environments, the procurement of an SOA governance platform should be well down the list of priorities. I’d add to David’s list of things that need to be ‘worked out’ before you get that cheque book out:

• What is your vision for governance itself? Do you want to adopt a ‘iron fist’ or ‘hand in glove’ approach? Is your registry going to be a mechanism for governing or a side effect of it?
• Who’s going to populate it? Have you got your analysis, design and development processes sufficiently honed that your repository isn’t going to turn into a dumping ground of candidate services?
• Have you actually got any services live yet? Governance is a whole lifecycle thing. Until you’ve worked out how you’re going to deploy and manage services in the production environment and demonstrated that this works, how do you know what capabilities your governance platform needs to offer?
• Most importantly: What are the use cases for your governance platform? Can you demonstrate that these use cases can’t be addressed using your existing tooling (even if that’s Microsoft Excel)? Be honest with yourself about when you’re likely to implement these use cases. If the answer is further than one year away, then for the time, you might be wise to forget them. There is little point in spending good money on runtime governance or automated deployment technology when in a year’s time you’ll be able to get more for less.

A lot of projects using SOA governance tools at the moment treat them as glorified databases. If that’s where you’re at, consider using something less specialised that allows you to evolve your ideas, understanding and schema before you commit to something that will make this innovation harder and more time consuming. When you’ve spent six to twelve months getting your ducks in a row, so to speak, you’ll be in a much better place to make decisions.

I’d really welcome stories from people about how they’ve implemented governance platforms in the past, whether they’re informal (e.g. Wikis, bugtrackers, spreadsheets) or formal (e.g. IBM Websphere Registry and Repository, CentraSite from Software AG): What did you implement? What worked? What didn’t? What would you do differently next time?

 

The Value of Governance to Architecture

People have often asked me “what is the value of (enterprise) architecture?”.  Well, first off, let’s think what architecture is, so we can talk about the value it provides.

Architecture is really a best practice, following the principles of good design from a top-down approach, whereby some sort of concept or vision is sketched out, which is firmed up into a blueprint, before the design is formulated using the applicable standards and policies needed to meet requirements, and finally, the artefact is built.  It doesn’t really matter if you are designing a house, an application or the whole enterprise – the same basic process is followed.

By following this approach the beginnings of a best practice start to emerge, which should deliver the following benefits:

• Standards and statutory requirements are identified
• Redundancy, duplicity and waste is minimised
• Resources can be reused and operations and maintenance are streamlined
• Return on investment is increased and total cost of ownership is decreased
• A plan for future development emerges, which can be consistently communicated, and to which all interested parties can participate

That’s all good and said, but how do you ensure these benefits are delivered?  Simple – that’s the role of Governance.

What governance does is makes sure that your architecture is effective and sustainable.  When an architecture is initially defined, many architects make the mistake in that their designs are efficient, but this is not the same as being effective.  Therefore, the governance model must ensure that what the architecture delivers is what the business and IT communities really want, and is being utilised to its maximum potential.

Architecture also suffers the problem in that after a period of being in place it is not always as it was when it was initially designed, because changes to the realised architecture have not been reflect back into the design.  Or on the other hand, the requirements or technologies have changed over a period of time, but the designs have not, thus rendering the architecture ineffective.  This is what we mean by sustainability – the architecture must be effective over a measurable period.

And this is the value of governance to architecture – it ensures effectiveness and sustainability, through its quality review processes, so that compliance and uptake can be measured, and where necessary, the architecture amended.

But the governance model itself must also be effective.  It’s no good putting in place over-bearing governance processes that make it too difficult for people to comply with your architecture – all this will do is stifle creativity and development.  Or worse – give people an excuse for not adhering to your architecture.  What you should instead be doing is encouraging people to increase the uptake of your architecture i.e. make them see the benefits of governance, not the restrictions.

Therefore, your governance model must be complementary to your architecture; that is, as the maturity of your enterprise and it architecture increases, so too must the maturity of governance.  This is one of the objectives of governance that many people overlook – your governance program should actually be increasing the maturity of your organisation and its approach to architecture.