In my previous blogs I’ve talked about the importance of getting all of the requirements aligned for the application delivery infrastructure, and ensuring that the teams who will be supporting the platform are all involved in the process. I’m confident that those projects that do gather the requirements and ensure their organization is fit to deliver the platform will create excellent application delivery infrastructures, but one area that projects tend to find incredibly difficult to address is the application sprawl.
Typically IT organizations will concentrate on the desktop estate and only see:
A) The number of desktops currently deployed
B) The number of users (Concurrency) who are at their desks on a daily basis
C) Print queues and other infrastructure requirements
D) Applications the users use
The common theme with the view above is that it’s an infrastructure centric list – applications tend to come bottom of the list and IT departments always assume they already know the applications in use across the business. Whenever I’ve been engaged with projects and we’ve had data extracts from one of our partner tools like LakeSide SysTrack or LiquidWare Labs StratuSphere the IT teams are stunned to find the number of applications that are really in use that they have had no involvement in. Shadow IT is a reality in practically every organization and it often manifests itself with application sprawl – one user will discover a great application which makes their life easier, and it spreads around their department without anyone from the IT department getting involved.
Once you have managed to discover the extent of the application sprawl, what do you do next? Most virtualization projects are looking to move to a fully virtual workstyle so that future upgrades paths are not as bumpy as the one they’re suffering through right now, so App-V sequencing becomes the de-facto method of delivering applications into the virtual desktops:
However they have a very large number of applications and no current skills in house to sequence them. AppDNA does a great job of providing insight into the readiness and even automating some of the process where possible, but I recently had the benefit of a demonstration of a full suite of software which allows an organization to build a packaging process and workflow which will be manageable into the future. Now – me being one of the infrastructure guys I talked about above – I hadn’t really understood the complexity of getting applications from “Now” to “Accepted” until I ran into a project which had stalled, not because of any underlying problems (In fact against the project requirements it had delivered everything!) but because applications hadn’t made it through to the platform to be delivered. Interestingly the project hadn’t planned how to address the user base and their application requirements, and assumed a “Big bang” application delivery would occur – when they discovered how long the packaging would take the project very nearly collapsed.
Given how long it takes to package and remediate a large number of apps, I was really interested to see the demo of AmberReef’s AR.c suite. The claims made are pretty impressive (10 packages in 20 minutes) and certainly from what I saw, it’s effective and would jump-start those stalled projects. I’m hoping to spend a bit more time working around the problems at the application and user layer (hoping to find a way to shrink my current essay length “User Segmentation” blog to something people won’t give up half way through!) and one area I’m going to investigate more thoroughly is the application sequencing part. Given the urgency of the platform refresh this year it’s something that will be hugely important to all application delivery platform projects, but it’s often the piece which takes the most time to complete because of its labour intensive nature. I just thought I’d share my excitement about something that will hopefully make our projects easier – also I’m eager to hear if anyone else has any other recommendations in this space?
The views expressed here are mine alone and have not been authorized by, and do not necessarily reflect the views of, Citrix.