The Achilles’ Heel of Digital Transformation

Does this sound familiar to you?

“Several years ago, our company had a great IT strategy. We began implementing that strategy with sincere enthusiasm. Then real life happened. Key executives left the company. New executives came on board with different priorities. Urgent market events forced us to pivot in response. We had mergers and acquisitions, some of which are still not fully integrated. We experimented with new and exciting technologies. A few of those experiments made it into production but aren’t fully supported. I’m pretty sure we have pockets of Shadow IT, though not quite sure how pervasive that is. We had fire drills around cybersecurity events. The government imposed new reporting regulations at an inopportune time, requiring suspension of other projects so we could address the regulations. And, of course, COVID caused disruptions for us all. So now our current state looks like a once-good IT strategy that was interrupted by a series of disruptive, disconnected fire drills and band-aid fixes.”

Many have referred to this result as the accidental architecture. Many CIOs would go further and lament that their accidental architecture involves a confusing jumble of solutions from a perplexing array of vendors. If this situation describes you, take some comfort in that you are not alone. (One recent client told me that they had 1,400 enterprise applications at last count.)

How do you transform a bird’s nest like that? You start at the beginning.

Clients often express their impatience when I stress the importance of creating a comprehensive current state document. They tell me they prefer to skip the busy work of describing the current state and instead jump directly to diagramming and planning the future state environment.

Just because you know your desired endpoint does not mean that all roadmaps to get there are the same. Consider a highway map of the United States. All roads may lead to Kansas City, but the journey in the winter from Seattle through the Cascades and Rockies is quite different from a journey that begins in Miami in the summer. Knowing your starting point and your current conditions are vital in charting your course to your end goal.

There are four compelling reasons to invest the time and energy to thoroughly document your current state.

Four reasons to document your current state

1. Win executive support

At some point in the future, you will create and present your transformation roadmap. This roadmap articulates the resources required to move the enterprise from its current state to its desired future state. Frequently, either the cost or duration of this journey causes senior executives to recoil. Those executives will demand an explanation for this disconnect. Executives may question, “How hard can it be to redo the data center or implement a new suite of Oracle applications or go from on-prem to cloud-native applications?” Without a thorough set of current state documents, you may find it tough to win over your executives on the complexity of your current state, including explaining complex, disconnected and sometimes obsolete components of your accidental architecture and how those complexities are driving the investment and timing budgets that you are requesting.

2. Reveal cost anomalies

The thorough current state document will identify small, possibly rogue or shadow applications and systems that will require very bespoke remediation activities as you plan the path to your future state.

3. Foundation for your roadmap

Ultimately every piece of technology, application, data store and business process that exists in the current state must be accompanied by a plan for its future. Each omission of a piece of technology, application, data store or business process creates a headache for you later as you may find yourself scrambling to retrofit its migration into your new transformation roadmap within previously approved budgets and timelines.

4. Reduce unnecessary efforts

The diligence applied creating your current state document could uncover unused or underutilized applications or systems that could be decommissioned as part of your transformation roadmap, thus saving you the trouble of migrating an application or system that does not actually require migration.

To create your current state dossier, you’ll want a comprehensive perspective of your environment from three angles: technology, data, and business processes.

Figure 1. Comprehensive View of Deployed Technology

Document Your Technology

The first document will explain the environment from a technology-centric perspective and examine both infrastructure and solutions (software and SaaS solutions). Capture the usage of individual servers, clusters of servers, switches, routers and related technologies. The list of technologies must include on-premises technology, managed solutions, IaaS and other solutions deployed to the cloud. This document will catalog each component of your infrastructure, its purpose, its user base and so forth. This first list goes beyond simply hardware and will also include a complete catalog of installed and deployed applications.

Don’t overlook your “band-aids.” Several former clients had a collection of homegrown interfaces or mini-solutions that were built as a quick fix to a problem. They were no big deal. Or so everyone thought. I call these little mini-solutions institutionalized fire-drills. They start out innocently enough – just a quick fix to get around a current hiccup. But a troubling number of quick fixes have unusual staying power and they often grow to incorporate additional capabilities. They are small at first but then grow to create a vital but fragile link between various legacy applications. Mini-solutions may live on long after the urgent need has passed, to become part of the production environment. They can become institutionalized.

Strive to document their purpose, inputs, internal processes, calculations and outputs. I further recommend you assess the potential value of replacing ad hoc solutions with well-supported modules or functions in your future state environment. Obscure little departmental applications, sub-applications, interfaces, data extracts and reports make up a segment of technologies that could fail and cause trouble at any minute.

Ask this question: “What legacy pieces inhibit your move to your desired future state?” These last-mile hurdles can take an inordinate amount of time and money to resolve. It is a dreadful setback in time and cost if you can transform 90% or more of your environment but are still required to keep an entire legacy environment in place simply due to a few archaic components that cannot be moved.

Many environments contain hardware platforms, software systems and applications that are years past their prime. Whether it is the AS/400 system in a small distribution center, a 1980s-era dot matrix printer for printing obscure production labels, or a homegrown interface written years ago in COBOL by two guys who retired in the 1990s, some aspects of your environment will not lend themselves to a simple migration to your future state vision. For these reasons, due diligence demands that you discover and document such occurrences.

Evaluate Your Data

Your second list will document all known data stores and record detailed information about the ownership or custodial assignments for the data, as well as how the data are secured, maintained and used in the organization. Years ago, I did not think a separate data-centric assessment was necessary as I expected the technology-centric assessment to capture all databases and data stores in the environment. After many client experiences, I have changed my view and now believe that a separate data-centric assessment is warranted. Unfortunately, meeting this requirement is particularly tedious. And that tedium is likely why data stores often go undocumented. For each store of data, you must evaluate who is responsible for creating, maintaining and ensuring its ongoing accuracy. The primary reason for this importance is illustrated by a term borrowed from law enforcement: chain of custody. The customer master, for example, is accessed and modified by various departments. It is important to evaluate all of the authorized users to ensure that their current needs are met in your future state solution – for each data store.

Understand Your Business Processes

And finally, your third document in this comprehensive dossier will be a complete listing from the business division perspective identifying how data flows into and out of each business function, including finance, sales, manufacturing, shipping, billing and payroll. This is not a redundant exercise as often this final evaluation uncovers unique departmental solutions previously undetected in your other discovery activities.

Regardless of which approach you use as your starting point, you will find value cutting across your current state and examine the environment from the perspective of the other two axes. Cutting corners here will leave gaps in your analysis and almost always create headaches for you down the road.

I cover these topics in much more detail in my book, IT Strategy, but I hope this excerpt convinces you of the purpose and value of thoroughly creating these artifacts that represent your current state.

View Your Dossier Through an Executive Lens

If you’ve done all the discovery and documenting as I have prescribed above, you have a comprehensive view of your current state environment. Congratulations! But don’t pat yourself on the back just yet. It is not enough to simply compile this information. As a strategist, take a step back and carefully analyze your discovery notes and think through the following questions:

1. Take an objective look at IT’s performance from a user’s point of view. How would a reasonable user grade IT’s performance using the common education grading measures on a scale of “A” through “F”? Which areas stand out as particularly strong or weak?
   
   
2. What percentage of your current IT budget of time and money is spent just maintaining the current environment? Compare that figure to the percentage of the IT budget that is invested in exploring, piloting and developing disruptive, innovative solutions to give the business a competitive advantage.
   
   
3. How many software solutions are in use but are no longer supported by internal developers or outside software vendors?
   
   
4. How is success determined for IT today and has that measurement system brought about the results expected from your IT organization? If not, consider offering suggestions for different measurement criteria in your future state document.

Beyond these reflections, you will increase the thoroughness of your current state document by providing a statement of origin regarding how you got here. It is quite possible that your current state is not the result of a carefully planned previous strategy, but rather a mixture of strategic initiatives, tactical departmental solutions and urgent fire-drills: an accidental architecture. Providing a clarifying narrative about your environment will give every reader of your document a baseline understanding of today’s situation and why your requested time and cost budgets are reasonable.