What do Indonesian e-commerce company Tokopedia, Filipino media giant ABS-CBN, Australian broadcaster Seven Network, and Indian customer engagement leader Capillary Technologies have in common?

Beyond their success stories, they each faced a common tech challenge: siloed data caused by multiple monitoring tools.

Data silos represent a key contributor to poor customer experiences, and any amount of website lag or delay on mobile app performance can be the catalyst that pushes customers to shop elsewhere. In addition, having a single, unified platform to observe your entire technology stack seems like common sense but the reality for many businesses is far more complex. Legacy systems and processes, combined with siloed teams across various departments and locations can make the move to a single platform seem almost unattainable.

Recent research conducted by New Relic found that almost half (49.5%) of Asia-Pacific organisations learn about software and system interruptions via multiple monitoring tools, while 39.1% are still uncovering these primarily through manual checks/tests or incident tickets and complaints. Furthermore, organisations across Asia-Pacific were the least likely to have unified telemetry data (37.5%) and the most likely to have siloed data (45.1%). In fact, 15.3% were entirely siloed.

Despite this level of disparate data, Asia-Pacific organisations were the most likely to claim that they prefer a single, consolidated platform (55.3%) when compared with their American and European counterparts. This indicates that Asia-Pacific organisations see the value in a single consolidated platform but are not sure how to rationalise their technology investment to eliminate toil for developers.

The need for a single platform is clear, but how can organisations implement it successfully?

Separate the past from the present

Many larger enterprises with decades-old presence have only recently added a digital arm to capture the online market. They are saddled with legacy infrastructure originally designed for bricks and mortar operations. To make the shift, the best approach is to start with a modern application architecture and not try to retrofit; adopt observability tools for new platforms and don’t try to deploy them across older ones.

Start with what’s most important

Take a top-down approach and start with what’s most important to your business. It’s about understanding specific business KPIs and aligning the observability strategy to support them. What are the business processes that support customers or support revenue, or other strategic objectives? It may not always be the bottom line or profitability. For example, for government agencies, KPIs might be citizen sentiment and/or targets around service delivery.

Start with the top, then start following the dependencies: the processes, applications, and infrastructure. Consider the teams that are supporting those dependencies and ensure a solid foundation is built, to get to a unified strategy around all the different layers and ultimately provide those users a better experience where they can respond to issues quickly. They can then use observability in a proactive way to continuously optimise these environments.

Treat it as a journey

Don’t try to bite off more than you can chew. Removing multiple tools and creating a single source of truth takes time to execute properly. Furthermore, the move away from legacy on-premises architecture is significantly harder than abandoning more modern architecture, and may take years rather than months or weeks.

First, start with the basics: Focus on reactive use cases before moving onto proactive ones, and be patient. It will take time for engineers to learn new skills and unlearn their old habits. Remember, it’s a marathon, not a sprint.

Accept there may be compromises

There’s never going to be a scenario with a 100% like-for-like outcome — there must be room for compromise. No modern tool can instantly replace its legacy counterpart that has been adapted and expanded over time.

When modern technology is deployed, it’s essentially about starting from scratch. Businesses don’t have 10 years of experience running a new application, so teams need to observe and understand how it behaves, and respond to feedback loops. Did the change have a positive or negative effect? This will inform future decisions but can only be done with a solid observability foundation.

By Peter Marelas, Chief Architect APJ at New Relic

This article was first published by Frontier Enterprise