Eating Donuts and Baking Bread

Enterprise Architecture provides a keen platform for observing the executive and those of us that serve them; this post is dedicated to that relationship. I apologize that it doesn't have much to do with technology - for first time readers, I promise my next post will make up for it. In the meantime, indulge me as I attempt to offer a few observations on American corporate behavior and how these relate to EA.

The first  behavior is what I call "Eating Donuts" and  relates to a rule of mine - 

"Donuts make you fat. They taste good for about 5 minutes and require hours of treadmill time."  

To understand this, think about the tasty donut and your hunger. If you are full from a good, healthy breakfast, the likelihood of overdosing on those Krispy Cremes somebody brought to work is small. You may have one. On the other hand, if you are starving because you skipped breakfast, hoping to get into the office early and finish that report...well, let's just say those KCs are gonners and so is your waist line. 

This happens all the time in business - a company that is starving for the short term satisfaction of ill conceived but immediately beneficial actions will rarely consider long term impacts. Results are figured quarterly - the benefits of the "donut" are too tempting.  Organizations with out of control IT "Run-the-Business" costs have executives who like donuts and underlings who bring them plenty. 

As EAs, we have to be the Jillian Michaels of our companies, offering long term solutions that keep us all healthy and fit. In the end the company will thrive and outpace competition. 

One practical approach is to become watchdogs of the Cost-Benefit-Analysis (CBA) - it's that spreadsheet completed to justify projects for funding. Companies do not always make the connection between CBAs and technology cost growth. Examine a few for yourself; there is a good chance that continuing maintenance costs are typically and grossly underestimated.  Put another way...show me a company that can't keep a handle on its technology costs, and I'll show you one that has a CBA problem.

"Fresh Baked Bread" is a second interesting behavior. 

This one relates to another rule -

"Just because something smells good does not mean it will stay down if you eat it. The devil is always in the details."                                                                 

Consider the following common corporate behavior - Director X presents a plan to solve problem Y to his boss Vice President Z. The idea seems aligned with the current strategy, uses all the right buzz words and is wrapped in a beautiful PPT. The boss gives the plan a "sniff test" and concludes it smells really good - like freshly baked bread. The VP gives the nod and reports to the SVP - "problem solved". Organizational attention turns elsewhere, this one is in the books...or is it?

Director X now attempts to implement the plan and runs into issues concerning the details of execution, probably because the solution is a variant of the the last three failed attempts. Ultimately the plan achieves some superficial success, but root issues are not addressed. Time passes, people turn over, nobody remembers exactly why we failed or who proposed the previous plans that did not work. Jump back to the beginning of the previous paragraph, rinse and repeat. 

Here is an example from personal experience:

The problem we were trying to solve is how to effectively govern architecture; our solution was standard - an Architecture Review Board. We attempted three times in as many years to create an effective board. We tried different formats, different board compositions (technical, executive, mixed), and different support staff. Each of these iterations looked and smelled good, however the root causes of our ineffectiveness were never addressed. 

The devil was in the details - we were trying to do both in depth review of an architecture and executive approval in one fell swoop via a grueling ARB meeting. Our projects would present to the ARB, expecting approval of their architecture only to find the executives needed for approval were not there and the underlings who did attend went down the rabbit hole on technical issues that could not be resolved in a meeting.  Once we split the process into a broadly attended Architecture Review Meeting on a single subject and  a regularly meeting group of executives to approve things (the ARB), we made real progress.

These solutions were simple - once we paid attention. As practicing EAs, we have a duty to identify root causes and propose simple solutions that eliminate sources of past failure, paying attention to the details. We must remember that the executives we serve are busy and they trust us because we are generally senior, experience people.

It is our duty to ensure we put the appropriate amount of yeast and salt in - and oh yeah, bake whole grain bread, not donuts!