Mar 132012

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.


  5 Responses to “Enterprise Architecture Governance”

  1. While your post discusses governance of EA, which is, of course, important, it is also important to consider the place of EA in overall enterprise governance.

    Governance is about what decisions need to be made, who gets to make them, how they are made and the supporting management processes, structures, information and tools to ensure that it is effectively implemented, complied with, and is achieving the desired levels of performance. When thinking about governance of investments in IT-enabled change, and the decisions that need to be made around those investments, governance is essentially about (continually) asking four questions – the four “ares” that I introduced in my book The Information Paradox. These questions are:

    1. Are we doing the right things?
    2. Are we doing them the right way?
    3. Are we getting them done well?
    4. Are we getting the benefits?

    In the context of IT-enabled change, EA (and by EA I mean the broader business view of EA, of which technology is only a part) is a key discipline to support answering these questions. While most attention is focused on “Are 2” the architecture question, and ” Are #3″, the delivery question, EA also plays a key role in “Are 1”, the strategy question. My view of strategy is that it is about understanding, configuring and managing assets to deliver the greatest value. And it is not generally the individual assets that contribute value, rather the relationships between them that, if managed right, create value, but if not understood, can equally erode or destroy value. This is where EA comes in, supporting the development and execution of strategy by providing an understanding of, communicating and managing the fundamental underlying design of the components of the business system, the relationships between them, and the manner in which they support the enterprise’s objectives.

    You can find more about my thinking around governance, and the role of EA in a recent post about, what I refer to as, Strategic Enterprise Governance,

  2. Can Agility and EA practice co-exist?

    The biggest challenge to make them co-exist is:
    – the incompatible vocabulary used by agilist and EA
    – the difference in the mindset between the two groups

    On the whole, they do not understand each other!

  3. avatar

    A good discussion, however there are many other aspects to governance than 3rd party vendors. It is also related to the processes of defining and enforcing the EA.

  4. EA proberly has one of the best records on spending money on governance, while stopping and/or killing business initiatives, even better than the feared IT security, since they at least come up with alternatives.
    I would sugest that EA governance in the future concentrates on mitigation to bad attitudes and will be managed as all best practise risk management functions, as at the the end EA governance is nothing else than a technical risk management.

  5. SOA adoption can be challenging due to the complexity of SOA initiatives and the amount of organizational change that accompanies successful SOA adoption. In fact, our experience shows that when SOA adoption is slowing or failing, it occurs during specific steps in the SOA adoption lifecycle that are especially prone to failure.

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>