5 Pitfalls of Legacy Cloud Master Data Management
Not all cloud MDM systems are created equal. Although the term “legacy” is most commonly equated to on-premises systems, the same principles can be applied to the cloud. Legacy cloud systems, typically built prior to 2015, are not the same as cloud native systems. But what does the term “cloud native” mean, and why is it so important? The Cloud Native Computing Foundation provides an official definition:
“Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.
These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.”
Cloud native systems are architected from the get-go for resilience, scalability, and agility, while legacy cloud systems inherit old, unwieldy architectural issues that result in significant behind-the-scenes effort to manage, upgrade, and enhance. This slows down innovation, makes upgrades longer and more painful for customers, and prevents the system from scaling elastically.
Legacy cloud MDM systems suffer from these 5 common pitfalls:
- Infrequent upgrades
- Monolithic architectures
- “Noisy neighbors” in multitenant architectures
- Limited innovation
- Multi-vendor approach
Let’s look at how Informatica’s fully cloud-native MDM solution addresses each of these common pitfalls.
Pitfall #1: Upgrades happen infrequently (<3 times a year) and require downtime, which hinders productivity
Legacy cloud MDM applications tend to follow software development processes that are more like that of on-premises deployment, resulting in slower release cadences and bigger disruptions or more downtime when new releases are rolled out.
Cloud-native applications employ continuous delivery without disruptions. Cloud-native vendors are obsessed with automation to increase consistency and speed of upgrades for their customers and have made the necessary significant investments in people and technology to achieve high levels of automation.
But should you care about whether your cloud vendor can quickly and easily and automatically roll out upgrades?
Well, yes, if one of your expected benefits of cloud is continuous innovation with minimal disruption. Rolling out upgrades with minimal disruption requires cloud software to be architected to support changes in software and/or metadata while jobs are in flight. For example, think about what would happen if the system is upgraded with new Load behavior while you have a Load job running. You don’t want some of the records in a batch to be processed with the old logic and the rest with the new logic; that would be a mess. You need the system to complete the Load job with its original logic, so that the batch is handled consistently. Cloud-native MDM systems are designed to handle this.
Pitfall #2: Monolithic architecture with shared resources, unable to scale according to demand
Legacy cloud MDM applications have coarse grained modules that depend on shared resources and that are not independently executable. This is known as a monolithic architecture. The complete application must be deployed all at once, limiting the capability to automatically scale the application components according to increasing or decreasing workloads.
In contrast, cloud-native applications are built using a microservices architecture.
Microservices architecture allows for single components to be deployed, updated, and scaled independently from each other at runtime without any downtime. Horizontal scaling of microservices is triggered by request stimuli—for example, if many requests are hitting a service, more service instances can be launched to distribute the requests across more instances, and if the requests are decreasing, service instances can be shut down to free resources.
This automated elastic scalability is a critical component of a cloud-native MDM application so that you don’t have to prepare your MDM vendor ahead of time for bigger-than-usual loads.
Pitfall #3: “Noisy neighbors” and shared processes degrade performance, impacting speed, in multitenant deployments
Legacy cloud MDM applications often suffer from “noisy neighbor” problems in multitenant environments—put another way, when the processes of one tenant tie up resources, it results in response slowdowns for other tenants in the environment. This is typically the result of a monolithic architecture which is not elastically scalable.
Modern cloud-native applications support elastic service scaling, dedicated storage and compute, and tenant-specific scaling built to handle increases in demand without negatively impacting performance, providing you with a buffer against “noisy neighbors” in a multitenant environment.
If you’re considering cloud MDM, ask cloud vendors how they protect you from being impacted by whatever processes other tenants may be running.
Pitfall #4: New releases focus on fixes and enhancements, limiting innovation and new features
Legacy cloud systems are almost as difficult to upgrade and enhance as on-premises software. They do not easily support continuous innovation. And the technical debt of old architecture means that the development team spends more time addressing performance and other issues in existing code than delivering new functionality.
Cloud-native applications are supported by automated processes that allow new innovations to be delivered on a regular basis—say, every week or once a month. New features and functions are delivered in a non-disruptive way. The microservices architecture allows for services to be upgraded individually, and APIs are versioned for continued compatibility with existing interfaces after each upgrade.
You might think that continuous innovation isn’t important for master data management but consider the strategic importance of master data for business transformation; and in that light, consider the benefits of having a system that continually receives more intelligent fixes and more self-monitoring and that can recommend ways to continue to improve the quality of your master data.
Pitfall #5: Implementation requires multiple vendors, resulting in greater time and cost
An MDM system requires more than just the MDM application itself. You must be able to get data into and out of the system easily, in batch, real-time, or streaming modes. You must be able to ensure data quality by verifying, standardizing, and correcting data including address, phone, and email verification. You also must be able to have MDM participate in business processes and make it easy to manage master data and reference data.
Many legacy cloud MDM applications claim to provide all the capabilities needed, but in many areas their capabilities are not especially deep and to meet the requirements of more than the simplest use cases, you’ll require capabilities from other vendors, too.
Data integration, data quality, business process management, reference data management … these are all critical capabilities for master data management, so why choose anything less than best-of-breed for those? An all-in-one platform approach is key to delivering a fully cloud-native MDM system that gives you best of breed capabilities in each data management area for master data.
Informatica’s all-in-one cloud native MDM platform
Informatica recently announced cloud-native MDM SaaS 360 solutions, marrying a heritage of leadership with the most modern cloud architecture and technologies. Informatica addresses the pitfalls of legacy cloud to ensure the full benefits of the cloud are recognized.
Informatica’s 360 SaaS solutions redefine modern cloud-native MDM with an all-in-one, enterprise-scale, best-of-breed approach so business owners can reliably curate, discover, match, and democratize data. Learn more from product experts and industry thought leaders by viewing Informatica’s Customer 360 Summit, now available on demand.
