Oracle Buys End-user Experience Management Leader Moniforce

Oracle Buys End-user Experience Management Leader Moniforce

Oracle has acquired Moniforce, a European end user experience monitoring vendor. The Moniforce product is an appliance that sits on a mirror port of the switch that supports the web servers in the data center. The appliance watches for request/response pairs of HTTP transactions, and measures the response time delivered to the end user from the perseptive of the data center. This capability is largely identical to what HP has with RUM, CA has with Customer Experience Manager, CompuWare has with Vantage Agentless Monitoring, and the Coradiant offering.

The implication of this acquisition are twofold. One is that a major applications vendor has stepped up and taken ownership of the end user experience for its applications. No other major line of busienss applications vendor has done this to this extent yet, and there will certainly be reactions from Oracle's major competitors. The second implication is that "everyone" either has, or will shortly have the abilty to monitor the end user experience of HTTP applications from the perspective of the web server farm. Therefore this capability will shortly no longer be the basis of relevant differentiation in the end user experience monitoring market.

Bernd Harzog
CEO
APM Experts
bernd.harzog@apmexperts.com

Improving end-user experience

Below is a link to an article in ComputerWorld where I reviewed and compared several different important end user experience products.

Improving end-user experience

What Exactly Should We Measure?

From my other posts it should be clear that I do not think that the cover the waterfront approach used by frameworks is workable, nor do I think that monitoring every element of the application system gets us to an ability to accurately measure end user experience and assure, on an on-going basis, a good user experience. So, what should we measure, and how?

The answer starts with the following assertions:

1. Every action taken by every user of the applications system is important
2. Some actions taken by some users are more important than others

In order to approach the problem of end user experience measurement from the above two perspectives, we must be able to measure the following:

1. Who is the user? This means understanding the importance of each user relative to all other users.
2. What transaction is the user attempting to execute? This means knowing which transactions are critical, important, convenient, and irrelevant.
3. When an important user is attempting to execute a critical transaction, what is the experience of that user from the start to the end of the transaction. This includes the response time for each step, the total response time for the entire transaction, and all errors and messages that the user sees during the entire transaction.
4. When a user is executing multiple transactions from a technical perspective, but one from the users perspective, the entire interaction needs to be captured. For example, if a user is about to buy some shares of a stock (one transaction), but pauses before committing the transaction to do one more piece of research (a lookup that is technically a second transaction), both need to be looked at together to really understand the user's experience. If the lookup fails with a HTTP 404 error, and the user aborts the transaction, you will never know why unless you looked at both together.
5. Not only are individual transactions important, but their rate and performance relative to periods of time also matter. Each transaction has a normal rate for a time of day and day of week. If that rate and performance change relative to the norm, that needs to be captured and noted. Understanding that "something is different" is critical to starting the process of understanding why.
6. Understanding long duration transactions. When someone buys something from an online store, is the transaction complete when the user completes the checkout process, and the vendor charges the credit card successfully? Maybe it is from the perspective of the online e-commerce system, but from the perspective of the user, the transaction is only complete when the product is actually delivered, and maybe really only complete when the product successfully meets the need for which it was purchased.

In summary, measuring end user experience holistically, is much harder than capturing some response times here and there. As organizations start to do this, I predict that it is going to expose tremendous weaknesses in how the underlying systems are actually being managed and monitored. This will be a very bad thing for the incumbent infrastructure monitoring vendors who are charging customers a lot of money for products, that at the end of the day, are measuring the wrong thing (infrastructure availability). And, it will be a wonderful thing for new vendors more in tune to the emerging needs of customers who embrace true measurement of end user experience.

Bernd Harzog
CEO
End-User-Experience.com

The Irrelevance Of Elements

An executive (who will not be named to protect his guilt), once remarked to me, "Response time is an over-hyped metric. If you monitor all of the elements of an application system with a sufficient level of frequency and granularity, you will detect things that can cause response time problems before they actually do cause response time problems".

I could not disagree more. Monitoring every element of an application system (all of the hardware and all of the software) is both a hopelessly complex task and an increasingly irrelevant one. Let's deal with the complexity first. Exactly why did Enterprise Management Frameworks fail (or if you don't think that they have "failed" why are they hated by the people who pay for them and use them)? Answer, it is a hopelessly complex undertaking to try to keep up with how fast every aspect of the hardware and software industry evolves in one management product. For example most management frameworks do not do a good job with wireless networks, VOIP, .Net based applications, and virtualized servers. Why, because these things are all too new to have been properly integrated into the agents for the various platforms where these new technologies operate.

On to the point about irrelevance. The infrastructure (network, server hardware, and systems software) is becoming so redundant that failures in any single element of the infrastructure often just do not matter. There is either an ability to route around the failure, or an ability to shift the workload somewhere else (to another server in a load balanced farm).

The last point is that monitoring elements of the system is not only irrelevant, but also a misguided reaction to how the infrastructure has evolved. Since frameworks are not doing the job, each group that is responsible for each supporting technology (the database server team for example) gets their own tool. This is good for point tool vendors, but it does nothing to help solve the problem of ensuring good user experience. As a matter of fact having each team monitor their own slice of the applications system makes the problem worse, since people either waste time on things that do not matter, or they fool themselves (and their management) into thinking that everything is all good because their point product shows all green lights.

Perhaps it is time to rethink the problem entirely. Let's start the process with what matters, the ability of the users of the system to do their jobs. Let's measure that, and when it is degraded figure out why. Nothing else matters, does it?

Bernd Harzog
CEO
End-User-Experience.com

Measuring What Matters

Enterprises (large and small) collectively spend $7B a year for software and hardware to manage the performance of their systems. Well here is the ugly little secret. Precious little of the spending for management products and services has to do with what really matters - ensuring that the users of these systems can do their jobs. These systems for the most part measure things that are important to the technical team supporting a part of the system (the network, the servers, the J2EE layer, the database, etc.). These systems for the most part do not measure what really matters - the experience of the user trying to do his or her job. Measuring what matters means measuring:

• The performance at the presentation layer of the application system. So, if an application system has 50 web servers as the front end, performance measurement must occur on each web server and cover every user and every transaction. Sampling user experience with scripted synthetic agents is not sufficient.
• Detailed performance and utilization data from every layer of the application system (presentation. Business logic and database) and it must synthesize this data with the performance information collected at the presentation layer.
• Combining applications level information with infrastructure information (however collected) to be able to tell Systems Administrators if the problem is in the underlying infrastructure (network, server, OS, middleware), or in the application itself.
• Pinpointing the root cause of a performance degradation with a sufficient level of detail so that an application owner can go back to either the vendor or the in-house developer with proof that it is an application problem, and enough data to get the resolution process started.
• In addition to gathering performance information across the application system, it must be able to verify the integrity of specific transactions (this is the valid role for scripts).
  It must support at least one of the major web based applications architectures (Windows/COM+/.Net or J2EE).

We help enterprises identify the end user experience tools that they really need, and we help vendors meet the real need in the market. So, our focus is upon the unmet need for real end user experience management on the part of enterprises and the strategy development for vendors who desire to meet those needs.