5 Mistakes Companies Make When Defining an Operational Architecture

Architecture, according to Merriam-Webster, is “the art or science of building” or “the manner in which the components of a computer or computer system are organized and integrated,” among other things. Operational is defined as “of, relating to, or based on operations” and “ready for or in condition to undertake a destined function.” LNS believes businesses are best served when they apply the technique of Operational Architecture, which taken literally from the previous definitions, is the organization of the systems and technology to perform the functions of business.

It is the art and science of bringing together the people, processes, and technology to run your business most effectively. It is the middle step of LNS’s Digital Transformation Framework, the step following the definition of Operational Excellence and the precursor to building the business case for investment. Being such a critical element, the biggest mistake for most companies is that they don’t even have an Operational Architecture. Even those that do have an Operational Architecture and a process to maintain, its currency still risk making a number of critical mistakes.

1. Confusing Plans with Planning

Dwight Eisenhower said, “In preparing for battle I have always found that plans are useless, but planning is indispensable.” Too many businesses fall into the trap of focusing on the plan, that is the document that results from the planning effort. Often, this is the result of using a template or a “kit” approach with too many fill-in-the-blank forms to produce a volume which then sits on a shelf, accumulating dust. The value of the plan is in the planning that produces it. It is the examination of the alternatives, evaluation of the options, and the process of selecting a path forward. The plan merely serves to document the process and the decisions so that those that follow can understand the thought processes that went into making the decisions that were made.

2. Designing in a Vacuum

Often the Operational Architecture is viewed as an IT initiative, a technological extension of existing IT planning processes. In other cases, the business leadership views the exercise as the translation of strategy into tactics for the operational elements of the business. In both cases, the lack of collaboration means critical information is missing from the process. Operational Architecture is about the convergence of people, process, and technology. All elements must be part of the planning process. That means the technologists, the business process owners and the leadership and front line management all have a role to play in a successful Operational Architecture initiative.

3. Too Much or Too Little Detail

The idiomatic expression “cannot see the forest for the trees” is a cautionary warning businesses need to take to heart when undertaking an Operational Architecture initiative. Too many businesses focus on too great a level of detail when defining their Architecture. They try to design the end state to such a degree that they may jump straight to solution selection, the final element in LNS’s Digital Transformation Framework.

In doing so, they miss opportunities to design flexibility into their architecture. Often, they find that the effort to produce such detail extends the architectural exercise so long as to render the effort never-ending. Technology and business drivers may change fast enough to constantly render their efforts in need of redoing. Likewise, an equal number of businesses often go to the other extreme by not providing sufficient detail as to actually drive further decisions. They leave things at such a nebulous level that subsequent business case development and solution selection efforts, the final two elements of the LNS Digital Transformation Framework, take an inordinate amount of effort because the missing work that should have been done during the Operational Architecture phase needs to be revisited before those decisions can be made.

4. Not Understanding Bias

Every individual in the Operational Architecture process has biases. The organization itself has biases. Some of these are the result of business decisions already made. When designing an Operational Architecture, there will be monument systems or untouchable elements that represent “political suicide” if rejected. Having spent hundreds of millions of dollars implementing a new ERP, it would be foolish to suggest that it be replaced simply because a nicer one is now available that does more.

These biases must be recognized and accommodated. Other biases, however, need to be identified and overcome. A bias towards a specific vendor merely because the local distributor for that solution brings donuts into the office twice a month and donates to the company holiday party is an example of one that is a counterproductive bias. A bias towards a solution because it is simple to use may be justifiable, but if it is a bias that ignores the limitations of the product then it may not be justifiable. Understanding individual and organizational biases, evaluating them and documenting them is the best way to understand how they can and should or shouldn’t impact the process.

5. Thinking You're Finished

Even if they have done everything correctly and have created an exceptional Operational Architecture, businesses often make one final mistake. They get so focused on the follow-on steps in their Digital Transformation efforts that they never reevaluate the validity of that architecture. The point of an Operational Architecture initiative is not only to do the work but to develop the skills in the business to maintain that architecture. Technology, business drivers, and the environment the business operates in are not static. They are constantly changing, so the architecture needs to be revisited regularly to ensure it meets the needs of the business over time. Failure to keep the architecture updated can be as catastrophic as not having one in the first place.