Tag Archives: End User Experirence

Explaining and Expanding the SLA Conversation

Service Level Agreements (SLAs) come in many forms and descriptions in life, promising a basic level of acceptable experience. Typically, SLAs have some measurable component, i.e. a metric or performance indicator.

Take, for example, the minimum speed limit for interstates. Usually, the sign would read “Minimum Speed 45 mph”. I always thought the signs existed to keep those who got confused by the top posting of 70 mph (considering that to be the minimum) from running over those who got confused thinking 45 mph to be the maximum.

It turns out the “minimum speed” concept is enforced in some states in the U.S. to prevent anyone from impeding traffic flow. For those who recall the very old “Beverly Hillbillies” TV show, I’ve often wondered if Granny sitting in a rocking chair atop a pile of junk in an open bed truck, driving across the country might be a good example of “impeding the flow of traffic” at any speed. Although, from the looks of the old truck, it probably couldn’t manage the 45 mph minimum either.

In the world of IT, there are all sorts of things that can “impede the flow” of data transfer, data processing, and/or data storage. While there’s nothing as obvious as Granny atop an old truck, there are frequently Key Performance Indicators (KPIs) that could indicate when things aren’t going according to plan.

Historically, IT SLAs have focused on a Reliability, Availability, and Serviceability (RAS) model. While not directly related to specific events/obstacles to optimum IT performance, RAS has become the norm:

  • Reliability – This “thing of interest” shouldn’t break, but it will. Let’s put a number on it.
  • Availability – This “thing of interest” needs to be available for use all the time. That’s not really practical. Let’s put a number on it.
  • Serviceability – When this “thing of interest” breaks or is not available, it must be put back into service instantly. In the real world, that’s not going to happen. Let’s put a number on it.

In the IT industry, there exist many creative variations on the basic theme described above, but RAS is at the heart of this thing called SLA performance. The problem with this approach from an end-user standpoint is that it misses the intent of the SLA, which is to ensure the productivity/usefulness of “the thing of interest”.  In the case of a desktop, that means ensuring that the desktop is performing properly to support the needs of the end user. Thus, the end user’s productivity/usefulness is optimized if the desktop is reliable, available, and serviceable… but is it really?

Consider the following commonplace scenarios:

  • The desktop is available 100% of the time, but 50% of the time it doesn’t meet the needs of the end user, e.g. it has insufficient memory to run an Excel spreadsheet with its huge, memory-eating macros?
  • A critical application keeps crashing, but every call to the service desk results in, “Is it doing it now?” After the inevitable “No” is heard, the service desk responds, “Please call back when the application is failing.” This kind of behavior frequently results in end users becoming discouraged and simply continuing to use a faulty application by frequently restarting it. It also results in a false sense of “reliability” because the user simply quits calling the service desk, resulting in fewer incidents being recorded.
  • A system’s performance is slowed to a crawl for no apparent reason at various times of the day. When the caller gets through to the service desk, the system may/may not be behaving poorly. Regardless, the caller can only report, “My system has been running slowly.” The service desk may ask, “Is it doing it now?” If the answer is “Yes”, they may be able to log into the system and have a look around using basic tools, only to find none of the system KPIs are being challenged (i.e. CPU, memory, IOPs, storage, all are fine). In this scenario, the underlying problem may have nothing to do with the desktop or application. Let’s assume it to be the network latency to the user’s home drive and further complicate it by the high latency only being prevalent during peak network traffic periods. Clearly, this will be outside the scope of the traditional RAS approach to SLA management. Result: again a caller who probably learns to simply tolerate poor performance and do the best they can with a sub-optimized workplace experience.

So, how does one improve on the traditional RAS approach to SLA management? Why not monitor the metrics known to be strong indicators of a healthy/not so healthy workstation? In this SLA world, objective, observable system performance metrics are the basis for the measurement of a system’s health. For example, if the CPU is insufficient, track that metric and determine to what extent it is impacting the end user’s productivity. Then do the same for multiple KPIs. The result is very meaningful number that indicates how much of a user’s time is encumbered by poor system performance.

In the case of SLAs based on observable system KPIs, once a baseline is established, variations from the baseline are easily observable. Simply focusing on counting system outages and breakage doesn’t get to the heart of what an IT department wants to achieve.  Namely, we all want the end user to have an excellent workspace experience, unencumbered by “impeded flow” of any type.  The ultimate outcome of this proposed KPI vs RAS based SLA approach will be more productive end users. In future blogs, I will expand on how various industries are putting into practice a KPI based SLA governance model.

Learn More About Maximizing User Productivity

How does Office 365 perform across Windows operating systems?

Modern users have the choice between a variety of Windows OS and Office versions. In relation to this mix, a common question we have come across in the past is “How does Windows 10 performance compare with Windows 7?” While we have addressed the situation in the past, it remains a popular question to this day. However, users are now becoming curious about the performance implications of Office versions against the operation systems. Through analysis of SysTrack Community data, we were able to reevaluate Windows 7 and Windows 10 performance implications against Office 365.

A feature that Windows 10 has is its integration with various components of Microsoft’s cloud portfolio. With this new component, we felt compelled to look at how Office 365 ran against past operating systems and how past versions of Office, specifically Office 2013, ran against current operating systems. Office 365 may look very similar to older versions, there are quite a few notable differences. While Office 2013 required a product key, Office 365 handles licensing more efficiently for users, potentially allowing each job role to be given a best fit licensing level. This is just an example of how Office 365 is now closely reliant on the cloud. The cloud allows Office 365 applications to be available from any device and encourages collaboration among users while Office 2013 requires a local installation. Office 2013 did not allow for as smooth of collaboration, requiring the user to share files that have been saved locally or manually stored in a place that can be reached by others. Finally, with Office 365 being software-as-a-service, it has improved security and user experience by seamlessly providing small, frequent patches.

With all these updates to Office 365, how does it affect the overall performance characteristics? We ran a comparison of Office 365 against Office 2013 with different operating systems to see how their load times compared (displayed below in Figure 1).

Figure 1

While it is interesting that Office 365 seems to take a slightly longer time to load, it is mostly due to external connectivity and tying the user account context for Office 365 to the application itself. However, looking at application stability (displayed below in Figure 2), Office 365 has significantly fewer faults than Office 2013.

Figure 2

As displayed above, Office 365 faults significantly less in Windows 10 than Office 2013. This can be a result of both being “as-a-service” products ultimately resulting in less downtime users (thus a higher end user experience) and less maintenance for IT administrators. It can be concluded that while Office 365 takes a little more time to load, it is more stable than Office 2013 among the various operating systems.

So what does all this analysis mean? Ideally, Windows 10 and Office 365 should be used together to achieve high end user experience. Office 365, overall, is more stable providing less application faults. However, other operating systems are also compatible with Office 365 despite the slightly longer load time. To evaluate readiness for a Windows 10 migration, or performance monitoring, check out our free Windows 10 assessment, with the addition of SysTrack to provide the transparency of end user experience monitoring.