Our language can limit us.  Our words can prevent us from thinking about our world in a clear way.  This article is about freedom from our own words.  Read at your own risk.

Enterprise Architects like to describe a view on a system of interest in terms of “current state” and “future state.”  Sometimes, there are a succession of intentional states, and we will use the label “intermediate state” to refer to the system as we change it along the way.  This is a very intentional kind of thinking.  As in: we intend the organization to change in this manner, and in this sequence.

The word “architecture” aligns to this kind of thinking, as does the word “engineering.”  With either word, we reference the things we create.  Systems of movement or interaction like a steampunk robot with wheels and gears and spinning motors.  Our robots of enterprise.  And that makes us the Gods of the Robot.  We are the mechanical engineers who draw grand diagrams of motors and frames and appendages like the great factory designers of the early industrial revolution.

However, Enterprise Architects need to break free of this kind of thinking.  I cannot stress this enough.  Enterprise Architecture is not mechanical and it is not physical.  We don’t build an enterprise the same way that we build a highway overpass and exchange.  We do not pour “enterprise concrete.”

Enterprise Architecture is sociological, biological, linguistic, and metaphysical.  For us to draw a “current state diagram” of an enterprise, we are describing elements in our “systems diagram” that represent not only individual people, but groups of people operating in a cultural environment with common beliefs and usually a common language within the group.  In my past models, I’ve glossed over these aspects, and I now feel that is not only a mistake, it is a fatal flaw.

While most systems need a designer, an enterprise can form, and reform, itself.  In fact, that is the primary mechanism by which enterprises grow: through self organization.  We talk about “organic” architecture, but have we really considered the mechanisms of self organization and growth within the community of self-organizing teams that makes up an enterprise?

Ways in which an enterprise can self organize:

• mutation  – we hire a new person, or install a new technology or just want to try a new idea about how to organize our behavior or our systems.  Those ideas create mutations – variations in the architecture of an organization that are not designed.  We try them out.  Sometimes, the work and we keep them.  Sometimes, they work and we destroy them.  Sometimes, they fail utterly and we keep them.  Sometimes they stay hidden in a corner, lurking.  Waiting to impact the organization in some way in the future.  These changes are not on the current state or future state architecture.  Yet they are the most common way that enterprises change.
• natural selection – two teams create competing products, or a company buys a competitor, and suddenly you have a situation where the success of one part of the company necessarily implies the demise of another.  Even when the products don’t directly compete, there can be some internal tension between teams with similar skills or training.  The most effective team may “win” for a while in the eyes of management.  They may produce results that are better suited for their environment than another team or they may simply appear more successful on a valued measure of performance.  This is an extraordinarily common mechanism by which the architecture of an enterprise changes.  It is nearly never designed that way.
• principle driven self alteration – Enterprise Architects love this one.  Most models of business, from balanced scorecards to the BMM to the EBMM to the Business Model Canvas include some mechanism for describing how a vision or mission or principles will produce results in an organization.  But who makes those changes?  Certainly not the enterprise architect.  Organizations and individuals will self-organize around mission and principles.  This extraordinarily powerful mechanism drives all kinds of behavior, good and bad.  It is dynamic.  It is immediate.  It doesn’t show up on an EA model.
• goal oriented self organizing behavior — Enterprise Architects often refer to goals and measures but rarely capture the dynamic aspects of behavior that emerge from goals and measures.  People will do what you pay them to do, and in most companies, there is some form of measure mechanism between their perceived performance and some component of their compensation.  (Compensation being a general term that includes financial rewards as well as recognition, self expansion, and sense of contribution).  But do we recognize that creating goals and measures changes the enterprise architecture in ways that we neither predict nor control?
• repair to damage or injury — Enterprise Architects are often surprised by changes in business just like anyone else in an enterprise may be.  A merger or divestiture is rarely part of a future state architecture.  However, when an organization undergoes forced surgery, it reacts like an organism that has suffered an injury.  There are unintended losses of information and people.  There are efforts made to stop those losses and return the organization to homeostasis.  There are changes in team structures, communication flows, processes, and information systems.  There are impacts on the overall health of the organization, even if the injury is localized.  All of these reactions are organic and from the perspective of the enterprise, follow the classic signs of healing after an injury.  And not one appears on the “future state architecture.”
• fight or flight response — An organization can become frightened and defensive.  Don’t believe me?  Look at Borland after it started to realize that the company had lost the “programming language wars” of the early 1990’s.  Or ColdFusion after it lost the “web language wars” that followed.  Or Netscape.  Or, even to a lesser extent, Microsoft.  Competition is not easy and sometimes your team is stressed.  You can see the future and it is bleak.  The organization goes into a form of shock.  Decisions are made more slowly and less boldly.  Key staff leaves, and processes are simplified in ways that serve short term needs.  The organization is responding to stress using the same biological mechanism that humans do: fight or flight.  This response is not just triggered by competition.  It can be triggered by regulation, sudden shifts in the environment, and increasingly climate change.  The future state of the organization nearly never captures the impacts of fear.
• oscillation — Too much of a good thing is a bad thing.  Some strategies can create oscillating effects. In many ways, we realize it but we rarely acknowledge it on an EA model.  For example, I have watched as the IT department of a large organization went from a single monolith to a distributed IT structure, back to a central structure, and swinging back to a more distributed model over the course of many years.  Similarly, a wise analyst explained to me just yesterday how she’d seen her company of 20 years oscillate between different forms of data governance, from centralized management to no management at all.  These oscillations are normal and in many ways, predictable.  So why are they not on the Enterprise Architecture model?  Because they are not intentional.
• self spacing territorialism — How many times have you worked with a team where they did their level best to define their deliverables not in terms of what they do, but in terms of what no one else does?  It’s something of a common business practice to define your unique value, but this behavior is different because it doesn’t seek differentiation, but rather distinction.  “We offer a distinct offering, and we don’t overlap.”  This is the kind of self organization that produces a murmuration (a swarm of birds flying in an undulating pattern, each simply charting their course relative to the birds that surround it).  In an organization, an Enterprise Architecture team may define itself by saying “we don’t create program charters because the program management team does that, and we don’t produce system designs because the solution architecture team does that.”  That is self-spacing.  Follow that with “we produce roadmaps and no one else is allowed to produce roadmaps but us,” and you get territorialism.  The two nearly always occur together.

That brings me to the painful conclusion.  While the list above is assuredly incomplete, it should be a clarion bell to any architect who drinks their own lemonaid and believes that an enterprise is a construct.  It is not.  An enterprise is a community of organic elements, each of which change and grow according to organic principles.  Some of the observable patterns are listed above.  None of these are “intentional” in any sense of “future state architecture” yet all of them impact the future state of the architecture of our enterprise.

Somewhere deeper in all this is the question: what is the value of modeling the future of the enterprise architecture if our guesses are missing so many of the influences that actually drive enterprise structure and behavior?

Today… I do not know.  A valued colleague Bruce McNaughton chatted with me offline about some ideas, and his deep thinking triggered this article.  I am grateful for the stimulation of working on ideas with brilliant people.  I’m blessed to know a handful.  Thank you Bruce.