Real World Experience – Example

In a previous role, I was asked to revamp a Virtual Desktop Infrastructure (VDI) – the preface is that it was not performing as well as the customer expected and it needed to be brought to enterprise standards in regards to performance, availability and robustness. The company was in “growth mode”; it was growing upwards of 10 – 25% year of year (from a straight employee count) and VDI was determined to be the primary desktop going forward.

Preliminarily, the first thing I usually ask is “why” (and usually I ask “why” more than one time) to get to the root of the issue or the driving force behind the request for a change or a new architecture. Sometimes the why is simple but sometimes it’s far more complex. In this case, the first why yielded that “we had under-performing hardware”. The second why found that “we hadn’t invested properly in our solution”. The third why was that “didn’t know what we needed” – and this is where I started.

VDI is simple at it’s core; it’s desktop as a service running on a virtualized platform. It’s complex in it’s execution in that there are many working parts to make it function as close to a physical desktop as possible.

The first thing was to find requirements – what did users expect out of a virtual desktop? Was it like for like performance to a physical desktop? Was it close to a physical desktop? What were users doing? Was it compute heavy? Storage heavy? Network heavy? Some of this was hard to gather; users tended to be quite arbitrary in their statements with not much actual measurable details; “it’s slow”, “it’s not as fast as my other machine”, “using a large workbook with calculations affects everything else”.

Utilizing some industry standard tools and best practices, I found the underlying issue was that the company had insufficiently invested in this infrastructure; it was running on older storage arrays, on older servers with an unoptimized operating system. With that in mind, I formed a vision based on the requirements and the preliminary questions. The vision was an infrastructure that was scalable, robust, dynamic and that fit in the companies existing ecosystem. There was a cost to this, and for the affiliate I worked for, it was not a small cost. I typically come up with 3 solutions – the best (and typically the most expensive), the better (we meet all requirements with some to spare), and the good (we are going to meet requirements, but that’s all).

Each of these needed to be proposed to leaders of the business – and ultimately did make it up to C level executives. Ultimately, I had to show them how this was going to positively affect business and how it would work with the business architecture that was being built and expanded. I believe that during these “sales”, that opportunity exists – opportunities to educate, to show how things are currently and how they could be and show the “whys” – why I am suggesting and designing it this way. If I’m the only person that believes in the vision, it’s not going to go anywhere; I need buy-in – from executives, engineers, finance, operational support teams, etc…

I show these “whys” in different ways – sometimes it’s a presentation showing financials of it; sometimes its logical or even physical diagrams of how the infrastructure will work, sometimes it’s just a conversation. It all depends on the complexity of the project.

Once the vision is defined and approved, the next step to is to plan – building an implementation and migration strategy to be as seamless as possible to the user. These plans are communicated to anyone involved and the plan is ultimately a group effort.

From there, we follow our standard controls to implement the technology – change management and maintenance windows. With the actual implementation, I become an escalation point. If engineering teams do not know how to do something or if it doesn’t make sense to them, I make myself available to answer any questions and guide them. Some of the cabling requirements of this particular VDI infrastructure were quite specific; the why is important, but also keeping track of all of it was quite important as well.

Once the implementation is complete, the systems fall in to our standard controls and processes. Operational support is turned over to operational support teams and they take over the day to day management. As an architect, I believe I still “own” the overall architecture, but it’s built in an extensible and manageable way. It can be expanded with little or no interruption – maintenance can be done with little or no interruption. As owner of the architecture, I’m responsible for answering questions about it – from RFPs to Audit and Compliance controls.