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.

By Nick Malik

Former CIO and present Strategic Architect, Nick Malik is a Seattle based business and technology advisor with over 30 years of professional experience in management, systems, and technology. He is the co-author of the influential paper "Perspectives on Enterprise Architecture" with Dr. Brian Cameron that effectively defined modern Enterprise Architecture practices, and he is frequent speaker at public gatherings on Enterprise Architecture and related topics. He coauthored a book on Visual Storytelling with Martin Sykes and Mark West titled "Stories That Move Mountains".

4 thoughts on “Governance in an Organic Enterprise”
  1. Many thanks indeed for this, Nick – much appreciated!

    If I may, though, I'd like to pick up on one theme, and what seem to be a couple of rather odd sideways-jumps.

    The theme is about rights versus responsibilities. I'm well aware that this can be a 'red-rag' issues for many people (especially in the US), but I don't think 'rights' is a useful lens to apply here. For example, interactions between services run on mutual-responsibilities; if we introduce notions of 'rights' into the mix, it soon becomes hopelessly misleading and confused. Since in a functional sense 'rights' are actually an outcome of mutually-interlocking responsibilities, it actually makes it much easier if we drop any notion of 'rights' from the analysis, and instead focus solely on the mutual-responsibilities from which those nominal 'rights' arise.

    For example, you talk above about a governance-mechanism that 'distributes decision-rights'. Yet in terms of the organisational function of that governance, what we're _actually_ concerned about is not the 'rights', but the quality of the resultant decisions. We want to be (reasonably) certain that the person to whom the 'decision-rights' are assigned has the ability to make competent and appropriate decisions in the context – what we might describe as the required 'response-ability'. Notions of 'rights' usually end up being a disruptive and pointless red-herring in this kind of analysis: it really is a lot simpler to drop the whole concept entirely. Tricky, I know, especially in the US: but we can do it simply by forgetting to mention them… 🙂

    Something for a longer discussion somewhen, I think? Architecturally speaking, though, it's actually a lot more important than it may seem at first sight: it's something that collectively we _do_ need to explore in a lot more depth in the future, especially as enterprise-architecture necessarily expands its scope from IT-only to the whole business and beyond.

    The 'sideways-jumps' were all about how you've handled the metaphor of 'organisation as organism': you seem to be agreeing with it at some points, and rejecting it at others, often apparently for the same reasons for either choice. So I'll admit I'm a bit confused…

    The main point I noticed is that you seem to have constrained your definition of 'organism' solely to something quite small: down at the cell-level, where there are only simple instructions, and so on. What I'd suggest is to remember that _you_ are an 'organism'; the overall set of signals and instructions running through your body can be very complex indeed, using a range of different mechanisms – physical (joint-range), chemical (digestion, hormones), electrical (nerves) and so on. The same applies when we move up the scale to a work-team, a business-unit, a division, a corporation, a city, a multinational: they each have complex structures that can be described in terms of service-relationships, a wide variety of signalling- and 'control'-mechanisms (and often multiple-pathways for each), a range of network-effects and emergent-properties, and often decidedly-unpredictable outcomes. That's radically different from organisation-as-machine, where the whole focus, and every assumption, is around predictability and certainty. Both views are valid: but don't mix them up randomly as you go along! 🙂

    Once again, though, many thanks for exploring this further in the way that you have – it really does help!

  2. Hi Tom,

    I'm really glad you managed to get past the bugs in this goofy blog software and get your comment posted.  As always, your comments add great value and I appreciate the time and attention you paid to my humble article.

    You did make one comment that I'd like to expand upon.  In your concern about "rights" vs. "responsibilities", you stated a presumed goal: "We want to be (reasonably) certain that the person to whom the 'decision-rights' are assigned has the ability to make competent and appropriate decisions in the context – what we might describe as the required 'response-ability'."

    From a purely social standpoint, and if the world were a meritocracy, I would agree with you.  I do want to make sure that the person who is in charge of making a particular decision is both competent and "up to speed" on the issue at hand.  However, EA is also a political art.  Where a decision responsibility becomes a decision "right" is in the realm of trust, not the realm of competence.

    Trust is not a state.  Trust is a vector.  It represents a one-way-relationship.  From an organizational standpoint, I choose to describe trust as either "ascending", "descending", or "horizontal peer."

    The easy one is for a horizontal peer.  I can trust a peer to decide an issue if I actually own a decision but wish to seek the opinion of a trusted partner.  Of the three types, this is the only one where I own the decision but choose to extend it to another.  In both of the other two types, someone else owns the decision.  The relationship "ascending" or "descending" is used to describe the manner in which I come about trusting that other person to make their decision.

    I can trust a senior manager or executive in a particular division, based on their experience and known accountabilities.  That is ascending (trust coming from the bottom, me, to the top, the person whom I'm trusting).  This can be direct (I trust that person) or indirect (I trust my superior, who trusts that person).  

    The descending form of trust is as important.  In this mechanism, large organizations are partitioned up into the "kingdoms" of various empowered individuals, each of whom repeat this pattern, choosing to trust their "inferiors" until most major decisions are made in the narrowest possible context.  Trust descends from the CEO, who trusts the divisional presidents, to the corporate VPs who are held accountable for specific business goals, and on down the stack to General managers who hold the lowest level of P&L accountability.  This is "descending" trust.

    To support an ascending trust model, we have only to find the most appropriate person to make a decision.  That would fit your comment about "rights" vs. "responsibility."  However, to support the descending trust model, we have to make sure that the person that the executive looks to, for addressing a particular problem, is the person that is making the decision.  Any other decision maker can have his or her decisions reversed in a heartbeat, without warning, and often with unpredictable consequences.

    In an early-21st-century organic organization, BOTH trust models are at play.  Therefore, we must not only identify the most appropriate person, but also the _officially_ appropropriate person.  They may be different.  The former can have the responsibility, but he latter holds the "right" to make a particular decision.  That is the only person who gets to own the decision, and claims the consequences (both good and bad) that arise from it.  That is the person who cannot be excluded from the decision, and whose word carries executive buy-in, and therefore, stickiness.  

    Decisions must be sticky.  If a systematic change is implemented on the basis of a decision that is quickly reversed, chaos ensues.  I've seen this happen.  It is NOT pretty.

    So, I stand by the decision to use the term "decision rights" because, at the end of the day, the stickiness of the decision is as important as the competence of the decision maker (if not more so).  That is the nature of politics.  I can sway, or educate, an incompetent manager, but there is no way to recover from a decision being made by the wrong person.

    Identifying the right person… fodder for another blog entry 🙂

    — Nick

  3. Hi Tom,

    As for the organism metaphor, I did reference the notion of organs, not just cells.  

    That said, I agree that there needs to be a better metaphor than "machine."  We don't follow orders, and we do self-form, and we do respond in complex manners, and we do offer services… so the "machine" metaphor is clearly broken.  We agree.

    However, the organism metaphor is not working for me either.  We don't have internal instructions driving individual actors, and we do have the ability to change and reshape our services (a kidney cannot decide, on its own, to perform a different function than it was programmed to perform).  In fact, we are required to respond in "self-organizing" ways, much more like a colony of individuals and less like a single organism.

    That is why I prefer the metaphors of community over the metaphor of organism.  A community can change how it is organized.  An organism cannot.

    I point out that there are many metaphors of community.  At the low end, a team is a good metaphor of community.  At the larger end of the scale, a city is a good metaphor.  Which metaphor to use depends on the context.  

    I apologize for creating confusion by appearing to agree, and then disagree.  I hope this response clarifies… I agree that "machine" is a broken metaphor, but disagree that "organism" is a satisfying alternative, preferring "community" in its stead.

    Once again, I really appreciate that you challenged me as you have to consider these ideas more deeply.  It is in an environment of mutual exchange of interesting ideas that I find the greatest opportunity for the growth of my own skills and perspective.

    — Nick

  4. Nick – The statement about "trust is a vector" is truly brilliant, and a great description too of the system-as-is. There's only one problem, but it's a huge one: _there is no vertical dimension to trust_. It's a delusion. And any system that incorporates that delusion is _guaranteed_ to be seriously dysfunctional, eventually to the point of total failure of trust.

    There's no question at all that – exactly as you describe – your 'as-is' structure is riddled with that delusion. And hence – as you also exactly describe – that almost everything about the would-be workings of that system is, in practice, a dysfunctional mess. No-one should be surprised at this: it's inherent in the structure – not the people as such – and it's what that type of structure has always done and no doubt always will.

    Trust is _human_: it only exists between peers – in other words, is _only_ 'horizontal'. The 'vertical' dimension you describe is actually about purported-'right-to-control-others' – which is almost the exact antithesis of trust. It purports to be trust – "I trust you as my inferior to do this act of fealty to me" – but in a very literal sense it's about attempted subjugation, the _suppression_ of the individuality and choice of 'the Other'.

    That's the 'downward' vector. The 'upward' vector is slightly different – "I trust you as my superior not to punish me if I do as you ask" – but the overall effect is much the same. To be blunt, it's the pseudo-'trust' of a 'protection-racket'.

    So the effective function of the what you've described as the 'vertical' dimension of trust is actually to _destroy_ trust. Hence I'd suggest it's not a good idea to call it 'trust'…

    So if you want a structure that _does_ actually work, your 'to-be' architecture _must_ remove any notion of a 'vertical' dimension to trust. Which, yes, is going to be kinda tricky to implement in a culture that's riddled throughout with delusions of verticality…

    But that _is_ the only 'to-be' architecture that will work – and I think you know that? And I'm pretty darn sure that just about everyone else knows it too? (Take a look at what happens at the collapse of a police-state: before the collapse, everyone says they believe in the Great Leader or whatever – no-one dares say to anyone else what they _actually_ believe, for fear from the omnipresent informers. When the police-state is demolished, it's always kind of a shock to discover that just about no-one else had believed in the Great Leader either…)

    So: you're in the unjoyous situation where your architecture-client is demanding something that you and pretty much everyone else knows won't work, on a pretty enormous scale. Sigh… "oh no, not again…"

    But the point is that it _is_ "oh no, not again…": _it's not a new problem_. We have to ride with it: in this kind of dysfunctional context, when the client says "jump", we have to jump. I'm not questioning that. What I _am_ questioning is the all-too-common tendency to pretend that it isn't a problem: because apart from anything else, that kind of pretence would be a _serious_ breach of professional ethics. But _we do already have a mechanism to deal with this_: the architecture-waiver, or architecture-dispensation.

    We use a waiver to record any aspect of a 'solution' that doesn't line up with our current architectural principles. Within the waiver process, we identify the details of the risk, how and why the risk has been incurred and can't be avoided, the probable impact of the risk, and the options for remediation of the risk. In this case, the details are that we're required to incorporate a trust-structure that inherently destroys trust; it's being imposed for cultural reasons; the probable impact is serious organisational-dysfunction with a significant risk of total organisational failure; and at present we are not allowed any means to mitigate that risk. _And that goes into the risk register_: even if we can't deal with it ourselves, at least we've made it clear that it _is_ a real risk, and one that that needs to be addressed as soon as any opportunity to do so would arise. That's probable all that you can do at present: but at least you've done _something_ to enact your professional responsibility in that context.

    And yes, as time goes on, you'll see a _lot_ of those specific waivers building up in the risk-register. Scary, isn't it? 😐

Leave a Reply

Your email address will not be published. Required fields are marked *

1 × 3 =

This site uses Akismet to reduce spam. Learn how your comment data is processed.