Why acquisition-driven Frankenstein APM product architectures should scare you this Halloween…

If you were tasked with developing a significant new business application with broad functionality for your company, would you start from scratch, or try to patch your solution together from 2 or 3 other partial applications that overlap in functionality? Which route do you think would deliver a cleaner, more robust and useable end product? Your answer may depend upon how much time you have to deliver the application.

Interestingly, Performance Monitoring vendors often face the same dilemma, when deciding whether to expand their product capabilities via acquisition vs. organic development. APM is a particularly challenging technology area for this type of decision, due to the high requirement for tightly integrated, highly correlated, end-to-end data from user experience to application code execution to databases to underlying middleware platforms, OS, hypervisor and other infrastructure. While all of this depth and breadth and extensibility is essential for APM, these capabilities must also be carefully balanced with usability to avoid the pitfalls of an overly complex solution.

At the end of the day, all APM vendors ultimately attempt to do the same thing: they each collect end-to-end data about your application performance, and then attempt to correlate and visualize that data in the most compelling, intuitive way possible. To do this effectively requires an overall data model that enables high-speed collection and correlation of low to ultra-high granularity/fidelity data, which means functional expansion by acquisition typically requires significant replatforming effort. Without that extra development integration and re-platform work, you end up with disconnected data sets, multiple management server technologies and consoles, and a raft of other solution challenges that ultimately limit how far users can go with the solution. Many vendors play games here, and pitch some stand-alone component of their solution as a sample of the fully integrated, end-to-end solution; but don’t get spoofed. Look for a common solution architecture that enables true data level collaboration between your DevOps, Ops, and IT administration teams involved in day to day incident management triage/combat against the ghouls and goblins attacking your application performance.

Anonymous