A logical view on end user computing architecture

Over the last couple of years, I’ve worked with a variety of customers looking to transform the way they deliver end user computing services. Typically they fall into two camps:

  1. “We invested heavily in thin client technologies and now we’re finding them to be over-engineered and expensive with multiple layers of technology to manage and control.”
  2. “We have a managed Windows desktop running <insert legacy version of Windows and Office here> but the business wants more flexibility than we can provide.”

There are others too (like the ones who bought into a Mobile Device Management platform that’s no longer working for them) but the two examples above are by far and away the most common issues I see. When helping customers to understand their options for providing end user computing services, I like to step up a level from the technology – to get back to the logical building blocks of an end user computing solution. And, over time, I’ve developed and refined a diagram that seems to resonate pretty well with customers as a framework around which to build end user solutions.

Logical view on the end user computing landscape


Starting at the bottom left of the diagram, I’ll describe each of the main blocks in turn:

  • Identity and access: I start here because identity is absolutely key in any modern enterprise. If you’re still thinking about devices and operating systems – you’re doing it wrong (more on that later). Instead, the model is built around using someone’s identity to determine what applications they can access and how data is protected. Identity platforms work across cloud and on-premises environments, provide additional factors for authentication, self-service functionality (e.g. for password and group management), single sign-on to both corporate and cloud applications, integration with consumer and partner directory services and the ability to federate (i.e. to use a security token service to authenticate on-premises).
  • Data protection: with identity frameworks in place, let’s turn our attention to the data. Arguably there should be many more building blocks here but the main ones are around digital rights management, data loss prevention and endpoint security (firewalls, anti-virus, encryption, etc.).
  • Connectivity: until we all consume all of our services from the cloud, we generally need some form of connectivity to “the mothership”, whether that’s a client-less solution (like Microsoft DirectAccess) or another form of VPN. And of course that needs to run over some kind of network – typically a Wi-Fi or 4G connection but maybe Ethernet.
  • Devices: Arguably, there’s far too much attention paid to different types of devices here but there are considerations around form factor and ownership. Ultimately, with the correct levels of management control, it shouldn’t matter who owns the device but, for now, there’s a distinction between corporately-owned and user-owned devices. And what’s the “other” for? I use it as a placeholder to discuss embedded systems, etc.
  • Desktop operating system: Windows, MacOS, Linux… increasingly it doesn’t matter what the OS is as apps run cross-platform or even in a browser.
  • Mobile operating system: iOS, Android (maybe Windows Mobile). Again, it’s just a platform to run a browser – though there are considerations around native applications, app stores, etc. (we’ll come back to those in a short while).
  • Application delivery: this is where the “fun” starts. Often, this will be influenced by some technical debt – and many organisations will use more than one of the technologies listed. Apps may be locally installed – and they can be managed using a variety of management tools. In my world it’s System Center Configuration Manager, Intune and the major mobile app stores but, for others, there may be a different set of tools. Then there’s virtualised/containerised applications, remote desktops and published applications, trusted apps that run from a file share and, finally, the panacea that is a browser-delivered app. Which makes me think… maybe this diagram needs to consider add-ins and extensions… for now, let’s keep it simple.
  • Device and asset management: until we live in a world of entirely user-owned devices, there are assets to manage. Then, sadly, we have to control devices – whoever they belong to – whether that’s policy-driven device and application management, more traditional configuration management, or just the provision of a catalogue of approved applications. Then there’s alerting, perhaps backups (though maybe not if the data is stored away from devices) and something I’ve referred to as “desktop optimisation” which is really the management tools for some of the delivery methods and tools described elsewhere.
  • Productivity services: name your poison – Office 365 or G-Suite – it doesn’t matter; these are the things that people do in their productivity apps. You may disagree with some of the categories (would Slack fit into enterprise social networking, or is it team sites?) but ultimately it’s about an extensible set of productivity services that end users can consume.
  • Input/output services: I print very little but others print a lot. Similarly, there’s scanning to be done. The paperless office is still not here…
  • Environmental management: over time, this will fade away in favour of mobile device and application management solutions but, today, many organisations still need to consider how they control the configuration of desktop operating systems – in the Windows world that might mean Group Policy and for other platforms it could be scripted.
  • Business data and applications: all of the stuff above means nothing if organisations can’t unlock the potential of their data – whether it’s in the CRM or ERP system, end user-driven reporting and BI, workflow or another line of business system.
  • High availability and business continuity: You’ll notice that this block has no subcomponents. For me, it’s nothing more than a consideration. If the end user computing architecture has been designed to be device and platform agnostic, then replacing a device should be straightforward – no need to maintain whole infrastructures for business continuity purposes. Similarly, if all I need is a device with an Internet connection and a browser, then the high availability conversation moves away from the end user computing platform and into how we provide the services that end users need to access.

I’m sure the model will continue to develop over time – it’s far from perfect and some items will be de-emphasised over the years (for example the differentiation between mobile and desktop operating systems will become less important) whilst others will need to be added, but it seems a reasonable starting point around which to start a discussion.

A diagrammatical approach to modelling technology strategy

Last week, I wrote about the architectural work my team is doing to standardise the way we deploy technology. But not everything I do for my customers is a “standard” solution. I also get involved in strategic consulting, stepping away from the solution and looking at the business challenges an organisation is facing, then looking at how Microsoft technologies can be applied to address those issues. Sometimes that’s in the form of one of our core transformational propositions and sometimes I’m asked to deliver something more ad-hoc.

One such occasion was a few weeks ago when I worked with a customer to augment their IT team, which doesn’t include an architecture capability. They are preparing for an IT transformation programme, triggered by an office move but also by a need for flexibility in a rapidly growing business. As they’ve matured their IT Service Management approach, they’ve begun to think about technology strategy too, and they wanted some help to create a document, based on a template that had been provided by another consultant.

I like this kind of work – and I’m pretty pleased with the outcome too. What we came up with was a pictorial representation of the IT landscape with a current state (“as-is”) view on the left, a future state (“to be”) view on the right, and a transformational view of priorities and dependencies (arranged into “swim-lanes”) in the centre.

I’m sure many organisations have similar approaches, but this really was a case of a picture is worth a thousand words. In this case, the period covered was short – just two years – but I also suggested we should add another view on the right, showing the target state further out, to give a view of the likely medium-term position (e.g. 5 years).

Each representation of the IT landscape has a number of domains/services (which will eventually relate to service catalogue items, once defined), and within each service are the main components, colour coded as follows:

  • Red (Retire): components that exist but which should be retired (for example the technologies used have reached the end of their lifecycle). These must not be used in new solutions.
  • Amber (Tolerate): components that exist but for which the supporting technologies are reaching the end of their lifecycle or are not strategic. These may only be used in new solutions with approval from senior IT management (i.e. the Head of IT – or the Chief Technology Officer, if there is one).
  • Green (Mainstream): These are the core building blocks for new solutions that are put in place.
  • Blue (Emerging): These are the components and technologies that are being considered, being implemented, or are expected to become part of the landscape within the period being modelled.

It’s important to recognise that this view of the technology strategy is just a point-in-time snapshot. It can’t be left as a static document and needs to be reviewed periodically. Even so, it gives some guidance from which to generate a plan of activities, so that the target vision can become reality.

I’m sure it’s not new, but it would be good to know the origin of this approach if anyone has used something similar in the past!

Architecture for the Microsoft platform: defining standards, principles, reference architecture and patterns

BlueprintIT architecture is a funny old game… you see, no-one does it the same way. Sure, we have frameworks and there’s a lot of discussion about “how” to “architect” (is that even a verb?) but there is no defined process that I’m aware of and that’s broadly adopted.

A few years ago, whilst working for a large systems integrator, I was responsible for parts of a technology standardisation programme that was intended to use architecture to drive consistency in the definition, design and delivery of solutions. We had a complicated system of offerings, a technology strategy, policies, architectural principles, a taxonomy, patterns, architecture advice notes, “best practice”, and a governance process with committees. It will probably come as no surprise that there was a fair amount of politics involved – some “not invented here” and some skunkworks projects with divisions defining their own approach because the one from our CTO Office “ivory tower” didn’t fit well.

I’m not writing this to bad-mouth a previous employer – that would be terribly bad form – but I honestly don’t believe that the scenario I’ve described would be significantly different in any large organisation. Politics is a fact of life when working in a large enterprise (and some smaller ones too!). And what we created was, at its heart, sound. I might have preferred a different technical solution to manage it (rather than a clunky portfolio application based on SharePoint lists and workflow) but I still think the principles were solid.

Fast-forward to 2016 and I’m working in a much smaller but rapidly-growing company and I’m, once again, trying to drive standardisation in our solutions (working with my peers in the Architecture Practice). This time I’m taking a much more lightweight approach and, I hope, bringing key stakeholders in our business on the journey too.

We have:

  • Standards: levels of quality or attainment used as a measure or model. These are what we consider as “normal”.
  • Principles: fundamental truths or propositions that serve as a foundation for a system or behaviour. These are the rules when designing or architecting a system – our commandments.

We’ve kept these simple – there are a handful of standards and around a dozen principles – but they seem to be serving us well so far.

Then, there’s our reference architecture. The team has defined three levels:

  • An overall reference model that provides a high level structure with domains around which we can build a set of architecture patterns.
  • The technical architecture – with an “architecture pattern” per domain. At this point, the patterns are still technology-agnostic – for example a domain called “Datacentre Services” might include “Compute”, “Storage”, “Location”, “Scalability” and so on. Although our business is purely built around the Microsoft platform, any number of products could theoretically be aligned to what is really a taxonomy of solution components – the core building blocks for our solutions.
  • “Design patterns” – this is where products come into play, describing the approach we take to implementing each component, with details of what it is, why it would be used, some examples, one or more diagrams with a pattern for implementing the solution component and some descriptive text including details such as dependencies, options and lifecycle considerations. These patterns adhere to our architectural standards and principles, bringing the whole thing full-circle.

It’s fair to say that what we’ve done so far is about technology solutions – there’s still more to be done to include business processes and on towards Enterprise Architecture but we’re heading in the right direction.

I can’t blog the details here – this is my personal blog and our reference architecture is confidential – but I’m pleased with what we’ve created. Defining all of the design patterns is laborious but will be worthwhile. The next stage is to make sure that all of the consulting teams are on board and aligned (during which I’m sure there will be some changes made to reflect the views of the guys who live and breathe technology every day – rather than just “arm waving” and “colouring in” as I do!) – but I’m determined to make this work in a collaborative manner.

Our work will never be complete – there’s a balance to strike between “standardisation” and “innovation” (an often mis-used word, hence the quotation marks). Patterns don’t have to be static – and we have to drive forward and adopt new technologies as they come on stream – not allowing ourselves to stagnate in the comfort of “but that’s how we’ve always done it”. Nevertheless, I’m sure that this approach has merit – if only through reduced risk and improved consistency of delivery.

Image credit: Blueprint, by Will Scullin on Flickr (used under a Creative Commons Attribution 2.0 Generic licence).