Cloud Infinity: The Organisation Stone
In a continuation of the Cloud Infinity series, I present The Organisation Stone. All infinity stones are of equal importance and full migration potential can only be unleashed if each one is harnessed correctly. A guiding principle, which I have written about in API Marketplace Engineering, is that organisations are different. Some may be aircraft carriers, some speedboats. By understanding and appreciating these unique characteristics, the Cloud migration route can be better planned, which would result in a more enjoyable journey. I highlight some of these characteristics, from my experience of sailing the seven seas of IT, aboard different types of ships, in various roles.
Agility: Well established enterprises are typically well governed and rightfully so. Without stringent processes and procedures, there would be anarchy. Orders from the Captain are relayed to the First Officer who repeats it to the Pilot who passes it on to the crew member for execution. New Cloud services and capabilities are carefully scrutinised under high magnification of Security and Architecture lenses. The slightest deviation from enterprise norms could tarnish the reputation of that service and to restrict where and if it can be used. The overwhelming burden that these organisations carry is that hastily made decisions could cause irreparable damage in the future. Unfortunately, this typically results in lengthy and drawn-out decision-making timelines. If you have ever worked with an Enterprise Common Data Model, this scenario may seem familiar - as Data Architects attempt to define a dialect which would appease Ancient Egyptians and the Alien race we will meet in the 25th century.
In these types of environments, be sure to allocate sufficient time (and energy) for detailed technology assessments. One approach which I have observed is to first attempt to understand the existing enterprise standard. Determine if that approach will work in a Cloud context. If it does not, identify and highlight the gaps. Find a new solution, preferably a Cloud native one, that meets the existing enterprise standard, fills the gaps and then adds even more capability. Then, present the new solution to a Committee or IT Forum with decision-making power to allow it to be used - either as a standard or an “allowed deviation”. Be sure to highlight that the new solution is likely to be compatible with Alien lifeforms.
Vision: As much as the world attributes the invention of the iPhone to Steve Jobs, this was the result of the combined effort of many people in the Apple organisation. I would think that the decision to move to Cloud is made by the IT Leadership after consultation with various stakeholders in the enterprise and for good business reason. Like sailors caught in a storm on a rough sea may sometimes curse the ship’s captain, delivery teams working to meet impossible timelines often demonise the Chief Information or Technology Officer for making over-ambitious promises to the Board.
It is imperative that the reasons for the Cloud migration are shared with everyone in the Enterprise, and understood before the journey begins. It may be great water-cooler rumour that the Board has promised the CIO a shiny new Ferrari if the on-premise data centre is shut down by the end of the financial year. Realistically (and far-less scandalous), the reason could be that the CIO and their Executive team is trying to reduce infrastructure costs to avoid restructuring and having to let people go.
Approach: Equivalently, IT Leadership must take a stand and set the tone for the migration. My good friend, Warren Koen, wrote a great article explaining “kill” vs “kill -9”, which comes to mind. If a commitment has been made to shut down data centres by a specific date, I would infer that time is limited. This would imply a lift-and-shift migration strategy. Architects should not be postulating about the meaning of life and Engineering teams should not be trying to “optimise” applications to leverage new Cloud capabilities. An accelerated Change Management process should also be defined to get solutions into production faster. Conversely, if a strategic decision is made to leverage the full capability of the Cloud and to use the opportunity to re-engineer solutions, it would allow the Architecture team the luxury of time to have another cup of coffee while they fight over a marker at the whiteboard.
This may appear to be a fairly straightforward observation. But, I have been in countless design sessions where Information and Network Security teams prescribe meticulous (and almost impossible) requirements for a solution to be migrated to Cloud. However, the on-premise solution does not meet the bare minimum. At these junctures, it would be fantastic to reference the Approach - "I would love to implement KMS with SSL, double-encrypted with a customer-managed key, sprinkled with a some magic fairy dust which not even a quantum computer could crack in a thousand years. However, Mike (the CIO) gave us the directive to do this as fast as possible - probably so he can get that shiny new Ferrari the Board promised him."
Again, this is not an exhaustive list of items for consideration when planning your Cloud migration journey. My hope is that it serves as a signal that the route for migration needs to be planned. The age-old reference of “A stitch in time saves nine” comes to mind. Your migration journey is likely to be far smoother if you know the type of ship you are piloting, you have the trust and loyalty of the crew and the approach is defined unambiguously. If you have any thoughts, experiences or insights regarding the above, I would love to get your feedback.
Note: I work at Amazon, but this is my own opinion.
