I wrote previously that the networking industry was evolving from CapEx to OpEx to AppEx (Application Experience). There is certainly enough market buzz around applications if you listen to the major vendor positions. Cisco includes applications in its overarching moniker (Application-Centric Infrastructure), VMWare has blogged about application awareness as it relates to NSX, and even some of the peripheral players like F5 have embraced applications as part of their ongoing dialogue with the community.
If there is a shift to AppEx, what are the implications for the CIO?
The most obvious requirement to move to Application Experience as an IT driver is to define in explicit terms what application experience means. We need to define terms like performance and scale and even secure, and then break down the various contributions by system component so that we can understand who is responsible for what impact.
But a movement towards explicitly-defined application experience means a lot more than just instrumenting some infrastructure, collection statistics, and correlating the data.
What would have to be true for application experience to be a major driving factor behind architectural decisions? At its most basic, there would have to be widespread agreement on what the meaningful applications in the company are. Certainly you cannot create blanket application experience metrics that are applied uniformly to every application. This means that CIOs who want to prepare for a move in this direction could start by cataloguing the applications in play today.
Any such inventory should explicitly document how applications contribute to meaningful corporate objectives. For high-tech companies with a distributed development force, the applications might hinge around code versioning, bug tracking, and compilation tools. For companies that deal with tons of human resources, the most important applications might be HCM or even ERP. For companies whose job it is to maintain data, the applications could be more related to storage and replication.
Whatever the applications, the CIO ought to know those that are most critical to the business.
Note that the focus is on what is most important. There is not a real need to understand every application. Optimization is about treating some things differently. If you inventory 4,000 applications and try to make them all somewhat different, the deltas between individual applications become irrelevantly small. Instead, application experience will dictate that you manage by exception – identify the really critical or performance-sensitive stuff and do something special there.
For most enterprises, IT is treated as a service organization. If this is the case, the CIO will be expected to align application experience to the various lines of business. Not only will they have an interest in what the most critical applications are but also in what metrics are being used to define success. After all, it is their employees that are the consumers of that experience. This means that CIOs should include the lines of business in the definition of application experience.
But once you define the objective, you will be expected to report progress against it. It seems likely that these metrics would eventually become performance indicators for specific groups or IT as a whole. The implication here is that the metrics will help set objectives, which means that they will influence things like bonuses and budgets.
Leaders need to understand the likely endgame. The temptation when creating metrics in many organizations is to quickly pull together metrics that are good enough. But if you know ahead of time that those metrics will eventually drive how the organization is compensated, perhaps you ought to spend more time up front getting them right. And before setting targets, you likely want to spend real time benchmarking performance in a repeatable way.
Repeatable is the key here. Anyone who has instrumented ANY system will attest to the fact that metrics are only useful if they are repeatable. If running a report yields different results every time you run it, chances are that the report is not as meaningful as you would like. The ramification is that reports need to be run around well-defined scenarios that can be reproduced on demand.
The upside of all of this preparation is that the right set of metrics can be powerful change agents. They help focus entire organizations on a small set of tasks that can have demonstrable impact on the business.
The point here is that there is a lot of work that has to happen on the customer side before something like Application Experience becomes real. While it is incumbent on the vendors to create solutions that do something better for applications, customers should eventually be complicit in any shift in purchasing criteria. Those customers that start early will be in the best position to lead the dialogue with vendors.
And leading will matter because the efficacy of all of this will eventually rest on the existence of a solid analytics foundation. It is possible that clever customers can steer their vendors to work with specific analytics companies. That would give them a tangible deployment advantage, both in terms of acquisition costs (the solution is already on-prem) and operational effort.
For vendors, this means you ought to be looking around now to see who you will partner with. Choose wisely, because if the industry does go through consolidation and your dance partner is gobbled up, you might be left alone. The stakes might not be super high now, but when purchasing decisions hinge on a measurable Application Experience, you might think differently.[Today’s fun fact: In the average lifetime, a person will walk the equivalent of 5 times around the equator. You would think we would all be thinner.]