Acronyms can be as treacherous as they are convenient.

Lately, for instance, both APM and UEM have received dramatic levels of attention across the industry -- with the common perception that UEM is a critical wing/adjunct of APM.

I would argue -- and have some admittedly old data to back me up -- that this is only a part of the picture. User Experience Management also has strong business impact, governance, service level and user productivity implications that transcend performance management.

I’ll be updating this research with a lot more emphasis on cloud environments and other technology and organizational shifts, with data collection starting in April. I’m reasonably confident that the strong business-centricity of UEM will remain consistent with our data from Q4 2008. Back then, we used QoE versus UEM, albeit we realized that we were already behind the time in getting our acronyms right. QoE was already passé.

The column/blog I write in May or June -- after the new data is in -- will prove me either wise or foolish in my convictions.

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.

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!

So to be clear, I do expect the role of applications management to rise in our April UEM data, but the main point here is that pushing UEM into being a subset of APM runs the risk of obscuring a much bigger picture.

The big story in the data so far is that the great majority felt that QoE/UEM was both a business and technology concern. And when it came to pushing towards one or the other, nearly twice as many thought it was primarily a business concern.

Let's hear from a few of those we spoke with back then:

"Google has set the expectations for end-user experience. It takes a fraction of a second to get hundreds of thousands of results. Setting expectations realistically is important. Make sure the customer knows what it is going to cost to get Google-like performance."

"The primary QoE initiative in our organization is meeting client expectations. Internal clients are much more demanding than external clients with respect to response times and a consistent experience." BTW, this was a legal firm, so internal clients were lawyers who were apparently far harder to please than the clients who paid them.

"QoE is mostly a problem for the stores. Most of our applications are home-grown to support how our products might impact our customers’ homes."

"As one project manager stated, 'the noise level from customer dissatisfaction finally reached the business VPs in the user community. Suddenly, IT was involved in trying to solve our QoE issues.'"

In running workshops on QoE and later UEM—I’ve always stressed dialog. My favorite way of summing it up is that it’s all about the “mammal sitting at the other end of the plastic.” This far transcends performance management to understanding real human priorities and behaviors, and how application and other services fit in with those demands.

This isn’t to say that performance management with strong reflexive insight into end-user experiences in terms of latencies, consistencies, transactional efficiencies, etc. isn’t a mainstay of UEM. These capabilities remain UEM’s technical heart and soul. But in themselves, they can greatly profit from added insights such as application usability and design, as well as how and when users interact with applications -- and what’s the business value or impact of the application itself?

Here are a few more quotes to underscore this:

"A Technical Advisory Services Council has been created which has equal numbers of IT and business staff. The purpose of the council is to discuss IT matters and provide a sanity check from the business about concerns and priorities. QoE is seen as a grass roots effort (not driven by a single incident or manager) with primary (non-technical) tools being focus groups and feedback surveys."

"My advice to others getting into QoE efforts is to have an on-going dialog with your business partners. Perception is really important. Don’t ignore the ‘soft stuff’ - meetings with your end users are completely critical."

"My recommendation is to get on the user’s level. You need to assume the end user’s mindset. Ask them (IT users) how they could be more productive."

But of course things do change.

Reactions to recent economic pressures, rightly or wrongly, have tended to push more IT organizations towards a more tactical, less strategic direction. And the advent of new technologies -- the growth of mobile computing and cloud in particular -- will put something of a new face on UEM.

How will cloud impact UEM? We have some insights into this from very current data, indicating that end-point awareness in terms of experience and service value is actually escalated due to cloud. After all, whether you’re doing internal or external cloud, IaaS or SaaS, how effectively your customers can utilize your services is the ultimate baseline for success. A cloud initiative that fails in UEM fails period! And I’ve even seen enterprise customers enforce meaningful UEM metrics with their SaaS providers -- and I don’t mean mere availability, although this is sadly an exception.

I welcome your input, both before and after our April data collection.

I’ve exposed my hand and my point of view. I suppose that anyone embarking on new research should do so. And although I may not be altogether free from some significance chasing, I will do my best to let the data and the deployment interviews speak for themselves.