The Main Performance Problem

Dennis Drogseth’s post The Many Dimensions of User Experience Management (UEM) is very indicative of the main problem we have in performance: people thinking about many small specific performances, but we have just one PERFORMANCE. It depends on many different components and manifests itself in many different ways, but any attempt to decompose it results in silos and losing some important parts of the whole.

From the post: When we asked “What is your primary driver?” Better application performance and triage came in fifth, with only 13% of the votes. Employee productivity topped the list at 23%, followed by business competitiveness and/or revenue at 20%. Better support for services delivered over the network came in third, and brand protection and customer satisfaction came in fourth.

Well. Ask , for example, business users about JVM performance and it probably won’t get into the first hundred of issues they care about. Does it prove anything? No. They care a lot about it if they use J2EE systems, but just don’t know about it (except maybe a few most curious).

“Employee productivity” heavily depends on application performance. ” Business competitiveness and/or revenue” is related to application performance. “Better support for services delivered over the network” – not sure what it means, but performance also comes to mind. “Customer satisfaction” – performance is a pretty major component. And even with “brand” quite may be impacted by bad performance. Probably business users (and not only business) don’t care much about performance when it is good, but as soon as performance degrades, it immediately jumps on the top of everybody’s priority list.

I, of course, don’t want to say that performance is the main thing in business – if you don’t have any business, you may not be concerned with performance. But as soon as you do, application performance would impact all parts of your business. But you notice it only when it is bad (and usually it will happen soon if you don’t take care).

Then the post says: Similarly, when we wanted to understand which organizations or groups within IT and the business were behind UEM or QoE, the Help Desk/End User Support came in first, Customer Experience Management came in second, and Applications Management and Network Operations were tied at third and fourth place.

And when asked which organization is likely to DRIVE the overall QOE/UEM initiative, the first five groups were: Line of Business, Customer Experience Management, Process Management and Compliance Professional, Help Desk, and Service Management.
Applications Management came in seventh, one percentage point after Infrastructure Management!

Yeah, exactly proves the point: there is no organization/group responsible for performance today. Not sure what “Application Management” is (I don’t recall seeing such group – app admins?). And it is not surprising that people don’t put such group to drive such initiative – I guess perception is that such groups are groups of IT geeks doing something with computers, not caring about business, and starting to do something only when would be told by CIO to fix it (that, unfortunately, often is close to the truth).

How it relates to concept of Application Performance Management (which is rather concept for the moment)? It just proves that it doesn’t exist in practice (at least in its ideal form). Usually there is no organization responsible for it (as holistic concept, in conjunction with business).

What are end-user response times (what EUM monitors)? They are external symptoms of application performance. The only part of application performance end users care about. The tip of the iceberg. If we are saying that we want to manage application performance, would end-user response times part of it? I have no doubt it would. Otherwise the whole concept doesn’t make sense.

The post states: User Experience Management also has strong business impact, governance, service level and user productivity implications that transcend performance management. Yes, performance has “business impact, governance, service level and user productivity implications”.

So the data provided in the post, by my opinion, proves two things: business cares about performance a lot, but there is no any reliable structure in place to care about end-to-end performance.

Actually I am rather confused by the term User Experience Management. I understand what it is User Experience Monitoring or End User Experience (which usually used in the context of measuring response times). But how would you manage it? You may manage your application/systems which would improve response times. Unless you just saying that you want to use the name User Experience Management as an umbrella name covering all related to performance (including APM, Capacity Planning, etc., etc.) – which maybe an option, but it doesn’t look like it is used this way. Or maybe User Experience Management is used as a wider term including usability, UX (User eXperience), etc., which usually relate to UI design? If yes, then it indeed includes important factors not related to performance and only partially overlaps with APM – but then I am not sure why we compare EUM with APM.

Ian Molyneaux’s post The Case for the CPO brought the topic of a person responsible for performance to its extreme. Great idea, but… How far are we from there? Forget CPO, but just having a person (or persons) responsible for end-to-end performance and building up the process assuring such performance? See job posting – have somebody seen any position saying that we need a person to drive performance in our organization (and meant it)? I haven’t. All positions are for a specific silo team or for consulting. So it looks like it would be awhile until we see a more holistic approach to performance (whatever name would be used for it).

5 Responses to "The Main Performance Problem"

Five Blogs – 23 March 2012 « 5blogs says:

March 23, 2012 at 12:46 am

[…] The Main Performance Problem Written by: Alex Podelko […]
Andy Hawkes says:

March 23, 2012 at 12:47 am

Great points and I totally agree. I think the impact of this is hugely underestimated and generally ignored. Looking back over my own career, I figure my productivity at big companies averages maybe 15-25% what it is at small companies, and the shoddy performance (and poor fit) of so many “enterprise” applications are one of the main reasons. We’ve all been there. The aggregate cost in lost productivity must be huge.

The inertia in those big IT silos is so bad though, I doubt anything short of a “chief” something-or-other would be able to crack the whip hard enough to bring about change.
William Louth says:

March 23, 2012 at 7:12 am

What worries me more about this is that the focus seems to shifting away from monitoring (and managing to some extent) what is under our control to attempting to manage (cough monitor) what is not under our control (to an large extent) but has much more “meaning” and “visibility” internally to the ever growing segment in the performance management industry that have “don’t have me think” printed on their forehead if not t-shirt. Performance is very much like supply chain management and yes getting these goods to the customer on time is important but this should drive engineering efforts along the supply chain and not be just at one end point because its easy to comprehend for some and makes everything look like a black (or green or red) box (which is gooooddddd for don’t have me think kind of people).

We need to take a holistic approach because efficiencies in one point in the chain might appear to allow greater flow when in fact it can have the complete opposite impact because of implicit feedback within the entire chain. Its the outliers I worry so much about and these tend to originate in some form or another from the backend and such feedbacks (and signals) kick in.

Does that mean we need end to end tracing? NO at least not as prescribed by many of the BTM/APM vendors today. We need to first observe, model, understand and manage each point in the chain in terms of in and out flows and how the behavior is impacted by changes in these and how behavior changes internally impact these transgress points.
Tyson says:

March 23, 2012 at 11:28 am

Most of the time, application performance has to do with end-user experience as Mr. Drogseth says. But not all the time! I was speaking with one of our ExtraHop customers who runs IT operations at a leading SaaS provider. He said he wasn’t just concerned about speed or response times, but also about driving down the cost of IT in general. He said, “We have to be able to complete the same amount of work tomorrow with less resources than we used today.” This is the case where IT is intrinsically part of the service or product provided. If they can identify and eliminate bad talkers on the network, inefficiencies in the database tier, and move more workloads to the data cache, then that translates directly to their profit margin or ability to undercut their competitors in terms of price.

I love your captcha, btw!
Mike Schoeffler says:

September 25, 2013 at 6:43 am

Measuring effects of performance in a holistic fashion can be a wicked problem. Finding a common currency that works across different aspects of performance (like dollars) can help.

For customer-facing websites (where I specialize), you need to properly attribute value to various customer interactions (mainly, buying stuff) – easy to mangle this step. Then, gather up data (take care to avoid erroneous data and confounding factors). And finally, build characteristic equations to relate everything together.

Employee systems (like BI) bring a new set of challenges. Businesses have attempted to measure customer revenues, but not speed-related costs. Wait time, context-switching, etc? A new level of tricky.

Leave a Reply