SOA Governance, or any other type of governance, is and has always been one of the least sexy topics in IT. It’s right there alongside testing, operations and the helpdesk. We, the hired consultants, developers, designers and even architects, only want to talk about the new and the next, the hot and happening, the Gartner Hype Cycle and the Forrester Wave.
Consultants don’t like to think about Governance. The reason for this is that governance is only useful to the people who want to use the system and adapt it when extra or new requirements need to be implemented. Consultants only have to design and build the system and then leave again. (Which is not really true of course. We consultants do care about governance, but are thwarted in our efforts and after a while give up)
In order to explain why one needs Governance in the first place, let’s go back in Software Development History together.
History of Software Development
In the beginning there was: the mainframe. The mainframe is basically one big central computer that runs a number of batches. Only one person is in control and determines which batch runs when, so no two batches will interfere. Everybody was happy… until the batches couldn’t fit into 24 hours anymore.
Next step: multiple best-of-breed systems. One system for accounting, one for customer contacts, one for billing, etc. Each on its own hardware running its own batches. Problem solved… until someone discovered they were entering the same data in multiple systems.
Around comes Enterprise Integration Application (EAI). Customer information is typed into the Customer System and any other system which requires this information will receive all the updates from the lead system. The Integration Software solves all (technical) incompatibilities.
This of course introduced a whole new set of problems on a whole set of levels, but we’re not done yet with innovation, so keep up! The problems with EAI were so numerous that in the last decade the new and latest technical “solutions” are too much to keep up with. My last personal effort was SOA, which at least promised solutions on multiple levels.
Levels? What levels?
Looking at a company you can (very broadly) identify the following levels:
- Strategy and Policy (Strategical)
- Organization and Control (Tactical)
- Operation and Maintenance (Operational)
- Human Resources (People)
- Information Technology (Technical)
All job titles that look like CxO, in others words the chiefs, operate at the Strategical Level. Their major concern is (or should be) the question: Where are we going? Or rather: Where do I want us to go? or Where should we go?
On the Tactical Level we find the (project) managers. They also have only one question to answer: How do we get there (as efficiently as possible)? Both very different and equally needed skills are required to be successful in each role, but that’s not the focus of this article.
The “what” question is for the Operational Level. What should we do today, every day, to get where Level 1 want us to go using the efficient route created by Level 2?
The workers are found on Level 4. They are the do-ers. They don’t have any questions to answer, they just do. They are assisted in their doing by HR, whose major concern is the well-being of all the people in the company.
And then there is us, IT people. Our only focus is the technical. Our problems are technical and our solutions are also technical. I’m not talking about developers only, this includes designers and architects. Not enough room to run all my batches in 24 hours? Technical solution. Having to input the same information twice? Technical Solution. Some service is not performing? Technical Solution!
But as Einstein already told us:
We can not solve our problems with the same level of thinking that created them.
Governance
So we need to move to another level of thinking to solve our problems: no more technical solutions allowed! At least not until we first solve some fundamental problems. How do we solve problems? By asking questions, and my favorite questions start with: why? Why is my service not performing? Why can’t my batches fit into 24 hours? Remember: no technical solutions allowed! For example the problem of a service that is not performing should not immediately be solved by adding more power. It may be the answer, but it may also not be necessary at all.
Observe:
“My service is not performing.”
“Why is that?”
“It is used more often than we thought it would when designing it.”
“Why is that?”
“It could be there are people or processes using the service that shouldn’t.”
“So who is using the service, and why? Is it OK that it’s used by these unexpected users?”
“Uhm, I don’t know. I guess I should investigate that first then…”
This requires thinking about what it is that you want to achieve with this service, what its business value is and what the business value can and should be. Someone has to own the service and think about it on a tactical and strategical level.
That is Governance! (A more formal description of SOA governance can be found on wikipedia)
Levels again
Back to the problem. The fact that it manifested itself at the Technical Level (5) doesn’t mean it should be solved there. Instead, people (4) should ask questions. Some of these questions can be answered at Level 2 or 3 and others only at Level 1.
Here the real problem of governance shows itself: the people at the Technical Level know this! They know each service needs an owner. They know that custodian roles are needed to guard and keep track of schemas, policies, registries, etc. But somehow they can’t get through to the right Level to get this change implemented.
A few years ago I explained SOA Governance to a small audience and this was one of their questions: how can we, hired consultants who work at the Technical Level, make the people at a higher Level understand that the organization needs to formalize these roles in order to succeed at SOA? I didn’t know the answer back then. I may have mumbled something about the possibility of education and recommended they should try real hard.
Change management
Luckily I recently attended a course on change management and suddenly everything fell into place. People at a certain Level only listen to other people operating on the same Level. And what’s more: you can not change this.
Wow, what an eye-opener!
This is what happened in my brain: “These stupid managers and CxO’s. Only listening to each other, probably while playing golf. Why won’t they listen to us? Too stupid to solve simple computer problems. No wonder we don’t ever listen to them…” Aha!
Eye-opener number two: it happens at every Level! At the Technical Level we are just as guilty of not listening to other Levels! Why should we expect management Level to listen to us?
But being handed eyeopeners is one thing. The big question remains: how to solve this?
Bring the right people
One of the solutions is to talk to the right people, using the right people. What does that mean? Let me explain. When selling for example, first ask yourself what you are selling. Are you selling a technical, a tactical, or even a strategical solution? In the case of SOA, the answer – in my opinion – is ‘strategical’. Meaning you should sell to Level 1. And since Level 1 people only listen to other Level 1 people: bring your own CxO when you sell.
When a technical consultant concludes a custodian role is needed at the Operational Level, send your manager of operations to your customer to talk to their manager of operations. Chances are they’ll listen.
But what if it’s your own company that doesn’t listen to your excellent suggestions? Then go for this solution: try to separate the suggestion from yourself and thereby from your own level. Ask leading questions to the right-level-people in order for them to come to the conclusion that you have already drawn. In that way, the suggestion comes from their own level and is much easier accepted.
“But… that’s really unfair!”
Yes, it is. And the sooner you accept that, the sooner things are changed. Care about the change, not about the process.
