This is the point where you can decide either right or wrong. Like I have mentioned in the very beginning, deciding application delivery method is not about playing around with the technical challenges, I also said it is something where we often fail. This step in the process is the one which takes us out of that kind of thinking, this will take us to something very important, users!
I know, it is very difficult to manage applications in a way that you have the organization structure included. Excel sheet is something for SMB environments, but when you hit the organization with thousands of applications you would need an army for just updating the excel files. Forget it!
Also modern application management is under constant evolution because users are requiring new ways for using the applications. Let´s take an example and call him Jim. Jim spends a lot of time at airplanes as his job in global organization requires travelling between continents, he just reached million air miles. As Jim flies a lot, he is constantly offline and because of that his applications are physically on his laptop. From Bangkok airport Jim has purchased a fancy tablet PC and wants to use some business application with it while enjoying the sun in Thailand, there is no way he would accept no for an answer without disappointment. So, IT must deliver but it may be a huge task for administrators.
Suddenly the whole scenario changed and the application should be hosted on a server, used over mobile connection with touch enabled interface and potentially with limited functionality. You are now thinking: “so what? it´s just one app!” Multiply this scenario with 10000 users and 1000 apps and try to have even the minimum level of user scenario management! Try it even with one user, if it feels easy, ask the user if he can use all devices he would like to and you are instantly lost.
You can easily see that someone is going to scratch head for a while when that XenDesktop consultant walks in front door of Jim´s company and begins planning the XenDesktop implementation. Even though I am by no means expert on XenDesktop, still I know what the obvious question is:
“Tell me about your user scenarios and show me the main user groups for each scenario?”
This is how it should probably be when desktop delivery models are defined, but my wild guess is that the simple question is not so easy to answer. Actually, it would be nice to hear how it is in reality?
Aha, light bulb! We need to glue things together.
As we started the process by importing data from System Center Configuration Manager and Active Directory, we pretty much have the tools for figuring this out. I am not saying that AppDNA can solve the challenge, but at least there is tools and possibility to take the control.
We can easily organize the applications to groups, suites and families and map those to the organizational structure.
Above illustration gives you an idea how to use them, but from reporting point of view there is something very important to understand.
Groups are relatively free way for organizing the apps, it is something like windows folders. Create a group, then put apps in to the group. It has no effect on the reporting, it is just for organizing. If application belongs to a group, it is still available as non-grouped item. It means that same application can belong to multiple groups.
Families are useful for closely related applications, like “word processing applications” –family including MS Word 2010 and 2013. In reports, this family would be displayed by the most suitable item. Meaning that if there is at least application flagged as green, the whole family is green because there is at least one version which could be delivered. If there is no green flags for the family, same would apply for amber.
Suites are something useful especially in XenApp scenarios where it is very common to have “business applications”. With business application I mean a set of applications or installations which are needed to build a solution. These solutions can be very large and complex, but simply would be something like SAP. SAP is one application, but for using the various features, you may need MS Excel, PDF reader etc. All of these applications must work, otherwise you are not able to deliver the business application “Corporate SAP”. For this reason, RAG status is displayed by the worst case. If even one application in the suite is flagged red, the whole suite is flagged red.
Ok, now we have the applications and organization in control and can start planning the desktop delivery models. I am not going to touch this area other than what I said before about the user scenarios and user groups.
From the above illustration you can see that now we could map the desktop delivery types to organization, but also have the users applications included. On top of that we directly have information on number of users in each group, number of applications inside each reporting category and we could drill down to these numbers to see the exact user accounts or applications names and so on…
After this stage is time for planning migration paths. Remember, in this example we are moving from physical environment to XenDesktop (if possible). Migration path is nothing cryptic, and actually there even isn´t any direct configuration for this, but it would be possible to define. Most important thing is that there is a plan. It can be something as simple as below.
Is there still something important we could do in this stage? Oh Yes!
Now is time for easy cost reductions. If our reports would show applications that are not mapped to any users or devices, it would be good idea to check if we could retire that application. By retiring unused apps, workload on the next steps and more importantly during daily application management is reduced. Also, if the application would generate annual license cost, that would be instant savings and it could be measured!
If you are like me, you may think about cleaning user accounts that are not linked with applications. Good idea, but be careful, all users don´t use applications! For example cities or municipalities may have huge number of AD accounts, but where might they keep the registry of all library card holders? Do they use the apps related to the same AD? Then there is users who just don´t use corporate apps for one reason or another.
Btw, next we dive to something very nice…