IT@Intel Blog

2 Posts tagged with the client_management tag
Click to view John Dunlop's profile
2

The old axiom "work expands to fill time" seems to parallel a truth about client computing: capabilities expand to consume available resources. As an Enterprise Services Architect responsible for Intel's IT client architecture, I have seen first hand how IT shops, software vendors, and users manage to throw everything but the kitchen sink into client systems only to be surprised by the resulting hit on performance. Let's face it: at most companies, client performance is an after-thought that becomes important when people start screaming. Making matters worse, everybody wants to dictate what needs to be on the client, including business, productivity, communication and collaboration applications, security & manageability agents, connectivity managers, backup clients, personal user applications, and more recently virtualization applications.

It's time to break free of reactive performance management "tiger teams" and get serious about addressing client performance in a more proactive way. Intel IT has begun to take a much more comprehensive view of client performance and has instituted a new framework for client performance management. Here are ten key learnings that you may be able to use at your company.

1. Form a client performance virtual team (v-team).
This step is first on the list for a reason. Client performance cannot be approached from only one perspective, otherwise it wouldn't be such a difficult problem. Form a virtual team consisting of at least one person from each of the following areas: client platform engineering, security & manageability engineering, client support (helpdesk), release management, human factors engineering, and enterprise architecture. To keep us on task, our client performance v-team has the mission "to drive an intentional approach to client performance management".

2. Develop a process and identify tools to measure performance, establish benchmarks, and set performance targets.
This is a discipline that needs to be baked into your client engineering processes. In order to determine what performance should be expected for any generation of client in your environment, you first need a baseline for comparison. The best time to develop this baseline is when your next generation client is ready for deployment and performance has been optimized. Industry and/or third-party benchmarking tools can be used to form part of the "performance profile" for you latest release. The choice of benchmarking tool(s) is less important than that you pick at least one and begin documenting the baseline performance of your clients. Data collected in a pilot under real-word conditions will also be useful in the baseline profile. The goal is to end up with something that can be used in the future as a yardstick for performance troubleshooting on the same generation of clients and for setting targets for the next generation client.

3. Develop a process and identify tools for tracking and reporting platform performance on the installed base of clients.
This is related but different from the last one and more difficult to pull off without further impacting performance. Benchmarks and performance targets are important, but those are established in lab conditions or in controlled tests and created only occasionally. Here we need to actually instrument the client and provide supporting infrastructure to actually collect data from our live clients. To do this, you are probably going to need some sort of agent running on the client. The results from this data collection and aggregation ought to correlate with the feedback you are getting from the helpdesk regarding their top performance issues. One related idea we are considering is to deploy a tool that allows the user check a performance status indicator on their desktop and/or allows them to push a button that sends a snapshot of their system status to the helpdesk when they are experiencing a performance issue.

4. Dedicate resources to forward engineering of performance enhancing capabilities.
There are a number of emerging technologies and capabilities that can actually deliver improved performance on the client, mostly under the general heading of QoS. For example, there are some third party products that will help with resource and process prioritization. There are also new capabilities baked into Vista that can be leveraged to improve performance including i/o prioritization and client-side policy-based network QoS.

5. Establish and maintain a strategic client performance capability roadmap.
A strategic capability roadmap for client performance will help by defining targets and setting context for engineering activities. Many of these capabilities we've discussed above, including those that enable performance management and those that enhance performance. Such a roadmap can also be used to drive application vendors to improve the performance of their applications.

6. Continuously validate platform performance against established benchmarks.
Modify your client release management process so that a comparative analysis can be done between your performance benchmarks/targets and the actual performance of the new client platform. You'll need to ensure that the benchmarking methodology you developed earlier can be exactly reused by the QA team.

7. Institute an ongoing continuous improvement process.
Establish a rhythm for taking what's learned about performance from PCs in the wild and incorporate the fixes, BKMs, enhancements, and optimizations into the client build engineering process for future releases.

8. Don't play chicken with your PC refresh cycle!
You know how people still do things that they know they're going to regret? Exactly. If you know what the right PC refresh cadence is for your environment, don't mess with it! The school of hard knocks has taught us that when we stretch the lifetime of our PC fleet, we end up paying for it in the end with spikes in helpdesk call volumes, above average failure rates, and complaints of performance degradation. The temptation is great to put off spending for a quarter or two or hold off to intercept a new version of an OS or new hardware platform, but this is a losing strategy that will probably land you in tiger team **** and will end up costing more in the long run.

9. Map out the client ecosystem and figure out where you can eliminate redundancy.
Take a fresh look at all the capabilities and products that are either installed on your client or that exist in the infrastructure that impact the client. This way you can identify where you may have redundancy that can be streamlined. For example, do you have two or more manageability agents with overlapping functions? Can you live with one even if it means giving up a feature or two? Don't forget infrastructure services that impact clients from afar. "Agentless" performance data collectors, for example, still have a performance impact on the client.

10. Establish client integration standards.
Assuming you have a healthy governance process, standards can act as both sword and shield to protect your client platform from being overrun by the barbarians. Like your city's building codes, these policies and related guidance can set a bar for application owners and service providers so they understand what is required and expected of them before they try to land anything on the client. Some IT shops have developed a "minimum security specification" that stakes out the absolute bottom line security controls that must be implemented in a given solution. Consider establishing a "minimum performance specification" to help educate application developers & vendors about performance optimization on your clients.

2 Comments Permalink Tags: client_management, client_architecture
Click to view John Dunlop's profile
1

As this is my first post in this forum, let me start by introducing myself. My name is John Dunlop and I am an IT Enterprise Service Architect responsible for Intel's IT client solution architecture. I've had this role for less than a year, having previously been responsible for some of our identity & access management services, as well as other backend core services. What an exciting time to have made the shift to the client side of IT! To say that there have been considerable and accelerating advancements in client usage models and application delivery models is truly an understatement.

Historically the most interesting and divisive discussions of client architecture have revolved around the debate over thin versus thick clients. Both models have their advantages and disadvantages, of course, but ultimately (as all IT architects know) it's all about enabling the business to have their cake and eat it too. We need to provide a client that is robust enough to survive network connectivity or performance issues, enable an increasingly mobile workforce, support data center consolidation, and satisfy the consumerization and personalization trends that are forcing IT to make more and more compromises to keep customers happy. On the other hand, competitive pressures drive IT budgets ever lower, keeping manageability center stage for providing TCO reduction and making IT managers crave more and more control over the client. Neither thin nor thick clients ultimately deliver on all of their promises, partly because the world has never been that black and white and one size rarely fits all.

Enter virtualization. Now, some will point out that we've had "presentation layer" virtualization solutions for decades, but again, this shifts us squarely into the realm of thin clients which simply don't serve our mobility needs and shift costs to the infrastructure. The benefits of true, on-board virtualization capabilities were immediately apparent on the server, but client virtualization wasn't taken seriously (as scalable) by many until fairly recently. Sure, you could run a guest OS on a client host OS for training purposes, or to do some specific task that wasn't supported on the host OS, but there was substantial overhead from a performance standpoint, and let's face it, the average user was never going to be satisfied with all the complexity and effort of moving between host and guest. Ever notice how it always seemed to be IT people using a virtualized guest OS for some constructive end? Improvements in technology (e.g. dual core, Intel VT) have meant substantial mitigation of the performance concerns, and the competition to deliver more and more capabilities and transparency in software hypervisors is creating a virtual arms race for the virtual desktop. It is amazing to see how far we've come when when you can run apps in two different operating systems simultaneously as they float side by side on the same desktop, allow cross-registration of applications, and share file systems, task bars, paste buffers, etc., etc.

Here's where you get that cake. Rather than continuing to evolve that tightly-coupled fat client architecture you've built a career around (so when are you planning to upgrade to Vista?) or continuing to tell your users that mobility is overrated while you shift client support costs to the network and data center with your antiquated thin client strategy, let's think outside the box for a minute.

Virtualization is about abstraction, and there are several layers where you can exploit abstraction using existing virtualization technologies and products. The most obvious one is between the guest OS and the host OS or hypervisor. This abstraction layer may, for example, allow you to change your client hardware procurement or provisioning model. Even a decision made to leave those business processes alone can be made confident in the knowledge that changing that decision later doesn't require a complete redesign of your client solutions. Some companies are even thinking about discontinuing the practice of providing laptops to mobile workers, opting instead to give them an annual stipend to purchase their own systems with their own OEM support contracts and a host OS they can do with as they please.

Virtualizing the workspace, even if that remains a tightly-coupled OS and application solution stack for the time being, makes that workspace transportable across devices, easier to recover, even potentially resident on a thumb drive. Because the user has a host OS to horse around with, you can finally lock down that work environment like you've always wanted. And, now you can provide a variety of workspaces through virtualization, including productivity and collaboration, engineering, manufacturing/shop floor control, etc. Making the framework of your client more modular means greater agility for your business, and you can finally begin looking at the workspaces you provide as true services.

And what about the tight integration of those applications? Another abstraction layer is between the applications and the guest OS. New and old capabilities and techniques can be employed to virtualize those applications, albeit not without some elbow grease within the greater IT organization to stop developing and/or deplolying proprietary or OS-dependent apps to the client. New IT policies that promote standards and provide guidance about the most appropriate forms of application virtualization and application delivery would be an excellent start. Writing applications on Java VM for example, or at least not using proprietary browser extentions in web apps would go a long way toward making applications available across workspaces and operating systems. Even for natively installed applications, adherence to standard data object types and document formats will provide at least the look and feel of virtualization which may be good enough in some cases. I don't have time or space here to get into the merits of Software as a Service (SaaS), but there is a clear paradigm shift occurring in the application delivery space that can support cross-platform "virtualization" of applications, and new technologies are even allowing for the caching of streamed applications that can run even when disconnected from the network!

Finally, and this may be the hardest abstraction layer of all, there is the holy grail of data virtualization. Imagine thinking about data as being associated with users rather than devices. Why are we still thinking in terms of client backups? I want my data to be available no matter what device I use to run my workspace. If I have a problem with my device or workspace, and a new workspace is provisioned, streamed, or otherwise made available to me, my data should be there as well, protected by some network service responsible for managing my data and serving it up to me no matter what device or workspace I may be using. I must admit that I haven't looked into the options in this area much yet, but I fear this is an area that lacks maturity from a client mobility perspective.

Naturally, there are significant manageability and security implications for this type of architecture. Hey, I never said this was easy! Many products are coming to market, however, to complement virtualization products to fill these needs. Figuring out how to solve these challenges is worth some time and effort. Client virtualization is not a fad; rather it is an evolutionary step forward that will provide IT and the businesses they support with newfound agility and competitive advantage in terms of lower integration costs, faster turnaround time, and improved user experience.

1 Comments Permalink Tags: client, virtualization, client_architecture, client_management