Governance is a fundamental (perhaps the fundamental) process within EA to connect the business aspirations with the current and future enterprise reality. Governance is probably also the most contentious EA process: a necessary evil at best or a dysfunctional rubber stamp or change-prevention mechanism at worst. The current focus on enterprise agility provides a context for refining governance. The conclusion is not to throw out governance or to diminish EA to a laissez-faire view of awareness and simplistic control of the enterprise. Rather, the conclusion is that governance can be made effective, compelling, and a value-add to agility.
Part of the complexity with governance is that it varies widely and is a tradeoff of constraints and flexibilities. The telecom industry in the early 1990s illustrates one view of governance. This was a time of great expansion of ideas/capabilities (e.g., cell phones, network features such as voicemail, data transport in addition to voice) but also a time of great constraint (50% of customers did not even have touch-tone phones — remember those circular dial faces!, and the connections were twisted-pair copper wires, not higher performance wires, cables, or fibers). At that time, the enterprise architecture — the way calls were switched, the way signals were sampled and processed by software, the way endpoint devices (phones) worked, and so on — was a set of relatively immovable constraints. This is not to say that the role of architecture (and the architects) was to limit innovation, but rather help “engineer” tradeoffs based on the current reality to encourage workable innovation and delivery. There was no doubt, though, that governance was there to enforce architectural constraints, and that the flexibilities were limited to understanding what those constraints did and didn’t mean. Outcomes included ways to deliver network services, such as caller ID, call waiting, network voicemail, and so on, to subscribers that had the most basic handsets and far-reaching features like “number portability” (the precursor to today’s ability to migrate phone numbers from landlines to cell phones or between providers). There were disruptive transitions, such as adding area codes or splitting them, that needed to be managed.
Another view of governance is that it manages the roadmap from the “as is” to “to be” architectures. The nature of the concerns can range from explicit transitions (e.g., moving from one document management solution to another) to abstract goals (e.g., adoption of XML, SOA, or REST) to operational concerns (e.g., the JDK version or App Server version used for implementation). In this view of governance, the architectural transition is driving the change, and the enterprise is shifting from a state of compliance with one set of standards to compliance with another set of standards. An audit function is performed to evaluate if each project/delivery is to either be part of the status quo or part of the managed change. This audit often occurs so late in the process that there is not much that can be done if the answer is other than what is expected. The audit and the mandate for compliance may occur at an idea level, not based on an integrated end-to-end capability that involves the details of how the transition was applied.
Enterprise governance ultimately provides answers to the following questions, and the considerations for how to answer them in an agile enterprise are significant:
- What third-party technologies are we using across the enterprise, and is that consistent with what we want to be using (vendor, version, licensing, migrations, policies on open source usage)? Agile methods use the term “situational awareness” as necessary to understand how a project is doing so that next steps can be evaluated. Governance provides an enterprise-level situational awareness.
- What are the third-party technologies being used on a given project, and are those from the approved list of technologies (including transitions)? The system-level projects may or may not be able to avail of the full set of options (i.e., variants) within the enterprise, so there is a fit-for-purpose analysis that is made. In the agile development process, that purpose and fit may emerge rather than be planned and this will need to be addressed with governance.
- When have technology choices changed on a project/system, what are those changes, and are those changes expected/approved? This is similar to the above, but emphasizes that much of the desire/need for technology transition is discovered at the systems project level. There are big ideas that might be able to flow from top down (e.g., adopt messaging over remote procedure call (RPC), or adopt document management over file storage), but within those large domains, the discovery of what works and doesn’t comes from the projects. Governance needs to be aware of these transitions, allowing for a managed, bottom-up innovation.
- What are the internal supplier-consumer (integration) relationships between projects/systems? Governance is not just about technology usage within a system, but also integration between systems. Integration has a technology underpinning, but the more significant concerns are at the level of interface models, data exchange models, and the ability to test system-of-systems integrations for functional, nonfunctional, and error-handling issues. Agile development emphasizes a continuous integration approach that necessities an integration environment that is always available (to each system/project), always up to date (and able to be moved to different dated revisions easily), and supports automated testing. But these responsibilities to the system-of-systems integration are, by their nature, bigger than any one system, and hence effective governance can make this workable and efficient.
- Are the third-party technology and integration choices across projects/systems compatible (note: this does not need to mean identical)? The key is compatibility, not conformity. This is a transition in the governance approach for standardization but appeals to the sense that “one size does not fit all,” and what organizations really need is a way to realize that objective in a way that supports agility without leading to chaos.