Let’s face it, to most people in IT, “Governance” is a dirty word. That perception is not born out of an idea that IT governance is bad, but out of the reality that IT governance is badly implemented in most organizations. When an organization confuses good IT governance with overly detailed and prescriptive IT governance, it starts to constrain rather than enable its people. And when people feel constrained and not empowered to make the decisions, they work around or against the process, which then results in proliferation of shadow IT.
The reason for this phenomenon is that many organizations approach IT governance with a few very flawed assumptions around how software and technology projects work:
- Changes are bad;
- Consistent results are driven from consistent processes;
- Standardization reduces the number of decisions, which makes the process more efficient and consistent; and
- Measure of a good project is on-budget and on-time.
These assumptions are fatal to any IT organization because they fail to recognize the realities of the nature of technology and the people implementing it:
- Technology is about change. The whole point of implementing technology is to support and enable more rapidly changing business needs. Add that to the speed of technology changes, the default position of any good IT governance process should be to assume constant change and deal with it head on instead of trying to contain and avoid it.
- Speaking of change, there is no way for a one-size-fits-all process to anticipate all the different ways a technology project can unfold. In fact, the more prescriptive a process is, the less likely it will fit the next project. There are simply too many variables and moving targets in modern enterprise IT projects.
- You hired smart people to implement technology and guess what? Smart people like to make decisions and feel ownership of their work. By over-standardizing, talented tech resources are turned into the IT equivalent of assembly line workers. At best they become disengaged and stale in their skills. But more likely, they take matters into their own hands and create opportunities to make decisions or fight the governance process to retain some ownership of the work they’re being asked to do.
- IT initiatives exist to make your business better and the users happier. While budget, scope, and schedule are important, they’re management measures on the process rather than whether a project was truly successful.
So how do we fix this? In a word, simplify! And here are some things to think about when slimming down your IT governance process:
- Reduce and align the number of gates to the number of “point-of-no-return” decisions on a project (e.g., business case, functional design, technical design, go-live).
- For each gate, focus on what kinds of decisions need to be made, guidance on people who should be involved, and some basic examples of information that should be provided as input. Let the smart people do what they’re being paid to do, which is talk it out and own the decision.
- Standardize only the mundane and highly repeatable decisions. Standards are about helping speed up the process and focusing the effort of only debating things that deserve to be debated. It’s not about compliance metrics and enforcement. If you have to put in an exception or exemption process, you’ve gone too far.
- Ensure communications on what the project will deliver in terms of functionality and value. Most stakeholders care a lot more about whether a particular feature set is being implemented for their users rather than whether a particular deliverable is green or yellow.
In the end, this is about creating a process that helps to focus people on the real objectives of the business and fostering communications. It’s about assuming that people are intelligent and reasonable and capable of making good decisions when given the opportunity. And if that turns out not to be the case, it’s a HR problem and not something that should be fixed with yet more governance processes.
SOA landscapes today look very much like fractals. An organization may have several internal capabilities presented as reusable services that connect to each other. It may even connect to 3rd party and/or cloud based services. But if you drill down into each of these services, you’ll likely see a composite application that is made up of several finer grained services interconnected together. And as a math geek, I am naturally curious about all things related to fractals.
In fact the fractal pattern appears in almost anything that’s responsible for connecting things together: highway and road systems, power grids, the internet… the list goes on. In all of these systems, there exists a hierarchical system of management and governance to regulate its functionality. Each country, for example, have national standards and regulatory bodies that define how power is to be exchanged, managed, and consumed. At the regional levels, there are additional standards and regulatory bodies that deal with region-specific decisions such as how much power to generate, pricing, and what equipment is to be installed where. Similar structures are true for transportation and telecommunications. So why is it that most organizations see SOA governance as an all-encompassing enterprise wide responsibility?
The interaction requirements and lifecycle characteristics of enterprise level composite services or business processes are very different from those of a utility service. To paint the entire enterprise service landscape with an uniform set of standards and processes will either result in a high number of exceptions or a lowest common denominator scenario. To be effective, an organization’s SOA governance model must match its SOA deployment model. The governance model must exist not just at the top, but at a granularity that matches how the services are being deployed and managed. Service Portfolio Managers, then are not just another role within the governance model, but micro versions of governance domains themselves. Service Portfolio Managers must be allowed to define their own standards and processes that are appropriate for the specific services that they’re responsible for. The SOA governance model for the enterprise must consider what standards and processes are appropriate for all services, which are appropriate for only the ones being consumed across the enterprise, and which ones should be left up to the Portfolios to govern themselves.
I know, at first glance it looks like the cramming together of 3 loosely defined and oft-debated buzzwords into the title, but got your attention didn’t it? So if you will bear with me for a few minutes, I will explain how applying Agile to a much more abstract of an activity such as building an SOA Governance Framework works.
SOA Governance is a fluid concept, with many differing, complementary, and overlapping point of views. Is it a framework focused on lifecycle management of service assets? How does it integrate with existing governance frameworks around other IT components such as infrastructure, database, packaged applications? Or should it be focused around the monitoring and management of business capabilities. The discussion could go on forever.
Because of this fluidity, I’ve seen two major problems come up again and again with clients when it comes to creating an SOA Governance Framework:
- The client has invested in a shiny new SOA Governance Framework complete with templates, registries and repositories, architectural review boards, the works. It takes a year to roll out. And the moment it’s done, people start finding scenarios that don’t fit within the framework; do not apply it consistently; or refuse to use it altogether.
- Various architects within the client organization can’t agree on the scope, focus, or business case around such an ambiguous concept as SOA Governance, so it keeps on getting pushed off.
The reason why the first problem occurs is that organizations are treating Governance like a traditional application build project. You need to define it all up front and build it once. And that can only lead to an SOA Governance Framework, or any Governance Framework for that matter, which is out-of-date before it’s even delivered. Governance needs to constantly evolve to adapt to the changes in an organization. Is the organization moving from being IT focused to being business focused? Is there an increased uptake in COTS implementations over custom development? Is the organization moving to an offshore support model? All of these changes in the organization will impact how the services should be governed. In short, the way the SOA Governance Framework is developed and managed over time needs to be flexible and adaptable to change. Sounds like Agile, doesn’t it?
The same general mentality also leads to the second problem: the idea that the SOA Governance Framework has to be perfect and all-encompassing the first time around. The fact of the matter is that instead of being stuck in analysis paralysis, we’re always better off with having something rather than nothing. Even an imperfectly managed SOA landscape is better than a completely unmanaged landscape. One of the key tenets of SOA is to enable continuous improvement of business capabilities and efficiency by building it out in loosely coupled modules. So why can’t we implement a SOA Governance Framework by starting small and building up additional components as we learn more about the landscape and become more experienced in working with it. Isn’t it better to solve a real problem that we encounter than to create a solution in anticipation of a problem? Once again, sounds a bit like Agile, doesn’t it?
That was a long preamble. So here’s our approach:
- Get the organization to agree on a core set of SOA Governance deliverables, creating a baseline of the framework. In Agile terms, this list is our backlog and includes:
– a Service Definition template
– a Service Contract template
– a Taxonomy
– a Service Registry and Repository
– and some kind of org chart from at least a support perspective
- For each deliverable defined in the backlog, analyze whether something similar already exists in the organization today or needs to be created. Group similar/relevant deliverables together (ie. Service Definition template with Service Contract template). Implement it and deliver it to the organization. These are our sprints.
- While operating our SOA landscape, constantly be on the lookout for areas to improve. Did we have any services that didn’t fit the definition template? Did we have a project that identified inefficiencies within the architectural review process? Is the service inventory becoming too cumbersome to manage? Are people adhering to the change management process and if not, why? Was there a re-org that requires us to rethink the key roles and responsibilities? Frame these into deliverables and put them into the backlog.
The key to success here is continuously looking at the applicability and appropriateness of the framework and keep it aligned to the rest of the organization. If the users of the framework start to feel like they have to shoehorn something into a structure that no longer works for them, they will cease to use it. So don’t fall into that trap and let’s apply some agility to our SOA Governance initiatives.