All of us Application Performance Monitoring (APM) vendors continuously rant about how this new capability, or that new feature makes our particular APM solution even more powerful, compelling and cost justifiable (which reminds that I need to blog about a revolutionary new Foglight capability that correlates individual production java code traces directly to a replay of the associated individual user application session in Tivo fashion, but I digress…). While this is true (at least for Quest Foglight), and while I personally see a marked increase in recognition by most IT organizations that APM is a credible (thank you Gartner, Forrester, IDC, EMA, TRAC and other analysts), and now often even a required IT management discipline, most companies still struggle significantly to overcome entrenched organizational and process limitations that prevent institutionalized APM adoption.
Of course there are mavericks in many organizations who somehow “overcome the system”, and successfully leverage modern APM technology outside of the standard IT Operations processes to heroically rescue their business and IT counterparts from the brink of disaster. Sometimes, as with one global systems integrator Foglight customer, those maverick teams turn into permanent performance SWAT teams, who parachute into critical situations on-demand.
In addition to the maverick approach, many IT organizations purchase an APM solution, but in reality implement just a new flavor of traditional silo’d monitoring across the some subset of the typical administrative domains, which fits well into their existing organizational structure and standard incident management processes. Unfortunately, while these organizations purchased a solution under an APM vision, the only people tasked with true application support responsibility sit in a line of business somewhere outside of IT, where the app was developed or purchased.
Additionally, there is often no formal responsibility, tooling or processes put in place to connect those departmental resources into a formal, efficient incident or problem management process in concert with IT operations. The end result: continued daily/weekly bridge calls, and the associated business disruption and general pervasive lack of confidence in IT, which prevents the business from expanding at a faster pace. Oh, and of course this often comes with the obligatory APM vendor blame. There has to be a better way, right? Yes.
The companies that I’ve seen achieve the greatest success with APM adoption recognize the need for some small, but important changes to their organization and processes related to incident and problem management. Some companies formalize an “Application Support” function within the department(s) where the applications are developed/owned. With this model, it is important to have IT own and clearly define the process and any standard tooling to be used to coordinate incident and problem management efforts between those departmental Application Support teams and their central IT Operations counterparts, which can be challenging since these teams do not work under a common management structure.
More recently however, I have seen a new model emerge, where some larger customers create a formal, centralized Application Support function within IT (sometimes referred to as “Application Operations”, or “Web Operations”) as a peer group to the IT “Infrastructure Operations” team. These centralized Application Support teams are staffed with individuals with application architecture/dev backgrounds not commonly required for IT infrastructure Operations staff. Of course, even minor organizational and process changes like this typically require executive sponsorship to be effective, so the historic status-quo IT executive management position that “my individual teams will determine the tooling they need and how to use it” must evolve.
While there is typically no true need (and in reality, often no viable, technical way) to consolidate to a single “monitoring” solution to support all the needs across every IT production support team for any sizeable IT organization, there is an absolute fundamental requirement for an overarching strategy and technology approach. APM just happens to bring all of this right to the surface.
With a small amount of IT executive sponsorship and several minor IT organizational and process changes in conjunction with a solid APM strategy and solution, a whole new world of IT efficiency and visibility is within reach.
I have attached a few diagrams to illustrate some of the process and organizational changes described above. Enjoy.