An exclusive to Leadership Thoughts, chapter 26 of Donato Piccino’s new book — The Ultimate IT Project Manager — Tin and Wires, Part 2: Data Centre Migration Master (DCM) Class.
Monkey Episode 7 : The Beginning of Wisdom
DCM involves data migration but it is only one constituent part of the programme. DCM is not a purely technical project — many stakeholder groups are impacted across the organisation. A purely technical focus will just bore them.
There is a plethora of documentation on DCM. For ease of understanding, I have tried to take all of those approaches and represent what is common between all of them. Dealing with anything complex requires a model to abstract and conceptualise an approach. I will start with a simple view of the organisational architecture impacted by the DCM.
For planning purposes, you have to place the organisation into 4 distinct domains.
A DCM is a programme of iterative activities that spans each of the domains. Impaired DCMs have a common theme. The phasing on the plan was very waterfall, and the activities on the plan were finish-to-start over long durations.
The more successful DCMs have the same phasing, but the phasing is iterative across the domains, which makes absolute sense when dealing with complexity and uncertainty.
In the diagram I have indicated the extent of the involvement of stakeholders from each of the domains to deliver a successful DCM.
Prior to initiation, the questions on everyone’s lips will be: How long will it take to complete the migration? How much will it cost? How do we resource the delivery? And within the technical ranks of the IT department, what will happen to my job?
Embarking on a DCM without first achieving clarity on these matters is a recipe for failure. The first critical success factor in a DCM, is the whole organisation having a shared and common understanding of why, how much and when. Achieving this aim requires execution of communications plan, to ensure transparency and a candid conversation about the impact.
Timing all depends on how much time you have to migrate from the Source Operating Environment (SOE). Migration of the SOE followed by optimisation on the Target Operating Environment, gets you out of the legacy data centre quicker than optimising the SOE, prior to migration to the Target Operating Environment. The more time you have, the greater opportunity you have to optimise both the source and Target Operating Environment.
So the ‘how much time do we have’ question is about ascertaining when and why the organisation needs to get its applications and data out of the Source Operating Environment.
The ‘why’ question should be answered in a dreaded future context, that is what is the commercial impact on the organisation, if the migration is not achieved by the dates requested by the business?
Using this approach identifies unreasonable time-is-of-the-essence delivery dates. It is unreasonable because when there is no reasoning behind why the delivery date is the delivery date, it is just a date plucked from the air with a propensity to become an expectation. This kind of planning risks an organisation’s business operational stability.
How much? It all depends on the return on investment in the business case and the ease of access to funding. The best advice I can give here is to invest time in understanding the actual cost of similar migrations with all the hall marks of success. I would urge caution when using cost models based on unproven assumption, sensitive to volume of servers, whether they are physical or virtual.
All DCMs are unique because of the interdependency between applications, network, OS and data. It’s the complexity in this relationship that drives the effort required to achieve a smooth DCM. That knowledge exists in 2 places: performance and configuration data in the Source Operating Environment; and in technicians’ heads as tacit knowledge.
Addressing the HR question is critical. Without addressing concerns from technical staff who maintain the Source Operating Environment (SOE), they will be less than enthusiastic about getting involved. A critical success factor in any DCM is having access to information about the make-up of the Source Operating Environment.
There are some key messages that must be understood by technical staff and IT managers impacted by the change. There is a way of getting these messages across. The key message is that less maintenance and management activity frees up budget to invest and innovate in IT for business advantage.
It’s difficult to see how any technician or IT manager could disagree. How engineers are led, managed or motivated will make or break a DCM.
A DCM involves processes and tools that extract, transform and configure workloads on 3 environments — source, interim and target. A workload consists of application, data and OS, migrated from one environment to the other.
In all likelihood multiple teams of different engineers will have to be engaged given the differing environments, OS, data tiers and application stacks. The aim of the game is to get them all working as a team.
It means pre migration acquires a focus on team building for the main event. There is nothing more detrimental to a DCM than a dysfunctional cohort of engineering teams finding it hard to collaborate.
After all, these are the guys who know about the environments and how to make the tools sing. It’s the engineers you will need onside to figure out why something that works on paper does not work in practise. Because of these reasons, your relationship with the engineers and technicians is more important than your relationship with anyone else involved in the migration.
Designers, testers, managers, sponsors, security consultants may be more vocal but they are not the ones pushing the buttons and looking at technical stuff in the middle of the night figuring out how to make stuff work when it doesn’t work.
So as a PM, you have to build a certain type of relationship with them. In practise, this means demonstrating a healthy respect for them. The moment you treat them like robots by spoon feeding instructions, their productivity will go south.
You have to include them in key decisions about how the migration will be technically delivered. Ask them for ideas on how to optimise the migration or simplify the migration design. The feeling of being involved in the design leads to improved quality and less unforeseen technical debt suddenly manifesting itself during migration.
Understand what motivates them. For some it will be money. For others it will be gaining new knowledge.
Adopting a policy of transparency is paramount. Don’t hide anything from them that may dis-empower them. Be selective with the engineers who engage on the migration. Look for positive attitude, team players and the proactive kind.
If they can’t offer this, do not let them near your migration. Lose the negativity addicts or the ones that will only work from painting-by-numbers prescriptive method statements. They are real time stealers.
Engineers are grounded types so your plans have to be realistic or they will see the holes.
Continued in Tin and Wires: Data Centre Migration Master Class, part 3