From time to time when working with our customers, I hear comments, such as ‘the environment isn’t performing’ or ‘the Citrix environment is broken!’ and as a Citrix Consultant, I probably hear the latter of these more often.
The last couple of customer projects I have been engaged on have involved deployments that have evolved over time and the original requirements, which the environment set out to meet, have long since changed. Or the business initiatives may have changed direction and new user requirements have been ‘bolted on’ and not fully assessed.
Now if you are in a similar position, I urge you to STOP! Take a step back, grab a cup of coffee and hopefully the remainder of this blog may provide some assistance to you.
Before I begin, there are two previous blog posts that I recommend, which have certainly assisted me and I have used for reference: https://citrixblogs.wpengine.com/2013/08/29/organizational-challenges-with-vdi/ and https://citrixblogs.wpengine.com/2012/03/30/desktop-transformation-high-level-project-plan/
Now, when I joined Citrix Consulting just a little over 4 years ago, I was introduced to the methodology of projects – something I wasn’t used to before being a techie! The methodology to which I was introduced was the Assess, Design, and Deploy process with each playing its own crucial phase!
Now, I hear you ask: why is this so important! I, myself, also asked this same question, until recently when I found that it really does work and is key to the project success we all search for!
So, how does this methodology work?
- Assess. Infrastructure Analysis and Requirements Gathering
- Users and Applications. This is the most overlooked part of any assessment phase. Define your user groups (segmentation) and the applications that they will be using. Whether this is for an RDS type deployment with users accessing similar applications (Call Centers for example) or one with design users utilising 3D Pro applications, each user set comes with its own application requirements. Since applications can make or break of the environment, failure to categorise these properly can cause user experience to fall through the floor!
- Requirements. This is (from my experience) the most important part of a consulting engagement. What is the environment setting out to achieve from both a functional and non-functional level? If these are defined within reason, but at a low enough level, the design phase almost writes itself.
- Design. Architecture Designs and Verification
- Conceptual Design. Once you have the requirements for what the environment needs to do, the conceptual or high level design can be produced. This is best kept at a high level and should include what products are in scope to meet the requirements, the rough number of users, estimated server sizing, and an overview of how the environment will look.
- Detailed Design. This can be overlooked at times, because the Conceptual Design has been classed as having enough detail for the project. I would argue this point, however, after some recent experiences with this. This is the first attempt (albeit on paper) of all the needed low-level configurations (I do sometimes think of it as a build document); it will form part of your documentation to rebuild the environment from ground up if ever required. More importantly, it’s where the justifications for each of your configurations are documented.
- Operational Design. This document is often overlooked, but is key to defining operational tasks and process, potentially to include image and security updates, reboot schedules, backup/disaster recovery, and other operational processes that may be required for the customer team to support the environment.
- Deploy. Pilot and Production Rollout
- Pilot. I am not going to dive into too much detail around a pilot. The main thing here is that a pilot has a specific end date, and users go back to the original production environment at its end, allowing for the feedback to be processed and the lessons to be learned. Pilots should have a specific purpose, such as design validation, or user experience feedback.
- Pre-Prod and Production. Once satisfied with the Pilot, then it’s time to move to pre-production and production deployments. Again, starting with pre-production before moving to Production!
After all that, I can hear you all saying that we haven’t got time for this or it’s a very lengthy procedure to deploy a Citrix environment! Well, I can’t stress enough from my personal experience that following this methodology strongly strengthens the chances of your project succeeding, de-risking it against common mistakes and challenges, and is a methodology which Citrix Consulting have used for a long time! Therefore, it’s proven too!
For more information surrounding the Consulting Methodology please visit: https://www.citrix.co.uk/support/consulting/
Thanks for reading!
