Phase II – Proving the technology

In this section, we are going to discuss the approach to proving the technology is fit for purpose. This is a key piece of work that needs to be successfully completed once we have completed phase I, and is somewhat different from how you would typically approach an IT project. This is the same approach you should take for any end user computing type of project. The transition from phase I to phase II can be seen in the following diagram:

Our starting point is to focus on the end users rather than the IT department. After all, these are the people who will be using the applications on a daily basis and know what they need to get their jobs done. Rather than giving them what you think they need, let's ask them what they actually need and then, within reason, deliver their requirements. It's that old saying of don't try to fit a square peg into a round hole, as no matter how hard you try, it's just never going to fit.

First and foremost, we need to design the solution around the requirements of the end user rather than spending time and money on building an infrastructure, only to find that at the end of the project it doesn't deliver what the users require.

The App Volumes component could well be part of an overall EUC/VDI project or could be an additional component to an existing Citrix solution. Either way, it's worth following this methodology.

Once the previous steps have been discussed and documented, we should be able to build a picture about what's driving the project. You will understand what you are trying to achieve/deliver and, based on hard and fast facts from the assessment phase, be able to work on what success should look like. From there, we can then move into testing some form of the technology, should that be a requirement.

There are three distinct roads we can take within the testing cycle, and it might be the case that you don't need all of them. In actual fact, it is usually best to jump straight to the last one, and look at deploying a pilot. We will discuss why later in this chapter.

The three stages we are talking about are as follows:

• Proof of concept (PoC)
• Proof of technology (PoT)
• Pilot

In the next sections, we are briefly going to cover what each of these stages mean and why you might or might not need them.

Proof of concept

A proof of concept typically refers to a partial solution, typically built on any old hardware kicking about, that involves a relatively small number of users, usually within the confines of the IT department acting in business roles, to establish whether the system satisfies some aspect of the purpose it was designed for.

Once proven, one or two things happen. Firstly, nothing happens as it's just the IT department playing with technology and there wasn't a real business driver in the first place. This is usually down to the previous steps not having been defined. In a similar way, by not having any success criteria, it will also fail, as you don't know exactly what you are setting out to prove.

The second outcome is that the project moves into a pilot phase, which we will discuss in a later section. You could consider moving directly into this phase and bypass the PoC altogether. Maybe a demonstration of the technology would suffice, and using a demo environment over a longer period would show you how the technology works.

Proof of technology

In contrast to the PoC, the objective of a proof of technology is to determine whether or not the proposed solution or technology will integrate into your existing environment and therefore demonstrate compatibility. In this case, it is to ensure that your applications will work as an AppStack. The objective is to highlight any technical problems specific to your environment, such as how your bespoke systems might integrate.

As with the PoC, a PoT is typically run by the IT department and no business users would be involved. A PoT is purely a technical validation exercise.

Pilot

A pilot refers to what is almost a small-scale rollout of the solution in a production-style environment that would target a limited scope of the intended final solution. The scope may be limited by the number of users who can access the pilot system, the business processes affected, or the business partners involved.

The purpose of a pilot is to test, often in a production-like environment, whether the system is working as it was designed, while limiting business exposure and risk. It will also touch real users so as to gauge the feedback from what would ultimately become a live, production solution. This is a critical step in achieving success, as the users are the people who have to interact with the system on a daily basis, and the reason why you should set up some form of working group to gather their feedback.

That would also mitigate the project from failing, as the solution may deliver everything the IT department could ever wish for, but when it goes live and the first user logs on and reports a bad experience or performance, you may as well have not bothered.

The pilot should be carefully scoped, sized, and implemented, which breaks down nicely into the following four steps to a successful pilot.

The following diagram shows the workflow we will follow in defining the four steps in the pilot:

Design

The pilot infrastructure should be designed on the same hardware platforms on which the production solution is going to be deployed; for example, the same servers and storage. This takes into account any anomalies between platforms and configuration differences that could affect things such as scalability or, more importantly, performance.

Even at pilot stage, the design is absolutely key, and you should make sure you take into account the production design even at this stage. Why? Basically, because many pilot solutions end up going straight into production and more and more users and applications get added above and beyond those scoped for the pilot.

That's great, going live with the solution and not having to go back and rebuild it, but when you start to scale by adding more users and applications, you might have some issues due to the pilot sizing. It may sound obvious, but often with a successful pilot, the users just remain using it and additional applications get added, resulting in the recommended maximums being exceeded. If it's only ever going to be a pilot, that's fine, but keep this in mind and ask whether if you are planning on taking the pilot straight into production: design it for production from the outset.

It is always useful to work from a prerequisite document to understand the different elements that need consideration in the design. Key design elements include:

• Hardware sizing
• Application packaging requirements
• Storage design
• Active Directory (users and groups design)
• Number of applications
• How applications are going to be grouped in AppStacks

Once you have all this information, you can start to deploy the pilot.

Deploy

In the deployment phase of the pilot, we are going to start building out the infrastructure, create some AppStacks by capturing applications, assign users to the AppStacks, and then start testing.

Test

During the testing phase, the key thing is to work closely with the end users and your sponsors, showing them the solution and how it works, closely monitoring the users, and assessing the solution as it's being used. This allows you to keep in contact with the users and give them the opportunity to continually provide real-time feedback.

This in turn allows you to answer questions and make adjustments and enhancements on the fly rather than waiting until the end of the project and then being told it didn't work or they just simply didn't understand something.

This then leads us to the last section, the review.

Review

This final stage sometimes tends to get forgotten. We have deployed the solution, the users have been testing it, and then it ends there for whatever reason. However, there is one very important last thing to do to enable the customer to move to production.

We need to measure the user experience or the IT department's experience against the success criteria we set out at the start of this process. We need to get customer sign-off and agreement that we have successfully met all the objectives and requirements. If this is not the case, we need to understand the reasons why. Have we missed something in the use case, have the user requirements changed, or is it simply a perception issue?

Whatever the case, we need to cycle round the process again. Go back to the use case, understand and re-evaluate the user requirements (what it is that is seemingly failing or not behaving as expected), and then tweak the design or make the required changes and get them to test the solution again. We need to continue this process until we get acceptance and sign-off, otherwise we will not get to the final solution deployment phase.

When the project has been signed off after a successful pilot test, there is no reason why you cannot deploy the technology in production.

Now that we have talked about how to prove the technology and successfully demonstrate that it delivers against both your business case and your user requirements, in the next sections we are going to start looking at the design for our production environment, as shown in the following diagram: