In the previous posts I focused on the Business domain of Digital Transformation, arguably the most important of the three. In this post, I will focus more on the mechanics of HOW the transformation will be executed and by WHOM.
To reiterate, the three domains to be addressed by the transformation include:
- 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.
The process by which the transformation should be assessed, planned and executed is represented in the schematic, below:
Figure 1. Transformation Schematic
The Technology Domain
Establish Transformation Program Management Office (jointly)
It is assumed that the organization has established a TPMO, headed by a senior Business executive with an equally senior Technology Executive as co-head or immediate report. See this same heading under the Business Domain in the previous post.
Acquire Expert Resources
It is also assumed that advisory Business and Technology resources will have been brought in to help guide the initial phases of assessing requirements and planning for the transformation. See this same heading under the Business Domain in the previous post.
Set Research Agenda and Begin Research
Once a Program Charter has been established, concrete feasibility assessments and the process of technology selection will proceed. This will be overseen and guided by the Technical Subject Matter Expert (SME.) That person should facilitate and guide the selection of tools and methodologies that will be employed to execute the Transformation Program and operate the to-be environment. It may be that multiple tools in a given class will make sense for different purposes. For instance, both Node.js and Python development may be justified, each for what it does best or how it is commonly used. While a specific Cloud vendor for company-managed applications may be selected, it is possible that a SaaS service, such as SalesForce, may be hosted on different cloud vendor or on its own cloud and will need to be integrated. Fortunately, service-based architectures and APIs can facilitate this.
Define Target Development Stack and Establish Dev and Ops Processes
All of the issues and preferences identified in the previous step must be taken into consideration and weighed in the course of selecting the Dev, DevOps and infrastructure stacks. Piloting required integrations and proving that the stacks work as expected is an important risk mitigation step.
Conduct POC and Prototype Projects
Once an instance of the target DevOps environment has been created, a realistic simulation of development and implementation activity should be created and exercised to identify process or other issues that need refinement. When a smoothly-running set of infrastructure standards and processes is in place, POCs and Prototype projects can be initiated.
It is advisable that these projects exercise the full stack of infrastructure and DevOps processes. Also, sequencing these projects can be important and parallel execution should be minimized early in the course of executing them to limit the number of causal factors that may interact to impair performance of the DevOps environment and team. This will make it much easier to identify and correct issues that arise. Finally, conduct lessons learned assessments at relevant points and revise and refactor as it proves necessary.
Execute Program Plan
The Transformation Program Plan coming from the Business Domain, while informed by the Technology SME and members of the team, is end-result oriented and probably will not contain the level of detail required to constitute a viable Project Plan for each initiative. It would not make sense to try to develop a suitably detailed plan for each initiative in the Program Plan at the outset because it is likely that the Program Portfolio will change over the course of the Program and the technologies on which it was initially predicated are also likely to change. What will make sense is to employ the company’s project management standards to produce a Project Plan for each initiative as a prelude to presenting it for approval and funding.
Elements of the Project Management Institute® (PMI) approach that should be incorporated include:
- Project initiation and Charter development
- Participant Role Definition and Assignments
- Project Management Controls and Process Definitions
- Communication and Reporting Plans
- Project Scope Definition—Functional and Non-Functional Requirements
- Solution Design
- Work breakdown structure, budget, plan and schedule
- Risk Mitigation Planning
- Change Management Process Definition
- Acceptance Criteria Articulation
- Continuous Improvement Plans (in addition to the Program-level process)
Participate in Continuous Evolution and Improvement (jointly)
See this same heading under the Business Domain in the previous post.
The Organization Domain
Define Staffing and Skill Requirements
Much of the knowledge and skills required in the to-be environment will relate to the specific technologies, processes and standards selected. It is advisable to plan to educate as much of both the Business and Technology staff as soon as is practical so that they can participate in Program activities. Migration to the Cloud will mean major changes in how things are done from both sides and it is important for both groups to work through the transformation together in order to maximize overall ability to execute.
It would be a good idea to find a training vendor that has programs focused on BOTH the technologies and DevOps processes that the Technical staff will need and role-based processes that will enable the level of collaboration with Business users that will prevail in a successfully transformed organization.
Issues to keep in mind include:
- Cloud-based applications are likely to be based on microservices architectures and APIs, architectural paradigms that may differ substantially from what existing staff are used to. Senior-level cloud architects should be made available to mentor project teams as they find their way with these paradigms.
- Agile development approaches are likely to displace virtually all waterfall-style approaches. Rapid implementation and non-stop refinement will create substantial changes in how projects are structured and managed and what users will come to expect from the development team. Learning to start developing and move forward with less information is something to which developers will have to adapt.
- Developers will become more involved with operational infrastructure as the knowledge and time required to implement it in Cloud environments is vastly lower than on-premises environments. Ultimately, the ratio of development staff to operations staff will increase. Cloud Operations specialists will evolve to play an active mentoring role early in projects’ lifecycles.
- More changes will come. The ability to adapt and change is crucial so existing people who navigate the new landscape effectively should be prized.
Build Staffing Requirements Plan and Identify Training Requirements for Existing Staff
ICT organizations have always mapped their internal organization as a matrix of technologies vs. Business user areas, the idea being that the organization could match members with appropriate skills to service Business areas’ needs. In fact, Cloud-based ICT is not particularly different, except that the close interactions between users and developers will necessitate more and better business knowledge on the developers’ part in order to optimize productivity.
Within the context of the Program pattern I have outlined, knowledge and experience requirements will become broader and shallower at each of a number of progress points:
- In the initial phase, prior to the development of the Program Charter, the highest levels of knowledge and expertise are required. It makes sense to rely on outside resources for this.
- In the subsequent phase, as the TPMO and technical research agenda is developed, senior resources will also be required, probably also from outside SMEs but paired with in-house people who may need some education.
- The EA work may be performed by existing EA staff, if it exists. If it does, it is quite possible that the information to be assembled may already have been, simplifying and accelerating things. If not, outside resources may be required for this, as well.
- At the point that POCs and Prototyping are to begin, staff versed in both sides of the DevOps continuum must be available. Cloud and Cloud Application Architects and Project Managers familiar with automated development and infrastructure pipelines will be needed. It is at this point that a mixture of acquired people with subject-matter expertise and repurposed in-house staff can be applied. Ramp-up time to prepare these people should be factored into the Program Plan to enable their participation when they are needed.
- By the time the Program Plan is approved and initiatives are approved and funded, transition to a subset of the steady-state organization should be well underway with a mixture of new and existing staff.
The Issue of Bi-Modal IT
Legacy applications, especially those built in technology incompatible with Cloud-native implementation create a problem—continue to use them as-is, port them to the Cloud somehow or replace them? Gartner has advocated splitting IT into groups that support legacy applications and infrastructure and groups that will be repurposed to move into the Cloud. (see this article)
I agree with Jason Bloomberg, who is quoted in the article. Perpetuating infrastructure from which a company is trying to move away, will ultimately be self-defeating, slowing progress just when it may be most important, impairing agility and increasing overall risks. Keep in mind also, that the economics of running legacy platforms may become even less palatable when some of the applications that shared them are moved to the Cloud and expenses can no longer be allocated to them.
The need to retire and replace these systems isn’t going away and migrating them to the Cloud should be included in the overall Transformation Program. The people who support these legacy systems may, or may not, be interested in or capable of transitioning to a Cloud-native environment and that must be dealt with on a case-by-case basis.
Finally, the downside of creating a group of people within the company with limited employment prospects should be considered. A disincentivized group of increasingly hard-to-replace people on which a company may be highly dependent is a considerable risk.
Execute Staffing Development Plan
Meeting staffing requirements for the Program and Initiatives and ensuring that the skills and experience that steady-state operations will require is a crucial part of the overall Program Plan. It is a good idea to begin trial education efforts and evaluate the results early and revise them quickly if the results are not acceptable. It is a good strategy to plan to place numbers of newly-trained staff on initiative teams mixed with experienced staff, who should be charged with mentoring them.
Participate in Continuous Evolution and Improvement (jointly)
See this same heading under the Business Domain in the previous post.
In Summary
I’ve covered a lot of ground in these last two posts, which reflects the breadth of issues inherent in digital transformation. The most important thing to keep in mind as companies approach it is it is not a change in technology as much as it is a required change in mindset, approach and a new understanding about what it will take to be competitive in the evolving environment. Established companies must demonstrate a willingness to jettison things that will retard their ability to compete, even if sunk investments go with them. In a cloud-native world, infrastructure and enablement for capabilities will become ever more ephemeral and, through the mechanisms of reusable components, open-source libraries and SaaS subscriptions, ever more generic. It will no longer be possible to rely on barriers to entry emanating merely from the ability to invest in infrastructure to secure a company’s position in its markets. In the end, the ability to compete will depend more and more on companies’ business ideas and execution as differentiation enabled by technology diminishes.