In today's technology-centric world, customer expectations rise with every advancement in technology, and the pressure to meet those rising expectations is high. Companies that started building their software decades ago are struggling to keep up with the times and modernize their legacy applications.

To truly take advantage of cloud technologies, high tech companies can’t simply focus on the same hardware solutions they’ve built in the past. They need to think in terms of reinventing themselves, their business models and their products.

Without investing in enterprise transformation, High Tech companies risk leaving billions on the table. If they don't update their applications' architectures and migrate to the cloud (whether public, private or hybrid), businesses worldwide will be missing out on lowering their business costs and increasing their applications' reliability. If they do choose to shift to a cloud-first mentality, they'll have to decide what path they want to take to get there.

<<< Start >>>

A composable application architecture made up of packaged business capabilities (PBCs) are software components that communicate with each other via API calls and can be fully decoupled from each other without breaking anything.

<<< End >>>

Lift and shift: Is it the right fit?

One method of cloud migration is the "Lift and Shift" method. It involves rehosting an application in another environment, presumably a public cloud or private cloud hosting service, without altering the app's existing architecture. It can be a very tempting option for businesses because of three factors: effort, time, and money.

The migration process would be fast, relatively inexpensive, and cause minimal operational disruption. However, despite this option being the path of least resistance, it isn't necessarily the best option for every business. Though it is low-cost in the short term, it could prove to be high-cost in the long term because the application won't have been optimized to leverage the benefits of the cloud. For example, businesses used to tend towards over-provisioning resources.

Unfortunately, cloud hosting services typically bill companies by the resources they take up, even if those resources aren't being fully used. Therefore, if a business's overprovisioned application gets migrated to the cloud without alterations, the business is charged with a needlessly high bill. Gartner analyst Ed Anderson found that because of this oversight, businesses are spending an average of 40% more1 on their cloud costs than they need to be.

Another drawback of the lift-and-shift method is that companies who use it are often so focused on how quickly they want the migration done that they don't take the time to think about the full scope of the project. They'll focus on migrating their main application but forget to test the latency between the application's various dependencies against the new cloud hosting service. If they wait until their main application is fully migrated before beginning to test the latencies, they might end up with an extremely slow application due to the high latency between the new cloud hosting service and the application's dependencies. A slow application can jeopardize a business's relationship with its customers. Either the customer assumes the application is broken if it doesn't load within a certain amount of time, or the customer decides that the high latency is a deal-breaker and switches to a different application. Overall, this method might come with less risk, but it also leads to less reward.

<<< Start >>>



<<< End >>>

Cloud adoption with application re-architecting

Businesses willing to invest more time and money into their cloud migration might see it as an opportunity to revise and upgrade their application's architecture. Such businesses have two general methods they can choose from. The first method is a middle ground of sorts. It involves companies identifying key areas of their application that have low compatibility with the cloud hosting service, then allotting enough resources to optimize those specific areas to better leverage the advantages that cloud computing offers. No core changes are made, just optimizations. The business then shifts the newly upgraded application to the cloud hosting service. This method has a higher cost than the classic lift-and-shift method, but it eliminates the more considerable inefficiencies that can result from simply rehosting your application without any alterations.

The second method is the complete opposite of the lift-and-shift method. It involves businesses completely rethinking, redesigning, and rearchitecting their application to best leverage cloud-native features. Like the previous method, the company first takes time to identify where their application could better leverage cloud hosting services, but unlike this method, these areas can be of broader scope and include core functionalities.

During this step, they might find that only a third of their architecture needs refactoring. They could also realize that nearly all of it does. They then allocate enough resources to execute the refactor. Due to the potentially large scope of the project, this path requires the most upfront time and money. It could reduce routine costs for certain companies, saving them money in the long run.

For example, if an application uses logic that requires a substantial amount of resources to process and store its data, migrating the application with that logic, unaltered, to the cloud could cost the business a lot of money.

Often the cloud hosting service offers a more efficient way for an application to accomplish the same goal. If a business doesn't refactor their application to utilize that more efficient method, the company is losing a considerable amount of money every month. Most cloud hosting platforms have built-in scaling features, so if an application is already fully compatible with the cloud hosting platform, it would be simple for a business to scale quickly while maintaining the quality of its application.

Embedded intelligence

In order to make informed decisions, a business has to collect, analyze, and understand its data properly. Unfortunately, even after migrating to the cloud, many businesses have incompatibilities between their data management and core business applications. This incompatibility could lead to the data management application not having the necessary full access to the core application, and therefore won't be able to collect all of the operational and user data. If complete data isn't provided, the data management application won't be able to tell the core application's whole story. With fewer data points to go on, the business's leaders may make less informed decisions.

Suppose an application has a new feature, and users can navigate to the feature either organically or by an upsell elsewhere in the application. If a business simply tracks the number of users that navigate to the feature but not which avenue they're using, the business's leaders won't know if their upsell was an effective allocation of resources. Also, less up-to-date applications are missing out on an advanced use of data analytics: embedded intelligence.

Embedded intelligence is the ability of a product to analyze its own data, reflect on that data, and enhance its product performance based on that data. Even if a business wanted to add this to their application, it might be challenging to find compatible embedded intelligence software. To solve these incompatibility problems and improve business analytics, a business can adopt a composable architecture and utilize packaged business capabilities (PBCs) to construct its applications.

Composable architecture using PBCs

A composable application architecture made up of PBCs are software components that encompass an aspect of a business's needs. They communicate with each other via API calls and can be fully decoupled from each other without breaking anything. This is beneficial because if one of your PBCs is incompatible with another, you can always remove one and find a different one that fits your needs better.

Finding and using a PBC for basic business functionalities such as data analytics results in a much higher quality product for your employees to use compared to an in-house built product that will take unnecessary resources to make and probably won't be as user-friendly. The decoupling ability of PBCs makes them quite reliable. If one of them goes down, the others won't be affected. Site reliability engineers (SREs) can easily oversee a business's PBCs by detecting when a PBC is broken and determining if a particular PBC no longer fits a company's needs.

When migrating to the cloud, a business might choose the simple and inexpensive lift-and-shift method. However, if a business wants to stay competitive in today's fast-paced world, it should rearchitect at least part of its application during its migration to the cloud. Through the collective power of cloud services, artificial intelligence, data analytics, and packaged business capabilities, businesses have the opportunity to transform their legacy applications into futuristic and desirable business systems.

1 High Tech Narrative

<<< Start >>>



<<< End >>>

Jason Mitchell

Managing Director – High Tech, Cloud, Global


Deb Roy

Senior Manager – Technology


Nick Sidhu

Managing Director – Intelligent Cloud & Infrastructure, North America

Subscription Center
Subscribe to High Tech Perspectives Blog Subscribe to High Tech Perspectives Blog