A Conceptual Desktop Architecture

I’m thinking hard about desktops, desktop technology and desktop architecture at the moment. With some of the key technology trends of the next few years being the increased power and ubiquity of mobile devices, the post-PC era and the consumerisation of IT, everybody working in IT strategy and architecture should be.  What I have found interesting, however, is the lack of a common understanding of what a desktop is. (In fact I’m fairly sure that “desktop” is the wrong term. Perhaps I should be talking about “end user computing”, or “client computing” or  “workspaces”. I’ll stick with “desktop” for the moment though). As we move from traditional physical desktops running operating systems and installed applications towards virtual desktops with virtualised applications to Desktop-as-a-Service it helps to have a conceptual framework to discuss these models and understand where they are the same and where they are different. In this post I want to describe the conceptual components of a desktop architecture, and then build on this in subsequent posts to analyse the different ways we can implement desktops and desktop architectures.

The conceptual components of the desktop and desktop management architecture

Conceptual Components of a Desktop Architecture

I believe that what we are really talking about when we discuss the desktop is the delivery of applications and data to users. The desktop is just the current best means we have of doing that. What I want to do in this post is show my conceptual analysis of the desktop. This will in turn allow me to describe a conceptual architecture for the desktop. (If you are wondering what a conceptual architecture is, or what the point of one is see my post on it here along with the comments and my responses.)

I separate the wider concept of desktops into the desktop itself (the thing that the individual uses and interacts with) and the desktop management (the layer interested in managing the stuff that the user directly interacts with). Within the desktop the conceptual components are:

  • Device: the most physically prominent component of the desktop. This is the actual physical hardware that the user interacts with.
  • Operating System:  provides management of the common hardware resources (such as memory, file systems, storage, input devices and output devices) as well as providing common services to applications. It acts as an intermediary between applications and the underlying hardware platform. Today’s operating systems also provide the central organising metaphor for presentation of and interaction with applications and data.
  • Configuration: the settings that influence the behaviour of the device and operating system. These are the parameters that the operating system uses to determine exactly how it will present and behave on this particular device at this particular time. Configuration will determine many aspects of the overall desktop including appearance, security and availability of functionality.
  • Applications: the executable computer programs that we access from the desktop. Applications perform a range of functions that we won’t go into here. Suffice it to say that applications are why the desktop exists. They are what performs the tasks that computers are for.
  • User Data: the data that belongs to the user for storage or processing/presentation by applications.
  • User Accounts: the settings, access rights and security associated with a particular named identity.

Within the desktop management layer the conceptual components are:

  • Device Management: management of device settings, tracking devices,
  • Configuration Management: central management of OS configuration – setting configuration, restricting what configuration users can change.
  • Patch Management: the application and deployment of updates (patches) to the operating system of the desktop.
  • User Management: the allocation of user accounts and their privileges to desktops.
  • Application Deployment: the delivery of usable applications to a desktop.
  • Application Packaging: preparing applications so that they can be appropriately deployed to the desktop. In an enterprise setting this usually means optimising application configuration for the organisation’s policies and environment as well as preparing it for the chosen deployment method (which may not be the way that it is delivered by the manufacturer).

These conceptual components don’t live on their own. Within a typical enterprise environment they also consume a range of other resources or services such as network connectivity and storage – but that is a topic for another post.

As an example of how to apply this conceptual framework to a real example, consider the traditional consumer desktop – such as the one I am writing this on now. It consists of a device (a box with hard-drive, memory, processor etc.; screen; keyboard; mouse) which has an operating system (Windows 7) installed and running on it. I have configured it to work as I wish, installed applications on it, created user accounts on it for myself and my family and my data (files, documents) sit on its hard drive. I perform configuration and device management manually. Microsoft do my patch management for me: creating and distributing my operating system updates to my desktop. I perform user management locally with the built-in tools of Windows 7. I perform application deployment manually, and the application manufacturers do the application packaging for me.

So the conceptual components allow me to describe what makes up the desktop. I also believe that these conceptual components allow us to describe the key differences between different ways of delivering and managing desktops and the applications and data that are their primary purpose. I’ll cover those different models in later posts.

If you are working on desktop architectures, or desktop virtualisation then I hope you find these thoughts useful. If you don’t, please let me know in the comments below. My thought in this area is currently evolving and I’d be keen for other viewpoints.


6 Responses to “A Conceptual Desktop Architecture”

  1. Yes, fair point.
    Looking at mistakes of the past, I think having one solution that suits all employees is the biggest problem.
    A whole range of solutions for end user computing exist, and a selection of them should be provided. This is based on the assumption that for some users, a self managed device is fine, and for others, a monolithic enterprise build with the associated security and automation is also required.

    Not only is the domain technically complex, but also politically so, as users will be attached to their current mode of operating, with subjective loyalties.

  2. Been thinking a lot about this during the week.The desktop “problem” essentially boils down to a security problem. How can safe access be granted to applications and services internal to an org?

    I have concluded that the best way to think about it is to consider the device accessing the applications to be totally untrusted, and to ensure security for access to applications and services is individually adequate. The larger the perimeter that you are trying to protect, the more difficult it is

    Time to descend into metaphor hell:
    It is easier to protect your car and phone and house by individually locking each one, or by putting them inside your property and building a big wall?

    • Hi Michele,

      Firstly I think that the desktop “problem” is much bigger than the desktop security problem – though that is an important part of it, and your approach to that part of the overall problem is probably dictated by your philosophy around end user devices in general. Certainly the industry as a whole is moving to a position of secure your information and applications rather than your devices (for a number of reasons) and treating all devices as untrusted, though the technology to do this universally is not there yet, and adoption will be slower still. One of the key drivers is the whole Bring Your Own Device issue, where securing the device to the extent necessary is not possible, and therefore we need to think of new approaches.
      This still leaves the issues of how best to manage devices, how to deliver and manage applications and data, unanswered, and these are if anything, larger issues.

  3. Hi Peter,

    I think that we still need to talk about end user computing even if we have covered issues like goal or activity related “spaces”, because those spaces still need to be experienced by individual users through some form of device (so you need to present to those devices and you need to manage those devices etc.). You just can’t get around that. The specific desktop metaphors are a separate issue. I think that the metaphors for providing access to applications and data will change significantly from the desktop metaphor we have today to different ones – and windows 8 is an example of this.

  4. General remark: It is a bit strange that we are still talking about end-user computing and the desktop metaphor. Wouldn’t it be time to really think about concepts that are more activity and goal related, like project or case desktops with applications, shares and information accessible to and relevant for teams?

    The conceptual desktop architecture looks a bit like what the DYA Infrastructure Repository at https://dya-knowledge.sogeti.nl/dir/DYA_Infrastructure_Repository tries to do for the whole infrastructure, they also are doing a conceptual analysis I guess 🙂


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: