The Rule of EA Governance

There is a clear distinction between Enterprise Architecture, as described by the architect, and Enterprise Architecture as implemented by the enterprise.  I would like to posit the following as a fundamental principle that describes the difference:

All Enterprise Architecture will be implemented according to the structure of ownership and governance that exists in the enterprise.  

This is essentially an update to Conway’s Law, but Conway was focusing mostly on application development.  Conway’s law, dating from 1968, is:

^“...organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations. “

Many of the factors that drove Marvin Conway to describe software design are also at play in enterprise architecture.  Organizations want to use the teams that they have, so they will design software in such a way that it can be coded by those teams, regardless of whether that is the best way to design or deliver that system.  For example, if your company has a team of people who manage the CRM system, and a team that manages Web front-ends, then any business scenario that involves web front-ends on a CRM system will have exactly two modules.  One will be written by the Web-front end team and the other by the CRM team.

In Enterprise Architecture, the effect plays out quite differently.  EA often creates recommendations to consolidate systems, reduce overlaps, fill gaps, and optimize spending.  Since EA doesn’t design software, Conway’s law doesn’t apply. 

So how does the Rule of Governance work you ask?  If you have two business customers who both want a CRM solution, and you have one governance body, you will end up with one CRM system.  If you have two governance bodies, you will end up with two CRM systems.  If you have four business units who want CRM, and you have three governance bodies, you will end up with three CRM systems.

This rule plays out repeatedly.  I’ve never seen it fail. 

The failure to recognize “The Rule of EA Governance” is one of the causes for the failure of an EA program.  

Enterprise Architects are an optimistic bunch.  We honestly believe that we can influence the course of our businesses (evidence: we work as Enterprise Architects!).  We use modeling techniques and engineering principles, and produce nice drawings and great designs.  The business doesn’t care about nice drawings and great designs.  They care about “stuff they own” and “stuff they don’t own.” 

If you want to change the way the business works, especially with respect to shared processes, capabilities or technologies, an EA MUST create a mechanism for the shared “thing” to be owned by only one person.  As soon as only one person owns it, and has authority over it, it will exist only once.  If two people own it, it is a matter of time before they go their separate ways.  Of course, making sure that the RIGHT person owns it, that’s an altogether different problem.

So if you want to know if your Enterprise Architecture can be implemented, count the “things” in it.  Then count the number of those things with exactly one owner (and clear governance).  Those are the things that will be implemented just the way you describe it.  Everything else is a free for all.