I've often been brought in to look at failed projects to understand what the company did wrong to avoid making the same mistakes again. When I get these engagements, my focus isn't on finding executives to blame but on identifying failures in the process that can be corrected to prevent future failures.
Often I've found the problem is that schedules and milestones are created in a vacuum, or they don't exist in the first place. The company has fired their guns before being ready or even aiming, and the problems of continually changing the target lead to a ton of wasted resources and a failed project.
This process failure problem came to mind this month when I looked at some of the partnership efforts surrounding the IBM Cloud. TCS (Tata Consultancy Services) has come up with a process they call the "TCS Intelligent Cloud Migration Continuum." It looks like a good process that could prevent future failures in Cloud deployments. Coupled with IBM offerings like the IBM Cloud Transformation Advisor and IBM Cloud Pak, the efforts should positively impact future Cloud deployments.
Let's talk about that this week.
Lift and Shift vs. Lift Modernize and Adopt
When I read through these efforts, I found a clear distinction between the two Cloud Deployment alternatives. Most Cloud deployments appear to be lift and shift. I was taking the fast path of just rehosting an application in the Cloud. When designed, the applications often existed long before those that developed them knew about the Cloud, and the result is kind of like putting a square peg in a round hole.
Much like if you were moving from boat to car racing, you wouldn't but wheels on a boat, you shouldn't make an application that was designed to run in a dedicated space on legacy hardware and plop it largely unchanged into a shared, highly dynamic cloud environment. Even if you get it to work, it will likely be inefficient, outdated, and perform poorly, much like that racing boat with wheels would in a road race.
Instead, it would be far better to rethink the application against the corporation's current needs and either rewrite it or modify it against those new needs while assuring it will work optimally in the Cloud. Specific advice on the Blog talking about these services was to point:
- Monetize every service as it is exposed — enterprises are a plethora of information on the applications, use cases, and users. Use that to refine the app, assess whether the cost to migrate and maintain the app is reasonable, and look for synergies and dependencies that may not be known before making the migration.
- Take advantage of an API ecosystem to reduce the cost of maintaining the app, increase the app's effectiveness and potential scope, and look for ways to streamline the related processes.
- Use analytics to identify new business opportunities and operational efficiencies. This use of analytics may result in decisions to buy rather than build the replacement app and either better spread the costs across defined funding groups and improve the effort's ROI.
- Adopt Cloud-native services to such an advanced extent that the profits are realized quickly and steadily with a shorter time to market. The Cloud potentially provides a level of flexibility and opportunity that on-premise deployments lack.
- Focus on creating a digital ecosystem that will be extendable as newer architectural principles are embraced.
An example of this approach was highlighted by TCS and how they use microservices with polyglots, coupled with a serverless approach to gain the most economical and operational advantages. Another resource to check out is the Modernization Propeller, which was jointly created by IBM and TCS to provide a microservices catalog to further help with Cloud migrations.
What initially attracted me to this partnership and effort is that it was from Tata and that large company is also the firm that owns the car company that built most of the cars I own (Jaguar).
But as I read through the material, I found their advice on point and consistent with advice my peers and I have been providing for years. Put effort into really defining what needs to be done before beginning a migration project so that the result is optimized for the Cloud platform and your company the way it is, not the way it was. While generally more expensive upfront, this approach can not only reduce the chance of failure but increase the economic advantages of the result both by lowering costs and increasing benefits.