In the previous three posts, I focused mainly on technology and how its evolution has created a need for changes in the way that companies operate. Digital Transformation is an ambiguously-defined and frightening term to many business executives but the need for it cannot be ignored. It has been my experience that many executives want their businesses to perform better and they seem to be willing to do anything except change in order to achieve the improvements to which they aspire. Many with whom I have spoken are all for migrating ICT operations to the cloud in order to cut operating expenses but too many of them see it as just a lower-cost alternative for doing essentially what they are doing now. In the long run, companies that change their operational architecture (HOW they enable their operations) but not their business models (WHAT they are doing) may well not survive.
The case I am making here is that merely mastering the latest technologies will not position companies to succeed. It is table stakes that will only allow them to get into or possibly just remain in the game.
As background, here are a few articles and posts that are worth reading:
- This VisionCritical.com article points out the acceleration of change and the decreasing lifespan of companies.
- This McKinsey article (free signup required) discusses some important internal impediments to successful transformation and provides some suggestions as to how to overcome them.
- This opentext article presents an approach to transformation that resonates strongly with me—WHAT first, then HOW, where HOW includes a transformation portfolio, program design and individual project plans.
The diagram, below, presents a generic schematic of a transformation initiative. It addresses three domains—the Business Domain (WHAT), the Technology Domain (HOW) and the Organization Domain (WHO.) In order to be successful, businesses have to transform in each of these domains.
- The Business must define and articulate what it expects from the transformation process, acknowledge the scope of what will be required and commit to participating and bearing the costs and risks.
- Technologists must determine the toolsets and define processes and standards that will best serve the organization.
- The Organization will have to be restructured and management must define a plan to instantiate the people, roles and relationships required to execute the transformation program and then operate the environment that results.
Figure 1. Transformation Schematic
The Business Domain
Obtain Corporate Buy-In
A company cannot succeed at Digital Transformation or any other major transformation without strong support from its management. The first step required is to obtain a commitment to an upfront assessment, inventory and preliminary planning process. In an organization of any size, this initial commitment will incorporate:
- Senior Executive management and, possibly, representation from the company’s Board, Financial, Technology and Human Resources management for a period likely to be three months, or more.
- Business Unit and IT resources necessary to begin the EA and IT inventory that will ultimately be required as a foundation of the transformation portfolio and the program plan.
- Access to some elite-level business strategy and technology resources, probably from outside the enterprise, to assist and guide the process.
The end result of the work in this exploratory phase is a clear-minded understanding of what lies ahead and a shared commitment to a follow-on scope of work that will culminate in a well-articulated program plan and defined, fundable initiatives.
Set Goals and Produce Program Charter
Once senior management has agreed in principle to proceed, the next phase is to articulate business goals for the transformation effort, identify the work required to achieve them and formally charter the effort to perform a detailed feasibility assessment and develop a plan to execute the transformation. This phase may not require significant elapsed time, but will require substantial dedicated senior management participation.
There are several potential reasons for this:
- It’s possible that there will be a need to frame strategic issues in a way that participants have not previously seen or thought about them. They simply may not recognize the company they know as it is proposed to look when it is transformed, which may be based on a number of fundamental shifts that the company has not, heretofore, contemplated.
- Some of the goals for digital transformation can be abstract, such as a trade-off between agility and operational cost-benefit considerations. Given this, defining KPIs for the transformation may require unfamiliar thinking.
- The capabilities and economics of a post-transformational enterprise may render a lot of existing applications and infrastructure expandable, which can be a shock to business and ICT people, alike.
- Substantial organizational changes will almost certainly be indicated and these are always uncomfortable.
- The scope of the program, the application of iterative techniques to infrastructure design and DevOps practices will probably make it necessary to view risk metrics in a new and different way than managers are used to. An organization designed to shift and respond to market events at high speed may place a higher value on opportunity costs than on concrete ones than more traditional organizations.
- It is likely that the people needed to manage and perform much of the work are not currently on board. Replacing existing capabilities while continuing to operate them means creating a parallel team, which will engender suspicion and fear. While some of the existing staff can participate, many will continue with the status quo for some time.
Ultimately, the goal of digital transformation is not replacing one set of technology, processes and standards with another. That is only enablement for the true goal, which is to become more agile, more responsive and more competitive in a changing environment. Succeeding at a cloud migration for all or most of the company’s infrastructure and applications, while cost-effective, will not be enough.
Establish a Transformation Program Management Office (joint Business and Technology Leadership)
If the company is serious about the transformation, it should have a Transformation Program Management Office (TPMO) headed by a Chief Transformation Officer (CTO), a senior member of Business management. This article is a good summary of the CTO role. It should be co-headed by or have reporting directly to the CTO a similarly senior Technology executive. The TPMO should report to the accountable executive, the CEO, COO or the most senior member of the Business Unit in which the transformation is executed.
Acquire Expert Business and Technical Resources
The transformation will certainly require expert resources on the technical side, but is also likely to require support for business and strategy issues, at least until the Program Plan is constructed. If the advisory resources that participated in the initial phase of work leading to the project charter are not going to be held over through subsequent phases of work, then alternative expert resources should be secured at this point. It is very important that the technical planning and standard-setting be headed by someone or a small group that will remain with the team until the first few initiatives are completed.
Perform Required EA and Define Target State
While technology has changed, one thing that hasn’t is the need to apply Enterprise Architecture (EA) discipline to any transformation. As often performed, EA practitioners delve into excessive detail, resulting in work product that drowns decision-makers in unusable volumes of data, text and charts. Nonetheless, a top-down EA model is needed to inform the planning transformation efforts. It is not optional.
In an earlier post, I presented a hierarchy for describing a company’s EA at a very high level:
- Strategy—What markets will we serve and how will we position ourselves in them?
- Business Model—What products and services will we sell? What characteristics will they have? How will they be priced? How will we market them?
- Operating Model—How will we produce and service what we will sell? What capabilities are required?
- Operational Architecture—How will we design and enable our organization to provide the capabilities needed?
The diagram, below, illustrates the relationships among these elements:
Figure 2. EA hierarchy schematic
The company’s high-level EA modelling should start with the external world—the markets in which it competes, its competitors and potential competitors, its suppliers, partners and any other meaningful parties, such as regulators. Some valuable exercises may include:
- Identify current products and services and slot them into the Boston Consulting Group Growth Share Matrix Model to help identify where investments may produce good returns and where not.
- Put together a revenue share model, identifying where the company’s revenue is coming from and what products or services might be critical to sustainability.
- Conduct a high-level SWOT analysis to add insight as to where threats may be coming from or opportunities may exist.
- Employ the framework of Porter’s Six Forces Model to gain some understanding of the company’s competitive position in any of its markets.
Then, move on to the internal space. Inventory capabilities, the commercially-valuable things the company is able to do, and map them to the products or services that it sells, identifying specifically the people, processes, assets and technology that are dedicated to each.
Ultimately, this model should result in a high-level understanding of what’s important to the company as it is currently constituted:
- Where does most of the revenue come from?
- Which products and services markets are growing?
- Can increased penetration for the company’s products and services be achieved? If so, how?
- What would it cost to achieve and what might it produce in additional revenue and profit?
- How risky would it be?
- Which products and services are declining?
- Can this be attenuated?
- Is it worth it to try?
- What threats and opportunities are out there for the current portfolio of products and services?
- What is the company’s competitive position in the markets in which it competes? Does the company serve its customers in them as well or better than competitors?
- What would it take for an existing or new competitor to threaten its position in each of its markets? Is there a sufficient barrier to entry?
- Can existing capabilities, resources and assets be applied to new opportunities?
It’s beyond the scope of this post to try to address strategy formulation but the EA work required to populate this model, down to the level of individual products or services, the capabilities they require, the enablement dedicated to them and the dependencies and integration requirements among them, is a necessary foundation from which to start.
Identify and Analyze Portfolio of Required Initiatives
Once a foundation of knowledge of as-is or current state has been established, the next step is to break the work of transformation down into discrete initiatives. This will be, at the very least, a messy process, one that the Business and Technology advisory resources should facilitate. There are innumerable approaches to doing this but all of them are supported by information from the EA model. Dimensions that must be considered and accounted for include existing and to-be states for:
- Products and services
- Capabilities, both business-related and technology-related
- Assets and capability enablers
- Organization, processes and skill requirements
A valid approach is to consider each entity in each dimension and define what will be required to transform it to the targeted state, keeping in mind that the transition process for existing elements of the current enterprise architecture must be accounted for until decommissioning or final transformation is completed. This will undoubtedly create numerous redundancies, but that is to be expected at this early stage.
Prioritize Portfolio and Create Execution Plan
When the ‘blue-sky’ list of potential initiatives is completed, then the hard work of rationalization (removing redundancies and identifying and accommodating dependencies,) cost-benefit assessment and risk and mitigation planning can commence. Once rationalized, the initiatives must be sequenced. Ideally, at least a subset of the early initiatives will produce tangible results quickly in order to prove that selected approach is working or to indicate that modifications are necessary.
The transformation program will, of necessity, proceed in parallel or overlapping paths:
- Select technology stack, choose vendors, develop internal competences, implement required infrastructure components
- Develop Dev and DevOps competence and processes until there is a core group of developers and operations people that can make them run smoothly; Define and initiate training programs in relevant areas
- Prototype transformed versions of applications and assets that will be replaced, classify existing elements that have common characteristics and identify potentially reusable components, processes or skills with which to address them; develop a transformation strategy across the portfolio of elements and plan to iterate across them
- Prototype new enablers and the Agile-style DevOps methodology that will be used to implement them; involve Business users heavily in this process
- Identify target evaluation points at which KPIs and results can be assessed and at which changes in direction may be initiated
Risk planning and mitigation is a crucial element of portfolio and program planning. Some considerations worth keeping mind are:
- Even though it will not produce results visible to a lot of the Business people, pioneering Dev and DevOps tools and processes must occur up-front as almost everything else in the program depends on the existence of smoothly-functioning implementation and operational capabilities.
- Clusters of products, services or capabilities that currently share tightly-coupled infrastructure or applications may represent risks resulting from co-dependencies. Seek to disentangle them, perhaps by building parallel infrastructure first, migrating one application and simulating existing integration with data connectivity where it’s impossible to interoperate across infrastructure platforms. Simultaneous migrations of multiple application systems can magnify risks.
- It may be easier to build new applications than be encumbered by older ones. POCs focused on new applications are better candidates for early implementation because they should have minimal integration dependencies and because Cloud Dev and DevOps technology enable rapid iteration and revision.
- It is necessary over the course of a long program to accommodate requirements for fixes for or enhancements to existing enablement. Expect to need to revise elements of the plan to account for this.
Fund Initiatives and Execute Plan
Ultimately, the Transformation Program must gain acceptance from the sponsoring executive managers and Business representatives who will participate in its execution. In addition to allocating funding for all or part of the program, it is critical that the executive team commit to participate in overseeing it, assist in overcoming organizational resistance and resolving disagreements. A lot of time, energy and money will have been expended by this point but this a make-or-break moment for the entire Transformation Program and the team behind it.
Participate in Continuous Evolution and Improvement (jointly)
The executive Business sponsors, the Business participants and the Technology staff should be monitoring status and meeting regularly to assess progress, successes and failures. One topic that should be on the standard agenda of the regular meetings is how to improve execution of the Program. Where necessary, amendments to the execution plan or other elements of the Program may be warranted.
This post has covered the Business Domain—the WHAT. In the following post, we will examine the Technology and Organization Domains—the HOW and WHO.