Governance in an Organic Enterprise

By |2011-09-28T04:32:12+00:00September 28th, 2011|Enterprise Architecture|

I spent a few minutes this evening reading through Tom Graves’ fascinating post Management as ‘just another service’ and it got me thinking of Governance in the organic enterprise.

As Tom describes, there are two paradigms of management at play: organization as machine, and organization as living organism.  Tom is of the opinion that most organizations think that they are of the first type, while they actually behave like the second type.  While I cannot quantify his assertion, I have noticed that my own organization behaves more like an “organization as living organism.”

So, this evening, as I contemplate the notion of enterprise governance, I consider the reality of improving governance in an organization that behaves more as an organism than as a structured automaton.  In order to share my thoughts, I want to establish some basic terms to make sure we are all on the same page.

First off: Governance is a system of distributing decision rights to specific individuals or groups so that (a) desirable behavior is encouraged, (b) undesirable behavior is discouraged, and (c) business rules are aligned with enterprise principles and legislative constraints.  Governance can be a simple as having the project sponsor review the project plan, and as complicated as having the United States Supreme Court review the specific clauses of President Obama’s healthcare reform law, before the administration compels the various states to implement it.

There are many things that can be governed:  the scope of projects, the expected architectural outcomes, the assignment and activity of individuals, the assignment of responsibilities to teams and systems, the correct handling and security of information, and the measurable performance of processes, to name a few. 

In addition, there are many different levels at which governance occurs.  Governance can occur at the personal level (I choose to do the right thing).  It can also occur at any “level” where a group of people with specific decision rights have a stake in the governable elements of an activity.  To whit:

  • A team may want to govern the efforts of its members. 
  • A business sponsor may want to govern the activities of a project team that is spending his or her money. 
  • A cross-business virtual team (v-team) may want to insure that dependencies between teams are carefully managed in order to insure the delivery of value. 
  • A senior business executive may want to govern the level of acceptable risk in a portfolio of projects to insure that there is a good balance between innovation and incremental improvement. 
  • A senior leadership team may want to insure that leaders have clear ownership and accountability (no gaps or overlaps) so that strategic changes can be implemented in cross-functional processes.

This may lead you to conclude that governance can be performed as part of a hierarchical escalation process, but that is not a foregone conclusion, as you will see below.

When designing a system of governance in an organic enterprise, we need to make sure that the “solution” matches both the “problem” and the organizational “network of influence” (instead of hierarchy) that the enterprise uses to make decisions and resolve disputes. 

So let’s break down the problem a little.  What is the array of problems that organizational governance (of which IT governance is a subset) is supposed to solve?  Here are some elements of that array:

  • Senior leaders are consulted when the cost of day to day operations overwhelms the organization’s ability to behave strategically
  • Business Managers are consulted when investments by one business manager can interfere with the efforts of another
  • Process owners are consulted as a process is being changed, leveraging organizational knowledge and experience
  • Information facet owners are consulted as requirements emerge that impact master data management and data quality
  • Platform owners are consulted for the improvement of business capabilities supported by enterprise platforms
  • Architectural owners are consulted as system designs are considered for inclusion in the enterprise IT ecosystem
  • Organizational standards are followed in order to minimize the cost of ownership of process, system, information, and infrastructure investments


The key thing to note from this list is that different “governors” are interested in governing different things.  There is no simple “chain” of escalation.  Rather, it is a network.  This is one effect of organic governance.  Another is that the number of levels of governance, for any one issue, should be fairly short.  You deal with things at an individual level, at a project level, and then, fairly quickly, at the level of a “governance body” designed specifically to resolve that particular type of issue for a business and then the enterprise.  Lastly, there is a senior management body that can settle all remaining disputes. 

Unfortunately, when considering this kind of problem, the metaphor of “enterprise as organism” begins to fail.  Actors in an enterprise do not behave like cells in an organism, nor do business units within an enterprise behave like organs.  Cells are regulated by internal instructions, hard-coded in chemical DNA sequences, and respond to fairly simple stimuli with pre-programmed responses.  Actors and business units do not. 

Organizations do not have consistent and uniform instructions (like DNA) that guide each person and business unit.  Governance is needed because of the variation of human beings and their desire to continuously look after their own interests.  Quickly we can see that the “organism” metaphor is shaky at best.  In small units, the metaphor of a sports team is a better metaphor, and at the larger end, the metaphor of a city is more appropriate.

I work in a fairly large company, so the metaphor of a city is better for me to consider.  After all, I’ve lived in cities all my life.  So in a city, how many times have I behaved in a beneficial way?  I’d like to believe that I do that every single day, in a hundred small ways.  How many times have I interacted with the police?  Less than the fingers on one hand.  Well… that’s interesting.  That simple observation alone makes one thing starkly clear: the police do not govern my city life.

I believe that the most important governance element of city life is the system of property laws, commercial practices, licensing laws, and simple rules of civil behavior that allow the city to be a productive and useful environment for individual people.  Governance itself is a tiny fraction of the overall efforts of the population of a city, and it is normal to live your life for years without involving a police officer, filing a law suit, or walking into a court.  That said, courts and lawyers and legislative bodies are essential overhead.  From an economic standpoint, governance is overhead and waste.  People who govern contribute nothing.  But from a social standpoint, the system of governance is critical to the success of the “organically” managed city. 

Which leads me to a rather startling conclusion: In order for a large organization (of say 100,000 employees) to successfully becoming a mega organization (of say 1,000,000 employees), they must develop a simple and fair system of property laws, commercial practices, licensing laws, and rules of civil behavior, and a simple adjudication system to address conflicts.  Hierarchy do
es not work as a model of governance in an organic enterprise.

When IT Architects Describe EA to other IT Architects

By |2011-09-02T09:53:24+00:00September 2nd, 2011|Enterprise Architecture|

Sometimes, I have a hard time being upbeat about the emergence of EA as a profession.  This felling is especially acute when I come across a slick, well-prepared guide to Enterprise Architecture, written by an IT Architect, that is incomplete, inaccurate and/or misleading.  That happened to me today.

The guide is written by Wolfgang Keller and was published in its final form in November of 2009.  His guide is titled “TOGAF 9 Quick Start Guide for Enterprise Architects.”  The document can be found here

Most Enterprise Architects have their roots in IT organizations, and there is a great deal of interest in both the role of EA and the TOGAF framework’s stated goal of becoming a framework useful for Enterprise Architecture.  That said, most practicing Enterprise Architects have some level of difficulty applying the TOGAF to their work, largely because it is a guide to producing Enterprise IT Architecture (EITA) artifacts, and not EA artifacts.  One such architect, Adrian Grigoriu, writes about his experience applying TOGAF to EA in his blog (link). 

EITA is to EA what a Biologist is to a Physician… a respected colleague with a similar area of concern, but totally different role.  Since TOGAF is a framework for EITA, it can be tough to expect an EA to use it.  Now, I know that the Open Group is making progress, and I have acknowledged that progress in past posts.  But let’s face it: TOGAF is about 20% there.  It is not wrong… just wildly incomplete.  Learning TOGAF to do EA is like learning to fly a business jet in order to take on combat missions in an F16.  The skills you’d gain are somewhat useful, but not even close to being sufficient.

So when I opened up Keller’s guide, I expected to see some tables showing typical scenarios for an Enterprise Architect, the ways in which a framework can support EA, and an indication of the gaps that TOGAF still has in providing that support.   That is not what I found, and I’m not happy with what I saw.

  1. First: it was not written by an EA or even listing EAs as contributors. There is no indication whatsoever that the author actually has ever worked as an EA. It would be like a nurse writing a guide to the Physicians Desk Reference.  Worse, “experienced” Enterprise Architects are supposed to use this.  What does it say about the student if he chooses a fool as his teacher? 
  2. Second: The author describes Enterprise IT Architecture, not Enterprise Architecture. He doesn’t know, nor has he taken the time to find out, what an Enterprise Architect actually does. It is one thing to be speaking outside one’s area. It is another to describe the role in completely inaccurate terms.
  3. Third: The author, while attempting to describe the much more limited role of EITA, gets that wrong as well. The author has placed the role of EITA in an untenable and ineffective position with no authority (or even role) in program portfolio prioritization and funding. If that were my job as an EITA, I’d quit.  I have seen EITA’s struggle and fail, time and time again, in this role.  This makes the guide not only a bad way to access TOGAF, but also provides some elements of seriously bad advice for any IT architect.
  4. Fourth: His document misrepresents itself.  Only about one third of it is a guide to using TOGAF.  There are two other parts.  One is a description of software architecture (including a history lesson), and the final third is a supplement that attempts to fill in some perceived gaps in TOGAF. He attempts to address two specific gaps: Formulation of IT Strategy, and IT Portfolio Management. He makes an attempt in both cases, and I will credit him for the effort.  The output is average.  Were TOGAF to include his supplement sections, it would be helpful to a small number of EITA’s, but not any EA’s that I know.   

There are two use cases for reading the document, outlined by the author: (a) An Experience EA wanting to understand TOGAF, and (b) A Student wanting to learn EA and TOGAF.  For both cases, the guide fails to be practical and, in many ways, is actually harmful.  I cannot recommend this document for either case.

Of course, that means that there is still an opportunity for an actual Enterprise Architect to do what Adrian tries to do, and provide insight into how TOGAF can be used to in the practice of Enterprise Architecture. 

If you know of one… please let me know.  If you develop one, I’ll be happy to review it.  (If you’d like my feedback to be private, let me know before you publish it and I will do what I can to provide feedback in a timely fashion.  Once it is published, my feedback on the published version will be public as well.) 

Technorati Tags: