At one of my customers there were needs for additional insights in their Citrix XenApp infrastructures. I was assigned the task to do a research of products that could fulfill the gap they currently have. When I just got this assignment I was wondering how I should start with this task. After I came up with the plan I thought it would be nice to write it down in an article series. The article series will exist of two components. The first article(s) will describe the process and the used techniques/methods and my experiences of selecting a monitor solution for SBC/VDI infrastructures (personally I think this can be used for almost any product selection, but that’s up to you). The second component will exists of providing more information of three products, which I have looked at more in-depth during this assignment. In this part 1 I will start with describing the first components about the process, methods and experiences, which I have divided in five steps.
Step 1: Determine the information needs
When I got the assignment the first question I asked myself which additional information needs are there actually. For which facets of monitoring are they really seeking? If you take a look at the SBC/VDI market there are lots of products mentioning that they are doing “monitoring”. However monitoring is a broad concept. The term monitoring can be used for: insights what’s happing on the system, analytics about the usage during term, alerting, resource usage, application usage, end-user experiencing. Probably you can think even more subjects that can be labeled monitoring. The first question you should ask (the customer) why they have additional information needs and more specific which additional information needs they have.
To be clear this is crucial, but that easy. When you ask many people what kind of monitoring they want, they would say everything. But what is everything. A good methodology is to ask several people in the organization what kind of information they would like to have. I have called this to find out the wishes.
You could to this by e-mail, but probably it’s better to set-up a couple of quick talks of 15/30 minutes with those persons. Try to get input from every target audience: Management, Citrix Administrator, Service Desk, Service Manager and so on. Everyone type of audience will have different needs of monitoring by default. Depending of the size of the IT organization ask at least between 5 to 10 persons what do you like to get from the solution. It’s difficult, but it really helps if the information needs are as detailed as possible. Write all information needs down in an Excel sheet, which becomes the “wish list”.
In the above shown image you can find some examples of wishes at this customer. It’s not the complete list, but shows which wishes can be recognized. In general there are three focus areas for SBC/VDI infrastructure:
- Information between the client and the SBC/VDI infrastructure (ICA Client and the Citrix session
- Information about the SBC/VDI machine (resource usage)
- Information between the SBC/VDI infrastructure and the back-end (both SBC/VDI and Front-End applications)
Also don’t forget implementation requirements: For example are appliance possible, on which machines needs the agent to be installed, which database are available/supported, which operating systems are allowed and so on.
However getting the wishes is a just the first step in this phase. The second step is to categorize the wishes. Logically not all wishes are equally important. Probably a couple of them are required, some are nice to have, some are mentioned that it can become important in the future and/or some are not in scope of the current project. We need to find a way to determine the importance of each wish for the organization. Logically there are several methodologies for that, I have chosen the so called MoSCoW methodology.
As shown in the above image borrowed from wikipedia MoSCoW uses four categories. Must (required), Should (should be included if possible), Could (nice to have/desirable) and Would (not required currently/out of scope for this project). Each wish should be categorized in one of these categories. I would recommend to do this which a small group of persons as every person would say that his wish need to be in the Must category. Architects and senior employees are good people to select for categorizing the wishes.
However the MoSCoW methodology is difficult to really rate a wish in future steps in the selection process. Therefore I gave each category points. With points you can do calculations and measurements later on. I decided to use the following rating: Must Have 15 points; Should Have 10 points; Could Have 5 points and; Won’t Have/Would 2 points.
I made the MoSCow category a selection list in the Excel sheet and created a simple formula if somebody changed the MoSCoW category also the points are changed automatically [ =IF(C6="Must have";15)+IF(C6="Should have";10)+IF(C6="Could have";5)+IF(C6="Won't have";2) ].
At this customer we finally got a list of 31 wishes, which were categorized in the MoSCoW categories. When you also have done that, you are ready for step 2.
Step 2: Is there something on the Shelf
The second step is actually taking a look in in the kitchen and the warehouse of the organization. It would be the first time that all ingredients are already available, but are never used at all or not fully implemented. In most cases there is already a product available that does some monitoring. In most times the product does fulfill the needs. Mainly because it’s a general monitoring product, which do not offer specific SBC/VDI functionalities. Such product do offer resource usage (and alerting) and monitoring services, but that’s not enough for SBC/VDI functionalities. Nowadays you also see situations that the available products are not cooperating well with modern techniques like PVS, MCS, Linked Clones, Azure, Layering and so on. I also have seen that the monitoring tool is alerting that much that other department just don’t look at it any more. Mostly in that cases there is lacking communication between the monitoring department and the other departments about which information should be monitored/alerted. The last option that’s available that there is a product purchased, but it is not implemented or even don’t know that can use a product. Within the Citrix stack organization running platinum licences are allowed to use Citrix EdgeSight. I must admit that my experiences with EdgeSight are not that good, but it can be option that is enough to fulfill the wishes of the organization.
In my customer case HP Open View was in place, offering only standard functionality like monitoring services and resource usage. Because we are using Citrix Provisioning Services the team behind HP Open View also did want to run the full HP OV Client on those machines (because of the HP Open View certificates requirements). They already had a tool available and running to check if a service was available. The tool could do run a synethic test if a user could log on to a Citrix infrastructure (but only starting it from the data centre). The test definite offers added value, but could not fulfill all wishes that could not be taken care by HP Open View.
The conclusion of Step 2 that the wishes could not fulfilled by technology and/or products that are already available within the organization. Additional software is required for that. If that’s the conclusion we can continue with step 3 selecting products for a short list.
If you are lucky that actually the software is already available, the actual monitor solution selection is ended. You can focus on implementing the product that was already in place or start making improvements to the current monitor solution already running. Otherwise you start step 3, which I will describe in an upcoming article.