Enterprise Architecture, Chaos Theory, Governance, Policy Management, and Mission Alignment

Chaos and Organizational Process Friction
The first paragraph of the article on Chaos Theory found in Wikipedia sums up the theory quite well:

"Chaos theory is a field of study in applied mathematics, with applications in several disciplines including physics, economics, biology, and philosophy. Chaos theory studies the behavior of dynamical systems that are highly sensitive to initial conditions; an effect which is popularly referred to as the butterfly effect. Small differences in initial conditions (such as those due to rounding errors in numerical computation) yield widely diverging outcomes for chaotic systems, rendering long-term prediction impossible in general.^[1] This happens even though these systems are deterministic, meaning that their future behavior is fully determined by their initial conditions, with no random elements involved.^[2] In other words, the deterministic nature of these systems does not make them predictable.^[3][4] This behavior is known as deterministic chaos, or simply chaos."

Notice that the definition emphasizes formal, deterministic systems.  These are systems that have a functional design (or system architecture).  Unfortunately, most organizations (both private and public) do not have deterministic control function or systems (see my post IDEF0 Model and the Organizational Economic Model for a description of the control function), so the amount of chaos is much greater than necessary.  In this case, the chaos creates intra-organizational friction.  This type of friction is akin to having junior officers misinterpret orders (in some cases to the advantage of the junior officer), march down the wrong road in the wrong direction, and so on.  Often, the result is a lost battle, a friendly fire incident, or some other disaster.

However, even in military organizations have their "peace time" control/process friction issues.  In history there are many examples.  Here is one taken from mid-year 1941.  This was just prior to the start of WWII.  In his book, General of the Army: George C. Marshall, Soldier and Statesman, Ed Cray Writes:

"For all his acumen, Marshall had not yet grasped the sheer complexity of the army he was resuscitating, nor how large it would grow if the United States declared war.  Another member of the secretariat, Omar Bradley, noted, 'I often shudder at some of the antiquated percepts that underlay our thinking.  The quaintest by far was the notion that after we had trained a force of four field armies (over a million soldiers), Marshall himself would lead it, perhaps to Europe, as Pershing had led the American Expeditionary Force to France in 1917.'  For eighteen months the General Headquarters of this putative expeditionary force duplicated the efforts of planners in the Munitions Building, snarling authority and communication into a grand bureaucratic tangle."  

The portions I've underlined of this quotation indicate four types of intra-organizational friction (there are many more) and the result--"a grand bureaucratic tangle." There are many more causes for organizational friction, and the results of this friction are decreased effectiveness of the organization's strategies in achieving the mission, decrease effectiveness of the processes in enabling and supporting the organization's strategies, and a decrease of cost efficiency for the processes and enabling and supporting tooling--none of which is good from the perspective of all the process stakeholders.

Among the worst cases of process friction are large, supposedly integrated, organizations created by mergers and acquisitions.  The vast major of the time mergers and acquisitions of two large organizations ends up with one of three results.

1. The managers, culture, processes, and tooling of one organization come to dominate the entire organization.  This has the unfortunate result that there is a major drop in the morale of the personnel of the dominated organization, which in itself will cause a major increase in intra-organizational friction, but additionally, the transition to new processes and systems causes a great deal of additional process friction, and finally, the learning curve of the personnel and operations of the dominated organization will cause significant process friction that I've seen results in many of the best and brightest personnel to leave--greatly reducing the value of the operations of the dominated organization.  These include the dominated organization's transformational managers and skilled personnel, the ones that produce future value.
2. Two sets of managers, cultures, processes, and tooling, one from each organization are used concurrently.  With respect to process and tooling, this result keeps the process effectiveness of both organizations prior to the merger in place.  Consequently, the new organization will need to enable two potentially redundant sets of processes and support two redundant sets of tools.  This may be fine in the case of a "holding company", that is, an organization that owns many divergent sub-organizations.  The reason is that the processes and tooling is (or can be) tailored for the requirements of that industry - requirements that come from the standards and policies set within the particular industry (for example, the type of geometry used to depict components).  However, if these organizations produce goods and services within the same industrial category, then, from the perspective of cost efficiency, a single process and tool set make more sense.  I'm familiar with one case where through mergers and acquisitions the merged organization ended up with 45 or more separate accounting and payroll processes and systems.  Since both accounting and payroll processes are not tied directly to the production of the good or service, and since each of these 45+ systems requires separate operations and maintenance, this really makes no sense at all; instead, consolidation of these systems makes sense.  Still, this is what can happen in a situation where the result is maintaining multiple strategies, processes, and tooling within merged organizations in generally the same industry.
3. Finance Engineers take over.  In this case, both sets of vision, mission, strategies, processes, and tooling is decimated and replaced by the vision and mission of "increasing shareholder value", which is shorthand for "taking as much value out of the organization, while putting as little as possible in."  This puts the combined organization on the "going out of business curve."  There are two reasons.  First is "The Borg Syndrome", that is, "Resistance is futile, you, too, will be assimilated."  The "Finance Engineering Department", from the CFO on down--and including all transactional managers in both organizations--set a new vision and mission to increase cost efficiency.  This mission is the same one that the farmer in the story of the dairy framer had.  As the story goes, "A dairy farmer, who was a good financial engineer noticed that his feed costs were the highest variable costs.  Therefore, he decided to reduce the amount of feed to determine what happened to milk production.  To his edification, he found very little.  Consequently, he continued to reduce the amount of feed.  However, when he reduced it to zero, all the cows died."  In today's economy, "the traders" of Wall St., and all organization's based on the mission of "increasing shareholder value" are identical with the farmer.  When "the number are made" the transactional managers get paid large bonuses.  When it looks like the organization "will not make its numbers" the CFO declares war on the "cow feed" or the "seed corn."  Suddenly there is a great reduction in funding of all research and development--but especially that for apparently "risky" ideas (ideas that the CFO doesn't or doesn't want to understand), training of personnel (it's not needed, the personnel only want to boondoggle at some hot spot when going to a standards committee or getting a certification), new equipment can wait until there is a better quarter, and so on.

Even in a single organization, external policies can lead to a significant amount of intra-organizational process friction.  For example, in the 1960s to the early 1980s, during the infancy of information technology, when computers had less computing power and storage (by one or more orders of magnitude), programs for the US Federal Government required separate computers.  This policy made sense, since, in addition to the fact that a single small program could use all of the power and storage of an entire computer, the finance engineers of the time had no way to allocate costs for CPU cycles and storage to more than one program--it was just too hard.  Consequently, Federal contract program and project managers, and other finance engineers got used to having one or more separate computers for each effort.  This policy of each program or project was institutionalized into the organization's financial thinking, processes, and systems.  As a result of Moore's Law, by the 1990s, many times the minimum computing power a program or project could purchase was many times its needs, so that up to 95 percent of a typical computer's CPU cycles were idle and less than 10 percent of the storage was used.  However, because of the low initial costs, every program and project still insisted on having its own systems and its own software.  This led to this large organization having thousands of sparsely used computers.

The problem was and is that each system requires installation, hardware and software maintenance, operations management, and IT and physical security.  From the perspective of both IT and the Organization's finance engineering, this is highly cost inefficient, while from the perspective of the program or project, this is the way the budget, the accounting, and the bonus systems were set up, so therefore everything is right with the world.  Any change was unacceptable, even though it would significantly reduce the overhead costs of the program or project. 

To show how entrenched this thinking was, many of these efforts would under run their expense budgets throughout the year, then in the last month the program would look to spend this under run.  One way they would do this is through the purchase of licensed software--software with a significant initial cost and with a significant yearly maintenance license fee.  Many programs and projects purchased this type of software based on potential engineering or programmatic needs.  In the following year or more, the program did not use the software because of intervening challenges and opportunities.  Still, it continued pay the license fee.  When another effort approached the program with an immediate need for the software, the nearly universal answer was no, the program could part with it "because it might be needed in the future" (and there was no accounting method to allow the program manager to participate in the bonus program of the other effort).  Consequently, there were licensed software packages costing tens of thousands of dollars with thousands of in licensing fees per year, simply sitting on the self.

When the corporate IT engineering and architecture team proposed consolidation of all of this standard engineering software, the universal answer from the program and project managers was a resounding "No Way!", even though it would reduce the cost per engineering seat for the program by an order of magnitude while increasing the agility of all participating efforts, that is they could use the software on short notice and increase or decrease the number of seats on nearly an hourly basis (paying for only what they used).  The additude continued to be "We need our own; just in case, and the accounting system will not accept the change."  This inflexibility of thinking and accounting led to much intra-organizational friction, cost, and chaos.

Another cause of friction is any change in vision, mission, or strategies.  This always results in an increase in intra-organizational friction.  Even in the most absurdly informal organization on the "going out of business" curve there will always be remainates of the successful organization standards and policies--though they may be difficult to discern.  Optimizing the investments, policies, and standards of a new organization always takes time--much more than most finance engineers expect.

However, when the objective is increased "shareholder value", then detailed cost efficiency takes precedence over everything else.  This means that the organization will purchase the low cost tools and software--that may almost work in the processes (I've seen that on many occasions).  At times the operating costs and the reduce effectiveness of "the least expensive solution" are such that the organization does or should have back "the solution" out.  I know of two instances where this cost the organization a great deal, one that costs millions and helped create a situation where they almost lost a billion dollar contract, and one that cost tens of millions to implement and tens of millions more to back out--in both instances, management did not want to acknowledge they were wrong, so they through good money after bad.  And this is what Wall St. traders and institutional investors force on management when they insist on "increased shareholder value" that is a synonym for "more money in my pocket this quarter".

In summary, chaos occurs in at least three key categories of process friction: 1) The alignment of the processes (with associated activities, functions, and procedures) and tooling, 2) The policies and standards set, and 3) changes in the vision and mission.

Enterprise Architecture and Chaos Management

Enter the Enterprise Architect and his or her processes to help to minimize the process friction of the organization in achieving its vision and mission.  If the overt or covert mission of the organization is to "create shareholder value" then there is little an Enterprise Architect can do; and it is likely that this type of organization will not allow good Enterprise Architecture (Mission Alignment, and Governance and Policy Management processes [that enable and support the elimination or amelioration the three categories of process friction]).

These Enterprise Architecture Processes are:

• Mission Alignment (see my posts, Mission Alignment: A Responsibility of the Enterprise Architect, The OODA Loop in Mission Alignment Activities, and An Example of Enterprise Architecture Changing the Structure of Government).
• Governance (with associated Policy Management) (see my posts, Standards: A Mission of Government and Governance, Infrastructure: A Mission of Government and Organizational Control and The IDEF0 Model and Organizational Economics Model).
• Agility in the enterprise architecture (see my posts: Lean or Agile Enterprise and Architecture, What is Architecture? and What is Agility?).