It has been a few weeks since I first wrote about drinking the Citrix Kool-Aid and trying for ourselves to turn our lab into a dynamic deliver center.  The first part of this project is to identify what is the purpose of our lab.  After looking at things deeper, we are responsible for mainly 4 things:

Technical Readiness Infrastructure: 

The Tech Readiness group is responsible for creating and delivering technical training to our customer facing people. This includes Support, Consulting, SEs, etc.  This group develops hands-on training that walks the student through setting up, configuring and troubleshooting the product.

As you can imagine, during a new product release, we have classes stacked up one after another all around the world. These classes use prebuilt environments in a remote lab in Ft. Lauderdale.  So if a class is occurring in Singapore, London, Sydney, Paris or anywhere else , the students will connect to Ft. Lauderdale to work on the pre-configured lab environment. Because the focus of the classes is to train on the new features, we don’t expect our students to run through installations.  This means the environment must be prebuilt ready for configuration.

As you can expect, this is a challenge, which brings us to our first few requirements:

  • Requirement 1: Tech Readiness: Must be able to work with the latest products, whether they be hardware or software, remotely.
  • Requirement 2: Tech Readiness: Must be able to refresh environment quickly to a base state with items installed, but not configured
  • Requirement 3: Tech Readiness: All previous classes configurations must be removed and devices and servers must be put back to base state (including passwords, accounts, optimizations, etc)
  • Requirement 4: Tech Readiness: Environment must be able to allow students to work with all features and products including WANScaler optimizations, NetScaler load balancing, XenApp Progressive Display, Smart Auditor, etc.

Worldwide Consulting Solutions

The Solution Center and Integrated Solutions team is responsible for developing best practices and recommendations for integrating Citrix products with other Citrix products and 3rd party products.  For example, these two teams have developed items discussing XenServer and XenApp integration and on how to integrate WANScaler and NetScaler with Microsoft SharePoint.  From project to project, the architecture could look quite different, but there is one common aspect to all projects… There is at least one Citrix solution involved. 

The types of projects can vary wildly from validating an application runs on XenApp, defining deployment best practices for a particular web application with NetScaler to performing scalability testing on the latest version of XenDesktop. All of these items come together to bring us a few more requirements:

  • Requirement 5: Worldwide Consulting Solutions – Need to be able to bring up a set of Citrix solutions without requiring installation
  • Requirement 6: Worldwide Consulting Solutions – Need to have the different project pods separated from other pods as one test might influence the results of another test

Field Teams

Working with our customer, many of our field Citrites find themselves in need of a reference system to be able to look up a setting, perform a quick test based on a customer question, or be able to demo a new feature that is easier to show than to explain.  These types of requests are short lived, but require a fast response. Because of the huge number of potential questions a customer could ask, it is impossible to anticipate every conceivable environment needed or when the requests could occur.  This type of situation brings about the following requirements:

  • Requirement 7: Field Teams: Need to get access to a base system (regardless of product) in a short amount of time that can be modified. 
  • Requirement 8: Field Teams: Each reference system must be isolated as customers will be seeing the systems in a lab that also contains systems of new, unreleased products
  • Requirement 9: Field Teams: Need to be able to extend check-out time if work extends beyond original request date

Administration

I haven’t hit all of the groups that use the lab because this blog would be longer than the movie script to the Simpsons Movie (which I highly recommend by the way), but most of their requirements are contained within the first three groups.  Before I close out, there are still a final set of requirements focused on the administration of the lab. We must make it easy and automated:

  • Requirement 10: Administration: Systems should be in a low-power state unless they are being used.
  • Requirement 11: Administration: The systems, when allocated, should be powered on automatically.
  • Requirement 12: Administration: Systems should be automatically built, cleaned, decommissioned and assigned.
  • Requirement 13: Administration: Hardware assignment notifications should occur through email with all pertinent connection information once the systems are online.

I know this was quite a long blog, but this is a big project and I didn’t want to gloss over anything. 

Up next, a Proof of Concept.

Daniel

(Homer Simpson Quote of the Blog: “Oh, so they have internet on computers now!”)