I recently read an article by Computer World that brought to mind the following— “Which of these five mistakes do you see as being the most common and/or detrimental to a cloud migration?” Here are my thoughts on the topic of migration and how to avoid these common pitfalls, plus how to how to communicate an organization’s needs based on the cloud learning curve.
The article gives these points as pitfalls:
- Not analyzing your apps before the migration
- Forgetting a business analysis before starting
- Underestimating costs
- Not getting the training you need
- Not moving beyond lift and shift
I’d like to pose the argument that these are all issues indicative of a much more pervasive issue that is best described by a hypothetical example:
A high level executive, board member, brand new CTO, or company MVP attend a conference or seminar where they learn that the cloud has numerous benefits that can give them an advantage in their market. It’s not a very technical presentation, and they never learn of anything specific to their use cases, but they see a generic proof of concept that shows some forthcoming feature that is polished and looks to be quite robust in its execution. They also get the impression that with everybody else in their market also looking at this technology, to pass it up would be to leave yourself open to becoming obsolete compared to the competition.
They return from this seminar looking to take advantage of these services as soon as possible. Coming from an MBA background they think in terms of quarterly returns and thus assign an arbitrary deadline within that framework with the hopes that the new cloud technology will manifest itself as some significant bump in the next few quarters to come. They do this without ever really considering that application development is an iterative, incremental process that doesn’t adhere to a definitive quarterly cycle. Thinking in terms of revenue streams, they are service focused and not resource focused, thus they will ask that a service or feature be migrated to the cloud, and not some pool of resources. They don’t consider that this service or feature itself may be comprised of many components that in and of themselves are not suitable for the cloud. They are coming from a different mindset, thinking about different problems.
Meanwhile, there is the project manager, feeling the catharsis of a rude awakening. They already have managed to keep a development and operations department at near-full utilization just maintaining and improving upon infrastructure that they have spent decades building processes around that are trending towards design decisions that had already been discussed down to the bone many epochs ago. Now, out of nowhere, decision comes down the line that a ‘feature’ is to be moved into the cloud–and it needs to happen before the quarter ends in a few months. The project manager knows full well that this feature is actually a cacophony of interacting APIs, SANs, workers, queues, data stores, all precariously held together. It’s a point of pride that this thing works and people are able to release code 4 times a month to production. What’s more, is there doesn’t seem to be any organic need driving the project–merely the whims of corporate. So now titles are on the line for a project that by its very nature is probably uncalled for. One that will entail many painful discussions with developers and engineers, each of whom will have to reconcile the moment they realize they are about to have to abandon many familiar things for a reason that, having no pragmatic value, is beyond them.
The role of what an MBA is has to change. Companies that are completely reliant on their application suites to generate revenue have an obligation of self-preservation to comprise themselves of MBAs with STEM and technical competencies.
Otherwise the seeds for big problems are planted within the company by these folks where:
- Deadlines are set that do not account for iterative development.
- Fear of losing business to competition makes slimming margins between resource cost and feature revenue and afterthought.
- Budgetary fluctuations increase as sacrifices are made to keep up momentum.
- The team that already had ~80% utilization of things to do all day now have to shift gears and try and meet deadlines while flying by the seat of their pants.
- They made so many compromises to get non-native and stateful services.
- Running just to meet this deadline that refactoring itself would be another complete endeavor that might be better served as a complete product re-release.
All of which could have been avoided had the person who attended the cloud seminar sat down with their CTO, and said, “Go talk to your team about this, and see if we have an organic need for any of these services. If we do, run a cost analysis and get an estimate from development and operations as to what low hanging fruit is available to us, and what processes need to be put in place to get us to where we want to be.” The strategic choice to create a robust development platform for native cloud applications that will pay off in the long run. When there is scaffolding for developers to rapidly release features that generate revenue many times per quarter, this is clearly a better option than the tactical choice to try and force some initiative with the hopes of boosting a single quarterly cycle.
How does the Cloud Learning curve change the way you communicate to clients what needs to be done in a timely and cost effective manner with technical people?
I look for systems they are familiar with and speak in terms relative to those systems. These people tend to be the most particular in their methodology, so the most important thing I try to convey is that I am not attempting to change their methodology, but rather provide a scaffolding that best supports that methodology. They know what needs to be done and how to do it effectively, the most important thing is that they know I am there to be the lens for them.
With non technically minded people, I look for the absolute simplest analogy to a solution to a use case. Take for example accumulating large amounts of numeric data. Rather than dive into the weeds about MapR, I can simply say, “If I have a massive pile of sticks, I can try and count them all myself. Or, I can give a handful of sticks to many people, ask them to count the sticks they have, and then add up the totals they give me. This latter solution is much faster. It’s computerized teamwork.” This is something that almost anybody can understand.