A Missing Link of Software Life-cycle Management, with Fries and a Coke

Software Life-cycle Management.  It's a term most often tossed around by drunk vendor reps at conferences and on the expo floor, when shoving brochures in your drunken face as you stagger through the gauntlet of fellow drunken attendees.

In basic, non-intoxicated terms, it refers to the overall management of a software product from the time it arrives in your mail room (or downloaded onto a storage device), through the preparation phase, testing and deployment phase, through the murky update and patch phase, to the upgrade phase and finally: the retirement phase.  It mirrors the human life cycle in some respects, but then again, anyone who's read a Chinese fortune cookie already knew that.  I'm such as genius.  I'm also on my third beer.  In any case...

There are some rather interesting twists in the cycle that can present challenges to modeling a logistical and procedural assembly line automation approach.  These are primarily focused on the naming aspects.  Rather than try to use a lot of multi-syllabic terms and pretend to be clever, I'll just spew it like a college plebe during rush week...

You get a disk with something called "Fubar 2012" made by "Snafu Corporation".  You dig into it and find out it uses a "setup.exe" bootstrap that runs an embedded .MSI installer package.  You manage to extract the .MSI and are able to ride that bitch like a Iraqi prisoner in Abu Ghraib on a Saturday night in the Summer of 2009.  I'm sorry, is it too early for Abu Ghraib jokes?  No disrespect intended.  Let me get back on the train of thought....   The .MSI is named "fb12.msi" and when you install it, it creates a program entry in the ARP list for "Snafu Fubar Enterprise 2012" version "2.12.01".

You pop open your Configuration Manager console and create a "New Package from Definition" and select the fb12.msi.  It reads the manifest and fills out the properties as follows:

Product: "Fubar Enterprise"
Version: 2.12.01
Publisher: "Snafu Corporation"

You modify the Program properties to suppress notifications and all the other usual mumbo-jumbo, add the first DP server, and it looks good.

Then you create a new Advertisement in Config Manager and name it (manually) "Fubar Enterprise 2012" and assign it to a Collection named "Fubar 2012".  You drop a test computer in the Collection and pull the trigger.

You look at the computer and sure enough, the installation is there, and shows up in the ARP list as "Snafu Fubar Enterprise 2012", version 2.12.01, by publisher "Snafu Corporation".

The Configuration Manager client (agent) runs a software inventory scan and reports back an ARP product named "Fubar Enterprise 2012".  The Software Products table receives the entry for the executable itself as "Fubar Enterprise", version 2.12.01, publisher "Snafu Corporation".

Now.  How does the inventory report intuitively "know" that this discovered product is directly associated with the Advertised Package?

It doesn't.

This is where third-party products step in, or, where developers step in (ok, ok, I'll be honest:  they stagger and stumble in) and create a tertiary associative relationship via some application magic.  This is sometimes referred to as creating a "tenuous link", meaning that it's a arbitrary, coerced relationship that must be manually (humanly) established and maintained.

Why does any of this matter?

That's a great question and I'm glad you asked.  I'm even glad that *I* asked on your behalf, and I'm glad to be glad that you might be glad that I'm glad.  Clear as mud?  Ok then.

The reason usually becomes clear when you work in a large enterprise environment, and you enter into a major project with lots of team players which include Project Managers and bean counters.  These sorts of people like to analyze numbers and costs.  They will see all these Advertisements and say "wow! you guys make a lot of packages!  That's awesome!"   Then they will see the inventory reports and say "wow! You guys deal with a lot of installed applications!" and then after few bong loads they will often ask the following question:

"How do you know how many of all these installed applications are installed by your packages?"

Dum-de-dum-dummmmmmm....

It goes way deeper than this of course.  You might already see where this is going (or could go).  I'm currently in a place where it not only "has gone there" but all the way to the other goal line.  We have to produce detailed metrics to assess package-to-install relationships, licensing aspects, upgrade and cost aspects, and .... AND.... match that up to distribution statistics (DP server status indicators) and directly on to installation metrics (successes, fails, waiting, etc.).  In other words: a Soup to Nuts, end-to-end monitoring and reporting system.

We have that now, all that and web-based.  And it lets us manage the process via the web without having to rely entirely on the MMC console apps.  Yes, it began from the seeds planted by Windows Web Admin, but it's as far evolved and removed from that as today's government is from George Washington's time.  I'm patting myself on the back, and I need to stop.  It's unhealthy to do that.  Hold on... I had to take another sip... ok.

Where was I?  Oh yeah.  It's 2012 and while many aspects of our ever-advancing technical world are evolving at a crazy pace, some smaller aspects are left hidden in the cracks.  And these smaller aspects matter.  They will matter even more as regulatory pressure, cost efficiency, and process automation priorities continue to rise.

Think about what parts of your own procedural environment are left to the thought processes of individual employees.  Think about how many intricate, yet vital, links in your automation workflow are not entirely automated.  Those are actually direct indicators of process inefficiencies.  Those are the things we absolutely have to focus on, double-down, and figure out how to formalize them into a conduit that can be automated.  The means of automation are not important.  The crucial aspect is that the process, and each process step or component, is well-defined, and therefore capable of being automated.

Tying up this small, but important, link in the chain of software management is just one example of many.  Think about all the "what-if's" that can play into this and toss a wrench in to crash it like a broken space shuttle.  What about home-grown applications?  What about proxy applications (remember those?  I discussed those earlier and mention them in my book)?  Those are the applications that really don't exist, but we give them names out of convenience and familiarity.  Humans are great a filling in these missing links with our minds.  But our minds are transient.  Business needs to be non-transient in order to survive.  And I need another beer.   Cheers!

P.S. - by the way, that nifty graphic in the first paragraph was created by me using PowerPoint 2010 in precisely 3 minutes, after consuming three glasses of ice-cold Belgian Tripple Ale.  You can do it too.