See what I did there? Some sneaky clickbait. But just keep reading; I promise the rest of the article is not.

It's not the truth either. It doesn't even want to be. It's my own view on the world EUC today.

Initially, I was about to write something just on Citrix. While correct, it would only be part of the story. There are other EUC vendors out there, and they are all facing similar issues.

We've all been there. The end-user reports that his Business Application is not working to their liking by some form of communication. That kind of message can go two ways:

  • "I've got a Citrix problem because of Application X malfunctions."*
  • "Application X does not work, so it has to be a Citrix problem."*

*Replace Citrix with EUC Vendor of choice.

EUC vendors have been innovating at an extraordinary pace. Gone are the days when we had to wait for a significant OS release to get some shiny new code bits. It's always changing; to that extent, it can be a real struggle to keep up.

But does this matter to the end-user? Not really; they just want their Business App. They don't care if the technology provides a watermark, prevents them from taking a screenshot, etc. They wish to use their application to get their job done.

When the application doesn't work, however, the application rarely gets the blame. It will be the EUC technology. Even the original developers of the application can be reluctant to accept responsibility and just blame "Citrix" or whatever.

As EUC admins, operators, specialists, (insert fancy job title here), ... we're often caught in the middle of this. We will be called upon to explain "why" it doesn't work. And we always have been, since the dawn of EUC technology. You could even say, EUC engineers were the very first DevOps engineers. Let me unpack that.

DevOps originates from 2 words:

  • Development: the creation of new stuff.
  • Operations: making sure that (new) stuff keeps running.

So, why am I calling EUC engineers DevOps Engineers then?

  • Operations: we need to make sure things keep running. It can be as a day to day job or to come up with a design that maximizes this simple fact: the Business App needs to be available.
  • Development: we don't write "real" code. Not the application code itself anyway. We might need to write scripts to mitigate some application shortcomings. But more than anything, we develop the solution. The solution to the end-users problem: get that working Business Application.

So, let's reconsider for a moment. EUC engineers will need to answer the question of why it doesn't work. So why "operations" of the application is impacted. And we'll be asked to fix it or to put in another way: to "develop" the solution.

Technology can and will help us with both of those tasks. But technology by itself will never be the solution. It will help us get there. Sometimes so fast we don't realize it did. But it will always be just "the tool for the road", not the final destination.

To wrap up this blog post, this is a call for action to all EUC vendors out there: if you can't explain why (new) technology will help us solve issues or make the experience better in general, go back to the drawing board and come back to us when you can. No software is perfect, no single technology solves everything. Stop pretending it does.

Technology by itself doesn't matter; it's about the people knowing how to make the most of it.