After reviewing archived project tracking tables, and consuming considerable amounts of caffeine, I estimate that I’ve “re-packaged” and “deployed” approximately 4,100 applications, from 250 vendors, to 30,000 computers in the past 10 years. That’s an average of 410 applications to 3,000 computers per year. That’s not counting “packaging”, just “repackaging”, but I’ll get to that later.
That statistic would be somewhat misleading, however, since the bulk of this activity occurred between 2008-2010, and again between 2012-2014, with another spike in 2015. In that same time period, I estimate that I’ve sat in approximately 690 status meetings for a total of 1,400 hours. That’s an average of 140 hours per year of nothing getting done. Did I work alone? Hell no. Others were doing as much, often more, than that.
Overall, over that time frame (2006 – 2016) I think I’ve learned a little bit about:
- The difference between “packaging” and “repackaging”
- The misperceptions management people have about applications in general
- The misperceptions IT people have about applications in general
- The misperceptions vendors have about customers
- The misperceptions about staff meetings everyone has
Let’s dissect, digress and digest this a bit.
Packaging vs. Repackaging
Some of you may be aware that I’ve written a few books about the subject of software packaging, repackaging and deployment. In most of them, I tried to elaborate the differences between these two (often-confused) terms. Those that read my books get it pretty quick, but not because I educated them or anything. It was because they already knew it, but didn’t realize some of the criteria that separate the two.
Packaging is what the vendor provides to customers. Repackaging is what you do with it before deploying into your production environment.
Misperceptions by Management
I can’t cover all of the misperceptions in this category without writing a series of books. Suffice it to say, once you hear an MBA-wielding executive say the words “Excel database”, it’s over and done. But, for the sake of this discussion I’ll focus on their views as it pertains to software deployment and the preparation work involved which leads up to that.
In all of those status meetings I mentioned earlier, some of the most commonly-asked questions focused on the following:
Them: “Good morning Don”
Me: “It’s Dave, but good morning to you as well.”
Them: “Sorry Dan. How long will it take to package ___ ?”
Me: “I don’t know yet. I need to see the specifics before I can…” (cut short by impatient asswipe in monkey suit)
Them: “I don’t care about that techie stuff! Just give me a number I can use in my Excel database!”
Me: “Okay. One.”
Them: “One what?”
Me: “One hour to assess the product and give you a real estimate.”
Them: “We’ve hired the firm of Douche, Phister and Ballzlik to develop a project plan for packaging and deploying 4,000 applications by your team. We need you to tell them how long it takes to package an application.”
Me: “That depends.”
Them: “On what? It’s just software. How difficult can that be?” (followed by smug chuckling)
Me: (eyes blinking rapidly, fist tightening on coffee cup)
Them: (eyes blinking rapidly, tapping pen on table top annoyingly loud)
Me: “There is no single number to fit all of those applications. Some will take a few minutes, and some will take a few days. It’s like asking how long it takes to build a house, when I haven’t been told how many rooms it will have.”
Them: “That’s no good. We want a single number.”
Me: “Okay. Using a standard deviation curve with a PA heuristics weighting of 25% being on the complex end, and 25% being on the super-easy end, I’d guesstimate 16.0 hours per application.”
Them: “Let’s make it 2 hours.”
You can see where this can lead. And people wonder how workplace violence gets started.
In short, what they (often) don’t understand is that software products are not uniform, nor are they uniformly packaged for installation. Some of them support a larger set of features than others which can be leveraged to support automated deployments (and custom configuration settings, etc.)
They also (often) do not understand the mechanics of shoe-horning the applications which do not support a sufficient set of deployment features into something that can be relied upon.
They also (often) do not understand how the logical “gap” varies by product as well as by the COE platform specifications. This is worse in organizations which have multiple COE specifications, often by division, department or project team.
Misperceptions by IT Personnel
Ask a software developer how long it takes to package or repackage a software application installation, and you’ll get one answer. Ask a helpdesk technician, network engineer or services architect the same question and you’ll get three different answers. One of them might be correct.
Software packaging is a very strange role indeed. It requires a unique mix of skills that cross the typical organizational boundaries imposed by most IT shops. In order to effectively plan, develop, test and execute a large volume of application deployments, the person(s) involved will ultimately have (or will learn) the following skills:
- Windows platform API’s
- File System
- Windows security models
- Common Proprietary components
- Java Runtime, Java Runtime and more Java Runtime
- .NET Framework (all of them)
- Oracle Client
- SQL Native Client
- Adobe AIR
- Apple Quicktime
- Visual C++ Runtime 2000, 2002, 2005, 2008, 2010, 2012 2020, 2340, 4040, 5050, and who knows
- IT Forensics
- Active Directory
- Accounts, Groups
- ACL’s (by scope and class)
- Sites and Subnets
- Group Policy and GP Prefs
- Role-based context modeling
- Services and Processes
- Core networking (TCP/IP, DNS, DHCP, etc.)
- Packaging tools like AdminStudio, InstallShield (or one of a dozen alternatives), possibly App-V, ThinApp and a few others
- Analysis tools ranging from Sysinternals’ to about two dozen lesser-known open source, shareware and freeware utilities
- Scripting, Scripting, Scripting and more Scripting
- Virtualization products
- Deployment Products
- System Center
- Cloud services (less common so far, but will increase soon)
Will this person be expected to master all of the above? No. (cough-cough, some managers will expect that, however). What I’m really getting at is that a successful candidate (and I interviewed many over the years) will have mastered some of these, and will involuntarily master the others over time. Or they will burn out and change career paths.
The Rubik’s cube of deriving estimated level of effort or completion times gets tossed into the following blender, making a quick knee-jerk answer to the question “how long does it take” nearly impossible (or complete bullshit):
- Product installer features
- Product prerequisites
- Product security requirements
- Vendor support quality (responsiveness, openness, etc.)
- Upgrades, Updates and New Install scenarios
- Product and/or API Conflict management
- Engineer skill set and aptitude (okay, yes, and attitude)
- Engineer workload
- Engineer distractions
- COE variations and constraints
The short story is that nobody in IT knows how to properly categorize a “software packager” or “packaging engineer” anymore. Hardware and Network people see them as App Developers. App Developers see them as infrastructure support. Infrastructure support sees them as some weird sub-group. InfoSec just gets annoyed every time they ask for firewall exceptions and malware scanning exclusions.
Misperceptions by Vendors
The most common problem I have seen with ALL software product vendors is that they view the world as though their products will have free reign over the device without any constraints or compatibility issues. After all, they tested it on their pristine lab environments and it works fine for them.
As long as you don’t install any other products and every user is a local administrator, it works just fine. Oh boy.
Some (few) vendors are easy to work with when it comes to getting some help with deploying their apps. Most expect you to stand in line behind everyone else, even though you may be trying to deploy 10,000 licenses of their precious baby. And others just flat-out don’t care.
There are also those one-off, solo developer applications which some customers just cannot live without. You contact the developer and it’s hard to hear them talk over their cats and dogs and spoons hitting cereal bowls while the TV is on. Many of them are also under-funded, such that they remain steadfastly anchored to outdated software versions and deprecated components.
It’s murky. It’s mysterious. It’s messy at times. It’s misunderstood. And it’s often fun, when the politics don’t get in the way.