To successfully deploy a Citrix solution, it’s important to be aware of how users are interacting with the environment, understand the purpose of the environment, and plan how the environment fits into the support structure. In the course of my 8+ years with Citrix I have seen countless customer environments, and being aware of the items above can make or break your deployment. At a basic level it comes down to understanding the difference between a Proof of Concept, Pilot and Production. There tends to be a few unique commonalities across all POCs, all Pilots and all Production deployments that made them successful.
Additionally, I’ll discuss a hybrid approach that uses a simplified and streamlined approach to accelerate a virtualization project to get a medium sized user population on-boarded.
This article is by no means meant to be exhaustive, but is instead to provide some food for thought to get you in the right mindset and on the right path when planning your virtualization project.
POC – Proof of Concept
It probably sounds intuitive, but the point of a POC is to prove the feasibility of a solution, or the feasibility of a critical aspect of a solution. Typically a POC is trying to answer questions similar to the ones below:
- Will this technology meet our needs?
- Will this product perform as advertised?
- Will the prospective end user communities be productive with the new way of doing things?
- Will the ultimate solution be feasible?
What does a POC look like? In order for a POC to be successful, it must be broken up into the following steps:
- Definition of success criteria.Clearly and specifically defining success criteria will set you up for success. Appropriate success criteria typically come from business decision makers, IT, end-users, or end-user representatives. Obtaining success criteria from the internet or solution vendors typically presents a skewed point of view and probably won’t accurately address what is important to your situation.There are two types of success criteria: technical or business. Each success criteria will have two components: a criterion and a test case. Some criterion, particularly the technical ones, will easily inspire a test case, while others may require some discussions and validation.
- Engineering of proposed solution. Once the success criteria and associated test cases are defined, the POC solution can be engineered. This is usually conducted in a lab or test environment so as to not have an impact on production systems. The team responsible will typically spend several days to a few weeks configuring the POC environment to achieve the defined success criteria and associated test cases. It’s very easy to get distracted, but it’s critical to maintain focus on the key question(s) and not deviate. You’re focused on timeliness and minimal effort with maximum effectiveness. Unless you maintain focus, your POC could spin out of control, answer the wrong success criteria questions, or miss a key detail that could cause the eventual deployment to struggle.
- Evaluation of solution against success criteria. Once the solution is engineered, it can be evaluated against the test cases defined by the success criteria. In a virtualization engagement, this includes test user accounts, IT staff, or actual end users. The net result is a collection of data (pass / fail for the test cases). User numbers are typically low and limited to “friendly” users willing to take some time out of their busy schedule to try something new while also being willing to wait patiently during an iterative testing process.
- Decision to move forward. The decision makers will access the results from the evaluation portion coupled with implications about the future solution and make a decision to move forward. You may wonder, “if the success criteria evaluated successfully, why wouldn’t we move forward?” Moving forward is a business decision, so if moving forward has undesirable implications, it may not make sense. For example, if all success criteria were met, but it means a complete re-architecting of the network, then that may not provide enough business benefit to move forward.
For a POC, a strict methodology focused on the success criteria is critical to achieving a useful result from a POC. If the POC can answer all of the questions set out by the success criteria (all pass, all fail, or a mix of pass and fail), then it is successful. If the end result is a business decision to not move forward, the POC was still successful. A POC is not successful, however, when the success criteria were not appropriate or the test cases not detailed enough. These will come back to haunt you when you try to deploy.
After a POC is deemed successful and a decision is made to move forward with the technology, the POC should not be “moved to production.” Some common reasons for this are:
- During the course of engineering, focus is on quick results, rather than a pristine environment. They are places of unmethodical engineering and tinkering rather than methodical and thoughtful configurations. Changes are not tracked – only the net result is considered.
- Fault tolerance and HA, which are typically desired in a production deployment, are not commonly incorporated into a POC (unless fault tolerance and HA are key success criteria for the POC).
- A POC usually focuses on functionality rather than performance, so POCs are not optimized for performance.
In my experience, customers that make the mistake of transitioning a POC environment into production will end up struggling through the successive Pilot and Production deployments.
Pilot
The simplest way to think about a Pilot is “almost Production.” Getting to Pilot typically means the following have already been completed:
- Detailed Architectural Design based on an assessment of business and technical requirements
- Environment build and configuration
- Infrastructure testing to validate failover, high availability, and possibly scalability
- User testing and iterative feedback to optimize the user experience
- Documentation or training for pilot users and the help desk
What does a Pilot look like? It’s typically implemented in a phased approach over the course from weeks to months depending on the size of the deployment. It’s best to limit the size of the Pilot to 100 users or 10% of the total user population, whichever is smaller. Additionally, these Pilot users should be doing 100% of the functionality. Since a methodical build and testing process has been followed (you’ve done your proper user testing before going to pilot, right?), a Pilot represents lower risk, but allows for the ability to roll back to the previous “way of doing things” if needed. Users typically have an expedited mechanism for receiving support from the engineering team.
As Pilot proceeds and is considered successful, the environment can be moved to Production and rolled out to the entire end user community.
Production
Having had success in the Pilot deployment and the organization as a whole (from IT to the help desk, to management, and to the business) is comfortable moving forward, the environment can be moved into Production. Many organizations define “production” differently as it relates to change control requirements, help desk processes, etc. The idea here is that the services provided by the environment are being deployed to all users to be used in the delivery of their core job roles.
The following are typically completed before Production is reached:
- Formal training for end-users and help desk support
- Formal schedule for transition to the new systems – and associated communications to the user community
- Placement of the environment into a formal operations and support organization / processes
- Sign-off from business
A good way to think about Production is in terms of “steady state.” How do end-users get support when they have technical issues? The same way they get support when they have an issue with any other IT provided service (password reset, email issue, etc…). How is the environment monitored? Similarly to how other IT services are monitored, customized for Citrix. How is capacity planned? Similar to how capacity for other IT infrastructure is planned. I think you get the idea…
Production Pilot (POC, Pilot, Production hybrid)
If you review the Citrix Consulting Methodology diagram below, you’ll see where POC, Pilot, and Production fall along with a few other key components of a virtualization deployment (Assessment, Design, and Build):
You’ll notice that with a very structured approach like the one documented by the gray dotted arrow, you end up with low risk but longer time-to-value. In some situations, this can be a large detractor to a deployment. One way to get around this is through a medium-risk hybrid approach of all three. This is called a “Production Pilot,” which is summarized below:
- Accelerated project to get a medium sized user population of 100-500 users into production quickly
- Focus on a handful of simpler use cases
- Utilize Citrix Consulting standard practices in the configuration
Once users are successfully using the Production Pilot environment, you can then progress through the standard Citrix Consulting methodology:
- Assess phase to define additional use cases and their requirements
- Design phase to update the design based on lessons learned during the Production Pilot
- Deploy phase to Pilot and rollout new use cases to production
- Maintain phase to roll environment into steady state support
Summary
To summarize the differences between POC, Pilot, and Production, let’s take a look at some of their common facets:
Now you know the high-level distinctions between POC, Pilot, Production, and Production Pilot. You can use them as you move forward in your own Citrix deployments, enabling you and your organization for success.
If you care to comment, let me know how was your experience in deploying Citrix technologies falls into these categories?