This post was originally posted on my blog at  https://www.cloudsparkle.be/2020-10-19-EUC-DevOps/ on October 19, 2020.

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 have 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 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 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 will and can 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. But it will always be “the tool” that will help us get there, not the endpoint of the journey of fixing something.

To wrap up this blog post, this is a question to all EUC vendors out there: if you can’t explain why (new) technology will help us solve issues or make it better in general, go back to the drawing board and come back when you can.

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