I had a very interesting debate with someone the other day. The debate was around the Total Cost of Ownership of an app on a desktop computer. Let’s say that you have a $5 app. Now let’s say that in order to package that app up and test it for end user deployment, that the cost to your organization is about $400. That’s going to seem high if you just look at it as a number. But when you consider that it takes time to customize an app package so that end user data is preserved and end users aren’t prompted a dozen times, then it takes time to test that package (thus my continued interest in crowdsourced automated regression testing these days), and then it takes time to deploy that package, potentially with rollbacks and customer issues when done en masse, $400 might end up being very low for some software titles and very high for others.
The debate. I’ve been on a lot of deployments with 25,000 or more users/devices. And something that always comes up is “OMG how can people have this much software out there?” One deployment, the customer estimated that there were about 20 apps on their 10,000 devices and there ended up being well over 1,000. This was OS X, not iOS. On iOS it’s a much easier conversation. But on OS X and Windows, a lot more work must go into preparing apps for deployments. In OS X, users can be a bit more irritable about tampering with systems, so extra care must be taken to not bug users when you deploy software. In most software titles for Windows, you have more patches. It ends up being a similar amount of time to manage your Definitive Software Library (DSL) for each. Now let’s say that for your 1,000 apps, you spend $400 per app to manage that, per patch, with around 4 patches per year as a round average number. This means that each unique application title ultimately costs you $1,600 to own (not including logistical concerns around chasing down licensing, the cost of the initial app, and any services attached to apps). For 1,000 apps, you could be looking at $1.6 Million dollars just to keep your repository up-to-date.
Scale helps. In Casper, we’re working on “Patch Management” as a feature. This is why. At 318, I worked with my team to get the open source AutoPKG linked to our Casper environments so we could have a tool that used recipes to automatically import known software into our Casper servers. We could then have a release management process around regression testing the software and ultimately releasing it to users for UAT and then to the full compliment of users, or in waves. Let’s say that implementing such a tool saves you 25% of your time. Well, in the previous example, you’re now down to $1.2 Million dollars worth of labor to manage your DSL.
Politics doesn’t help. Now let’s say that you are faced with not having the staff to deliver all that time to manage all those software titles in your DSL. Well, bummer. I guess you’re going to have to look for the least distributed software titles and remove them from the list of apps users can have. There are many, many apps that only one person uses. As your compliment of machines grows, the distribution of apps with less than 5 people using them displays as a hockey stick. But, each app could end up saving 5-50% of an actual humans time. And in my experience, some of these smaller distributed apps can be the most hyper-focused on a job-specific need. Some apps are absolutely frivolous. But we’re not talking about people asking you to support Angry Birds on their computers, we’re talking about business machines. Unless you work for Rovio…
You don’t have to own it all. Or do you? If you deploy an app, do you have to support it as well? If you give users admin passwords, they can deploy their own apps and you don’t have to package some of those random apps. But if you let users deploy their own apps, how do you make sure you aren’t opening your company up to the risk that the app deployed is actually owned and properly licensed? And if the user gets a new machine, how do you give them that app? If all apps were distributed through an App Store (be it Apple’s Mac App Store, etc) then this would be tracked in an MDM solution. While it would be nice for administrators who have a lot of machines to manage, that would seem draconian to developers. But doesn’t it look more and more like the future?
Understanding your users is key. I’ve seen many environments where administrators took an accounting of what apps people used and then surveyed users to ask if they actually used many of the less obvious apps in their environments. After doing so, between 20 and 50 percent of apps were no longer needed. Of those, a few percent ended up coming back, because users didn’t take the survey or didn’t think to mention the app in the survey and forgot about it until a few months later when that quarterly process they use the app for came back around. I’ve also seen workflows where a slightly more expensive app that did the task of 3 or 4 smaller apps could be used. The cost to license the new apps was justified by offsetting the cost of packaging, distribution and testing. In all of these environments, chargebacks for software AND the associated management caused a business analyst within a group to redefine requirements and find a better way. A packaging administrator cannot fully understand the needs of every user in a large organization; but a business analyst charged with helping a smaller group can get innovative and cut costs while providing even more value to end users.
Is the Mac a Mobile device? All of this comes into focus because on a call, someone said that managing Macs had been marketed as similar to managing iOS devices. No. That’s not the case. Some of the same tools are use, which help to simplify management. And the focus is on empowering users rather than limiting users. The work that we do in packaging is just to provide a better user experience. However, when I speak to organizations on technical requirements and integrating services, I often ask “what is the workflow for Windows?” For example, NetBoot. I always ask “what do you do for PXE-booting,” which helps set the stage for my next question “can we get an IP helper, just like the one you created for PXE?” When you frame a request in a way that there’s a historical analogy, administrators more easily understand the intent, technology, and desired end state. While imaging a computer in the Post-PC era may be arguably dead technology, it still serves some troubleshooting purposes and so cannot be fully discounted. And if you disagree with that, the analogy still holds true for other technologies, such as defining MIME types for a server that’s distributing .ipa files.
So in conclusion, the arguments here are supporting a very basic question: how do you calculate the ROI of an app that is distributed to only a few users, and whether the ROI is greater than the productivity or creativity gain that the app provides. Obviously, the answer is “it depends” which is not a basic answer. However, you can take these questions and derive whether containment makes sense for your organization or not. Chances are, you can remove a good chunk of apps that are deployed in your environment. And then you can focus on packaging and support of the remaining apps. Of the successful large-scale deployments I’ve worked on, this has been an absolute pre-requisite to getting to the point where they can support machines with one tech/engineer per more than 1,000 systems. Now don’t even get me started on virtualization of these apps…
