Procurement decision-makers get barraged with companies declaring that they are “Born-in-the-Cloud” and touting the benefits vs. applications that have been developed for on-premises then later adapted for the cloud.
The big question for procurement leaders as they evaluate software from their perspective: Does it make a difference when software is born in the cloud? Sometimes. More often, it opens up a whole different process of discovery and evaluation.
Not long ago, it was simply assumed that technology would be installed on customers’ in-house systems and supported by their IT teams. Most of the big ERP systems began that way, running in their clients’ data centers. That’s one of the reasons it was historically challenging to install upgrades: for each customer, every revision became a unique project because of their configuration, in-house skills, budget, and more. And customers couldn’t always incur the time and costs, so sometimes they’d skip installing new versions.
When an application is Born-in-the-Cloud (also called “cloud-native”), it means it was designed solely for cloud delivery. It means that all the IT assets of a provider have always been in the cloud.
These applications leverage microservices architecture and containerization, enabling quicker development cycles, easier updates, and rapid deployment of new features. Overall, the user experience and interface have been designed to be easily portable across cloud platforms.
If you are a chief procurement officer (CPO) or business leader trying to decide between an application that is Born in the Cloud and one that uses a hybrid or on-premise model, or is in the midst of a transition, how do you evaluate what is best for your firm? Here are some points to consider:
Born-in-the-Cloud Characteristics
- Cloud-native applications are built to be agile, efficient, and cost-effective. Since they are developed to run in the cloud from day one, they don’t ever incur the cost and disruption of transitioning to the cloud. They are designed to scale seamlessly and should be able to easily adjust resources based on demand, allowing for more efficient performance and cost management.
- AI and ML rely on large datasets to train applications, more than you’re going to have in your data center. So if the application you are evaluating is AI- or ML-based, it should automatically be running in the cloud.
- Cloud-native applications can be updated quickly and efficiently by comparison to on-premises apps. Providers are not dealing with individual instances set up at each client site; upgrades and revisions take place for all clients at the same time.
- Cloud providers invest heavily in security measures, providing robust protection that would be challenging for individual organizations to implement on their own. They are bigger targets than your individual firm, but apply many more resources to ensure security.
- Cloud-native apps assume distributed systems, so bottlenecks are minimized and failures can be easily detected and resolved, yielding improvement reliability and resilience.
- These applications are built from the ground up with cloud-based usage in mind, resulting in modern interfaces and functionality optimized for cloud environments. They are designed to be easily integrated with other tools and systems and should be efficient in handling and accessing content.
- Storage is not restricted to on-premise machines nor are files or information shared manually. So information retrieval is generally speedy.
Ask Cloud Wars AI Agent about this analysis
Risk Mitigation
CPOs, as well as CIOs, are accustomed to managing direct relationships with suppliers, but with cloud native, the cloud provider that hosts the software is a third party in the mix. Data security and other elements are highly dependent on the deal that your supplier has with their cloud services provider. This means CPOs and CIOs have new information to evaluate that is unique to operating in the cloud:
- Who owns the data?
- Is the product platform-independent? Born-in-the-cloud applications are often designed to work across multiple cloud platforms, providing flexibility and avoiding lock-in to any one cloud provider. What happens to your data if your application developer moves to a different cloud provider?
- What are the costs for a transition and who pays?
- It’s not enough to ensure that your chief risk officer is comfortable with security and the protocol in place on day one; there needs to be a communication vehicle, service-level agreements, and a triage plan if a breach occurs or a policy change takes place within the cloud provider
- Because cloud-native businesses are typically newer than traditional tech partners and may be cash flow negative, you need to understand their financials and ensure that your CFO will not automatically reject the choice of a cloud-native provider because they don’t have the financial security of a more established firm. This is a big mindset change for some CFOs, and it’s important to bring them on the journey with you from the early stages, to avoid having your recommendation turned down because the supporting financials are not acceptable based on their normal evaluation processes.
- When you obtain references from companies running in the cloud, consider the composition of their clients versus the size of your firm. Traditional partners are more likely to have deeper relationships with enterprise clients because they’ve been around longer while companies born in the cloud are more likely to have small-to-medium clients as references.
- Software that was originally designed for on-premise use can stumble when it is transitioned to the cloud. The process of adapting pre-existing software to a high standard of operation in the cloud is complex, and it is normal to encounter glitches.
- Buyers should be aware that some cloud transition costs are likely to be embedded in pricing when purchasing software that started as on-premise. Adding that as a discussion point could open the door to getting some financial relief during the life of the license.
No matter which model your potential supplier follows, understanding the differences and asking the right questions ensures you’ll make the best decision for your company.
The AI Ecosystem Q2 2024 Report compiles the innovations, funding, and products highlighted in AI Ecosystem Reports from the second quarter of 2024. Download now for perspectives on the companies, innovations, and solutions shaping the future of AI.
