Cost

Software technology, like any technology, provides a means to solving problems.  Some big. Some small.  Some that help.  Some that hurt.  And as with all tools, they come with a price.  Some big.  Some small.  Some obvious.  Some obfuscated.

Let's itemize, shall we?

• Licensing
• Tracking
• Reporting
• Installing
• Customizing
• Consulting
• Updating
• Upgrading
• Reassigning
• Removing
• Supporting
• Training
• Managing
• Securing
• Hosting
• Deploying

Each of these breaks down into yet more costs.  Some obvious.  Some not so obvious.  And within the small slice of software technology that involves "customizing", it breaks down into an entire ecosystemical world of its own.

Let's itemize, shall we?

• Assessment (requirements)
• Analysis
• Functional Design
• Hierarchical Design
• Interface Design
• Role-Based Access Design
• Build
• Test
• Alpha
• Refine
• Redesign
• Refactor
• Beta
• Pilot
• Fit and Finish
• Release
• Update
• Upgrade
• Retire

Depending upon the nature of the application, any one of the first set can shift weight onto a different item.  For example: Managing.  Content Management Systems are a common example.  Some might lean more on consulting or training, such as SAP.  Some might lean more on securing, such as Internet-facing web services.

Ultimately, for every cost they solve, they add another cost elsewhere.  Just as the shift from classic typewriters to computer-based word processors saved costs in one place (typewriter supplies, repair costs, speed, physical storage), they added more in others (printers, networking, paper, ink and toner, disk storage).  Obviously, nothing is really "free".  That's not to say that the new costs equal the old costs.  But before you sign your name on a proposed shift in technology, make sure you know where the money will flow.  You might be surprised what you discover.

Read More

Making a Poor Man's Web Service

A "true" web service uses a robust and sophisticated structure.  Combining XML with SOAP and other goodies, you can unleash the power of the gods and melt down the entire Universe (or maybe just max out your NIC channel).  In any case, you can still achieve the same basic (repeat: Basic) capabilities using things like the old XmlHTTP object, or the .NET WebRequest object.

What for?

If you write scripts or do any programming, you may run into a situation where you would like to be able to pass a request to a web site via URL and get something back, without ever opening a web browser.

The old way, the "brute force" or "knuckle-dragging" way, was to open up the firehose and collect everything, the entire web page, into a bucket and sift through it. That is commonly called "screen scraping", but it's really just basic text or stream parsing.

With VBScript or KiXtart you can use the Microsoft.XmlHTTP object like this...

URL = "http://intranet.contoso.local/mypage.aspx"
Set objXmlHttp = CreateObject("Microsoft.XmlHttp")
objXmlHttp.Open "GET", URL, FALSE
objXmlHttp.Send ""
$result = objXmlHttp.ResponseText
Set objXmlHttp = Nothing

With PowerShell and .NET you can use the System.Net.WebClient object to do this.  Here is just one example...

$url = "http://intranet.contoso.local/mypage.aspx"

$wc = new-object System.Net.WebClient
$result = $wc.DownloadString($url)

Why bother?

The older you get, and the longer you work with programming, you eventually realize that you can leverage the power of existing structures without reinventing the wheel.  Let's say your best friend works in the web team and has a ASP, PHP, or ASP.NET web site that interacts with a database somewhere, maybe several.  Now let's say you're having lunch with this friend and you ask "hey, don't you have access to the hardware inventory system database?" and he puts down his sandwich and can of Red Bull and says "yes, why?"  "Oh nothing, it's just that I'd like to be able to query some information from it, but I can't wait for access approval from the DBA team."  After some more discussion you determine that the information you want isn't sensitive, but you don't really need to have the DBA folks setup a new DSN for you when your friend already has one for his apps.

Now your brain starts churning.  You think about all the pieces and what you can assemble.  What if your script, running on a remote desktop computer, could submit a query URL to a web page and get back some useful information for your script to continue on with?

What if you could fetch the computer name, or BIOS serial number, and pass that in like "http://intranet.local/computer.aspx?sn=ABC12345" and get back the Purchase Order (PO) number, and information about the warranty dates, service contract number, original owner, etc.?  Maybe your script could grab that, determine if the machine is still under contract support coverage, and go ahead and process an internal support request, or send an alert, based on some condition, all without ever popping up a form asking for user input?

$sn = "ABC12345"

$url = "http://intranet.contoso.local/computer.aspx?sn="+$sn

$filename = "c:\temp\filename.txt"
$wc = new-object System.Net.WebClient
$result = $wc.DownloadString($url)

# parse the contents of $result and do amazing things...

Get the picture?   Is this making sense yet?

You PowerShell nuts out there will obviously see where the above chunk of code can be refactored into a simpler form, but the point is what you can do with it.

This is ONLY ONE example.  Do not run with this and think I'm suggesting this is all it's good for.  There really is absolutely NO limit to where you can go with this.

As I say often:  Technological API's are like Lego building kits.  The more you have, the more you can do.

Ain't it awesome?

Read More

Gazoline or Vazoline

Gasoline sounds so American.  Gazoline sounds like a diabolical German scientist in a black-and-white suspense movie.  I'm not an expert on the subject of Petroleum, nor any of its refined downstream products (except for plastic, of which I use daily, har har), but I do play a petroleum expert on TV.  TV in my mind, that is.  This article is going to blow the minds of a few of my colleagues, who know me as anti-oil, but this should prove that I'm objective by nature and always have been.

And if I were a real bonafide expert on post-production petroleum permutations, I would offer the following insights into the aspects of Gasoline and our cultural perspectives upon it.  Myths be damned...

Myth: The indicators of gasoline price change are easy to predict

Wrong.  They don't exist.  What does exist is picking a reason du jour for blaming anything besides profit drive.  The truth is that of all the various excuses used by big oil, none have held up consistently.  Not oil prices, war, regional conflict, weather and natural disasters, political strife, exploration costs, refinement costs, transportation challenges, not even solar flares.

The biggest "oops!" moment came in 2008, when, at the lowest point in our economic collapse, Exxon-Mobil reported their biggest profits in history.  Not biggest revenues mind you, but biggest profits.

This was during the same week that one of the biggest page 2 stories around the nation was the report from NHTSA that highway traffic was at the lowest volume recorded in the previous twenty years.  Higher unemployment and higher gas prices meant fewer people driving around, it was said.  When asked how they could rake in such insanely-high profits, each of the big oil reps gave a completely different answer.  It seemed that they skipped their weekly golf outing and didn't have a chance to synchronize their stories.  In the end, big oil faded into the background without giving a cohesive explanation, the government panel gave up, and ultimately: nobody cared.  The best example of American determination is our short public attention span.

Conclusion: If you want to know why gas prices go up suddenly, just pick any reason, I'm sure it will stick.

Myth: It's unfair that oil companies can raise prices at will

Wrong.  Companies like Exxon/Mobil, Texaco, Chevron, BP, and so on are NOT social agencies.  They do not exist to support the betterment of society nor the noble efforts of the common worker struggling to make it to their office, their kids events, the bowling alley, the bar, and back home again.  They are what's known as A BUSINESS.  A "business" is defined as an entity that exists for the purpose of making profit.  Period.  Don't like it?  Ride a bicycle or buy an electric car.  Oh wait, there's none to choose from locally.  That's because all those years when the tree-huggers you laughed at were warning you that you'd be tied to Gas like Keith Richards to a heroin couch.  You ignored it and kept dumping your cash into big American-sized shit.  Pat yourself on the back.  Good job.

Myth: Oil companies are to blame for SUV's and 4x4 trucks with crappy mileage

This is the same bullshit argument used against Microsoft's supposed monopoly on operating systems.  No one forced you to buy a stupid, over-sized, difficult-to-park SUV.  Your ego forced it.  You had to keep up with your social circles and not be the only soccer mom without a white Escalade, Lexus or Tahoe.  You had complete control over what you purchased.  You chose poorly and now you want to blame the oil companies.  If you drive a Prius and despise the oafish driving habits of half-blind SUV owners, you still can't blame big oil. Blame the peroxide-blonde with the sunglasses on, carrying a toy poodle in to get groomed.

Myth: Government should step in to regulate gasoline prices

As much as my emotional side wants to agree with that, my rational side sees the downside of that.  Where do you draw the line?  What comes after that?  Hamburger prices?  Cable TV?  Condoms?  Chewing gum? Some people would call that a "slippery slope", but I call it a "lubricated slope".

The best solution?  Pursue alternatives.  I'm not saying to talk about alternatives, that does nothing.  Americans are all about talk, rarely taking action.  "Someday I'm going to lose weight"  Yeah.  And Elvis is coming back.  You want to break your weekly dependence on oil?  Buy an electric car, bicycle or just walk, or just STFU.

Myth:  Cutting back on gasoline use will break our dependence on OPEC and foreign oil

Wrong.  Not only does America import more oil from Canada than anyone else, keep in mind that each automobile tire consumes seven (7) gallons of oil to manufacture.  That's just the start. Now consider everything else that requires oil as an ingredient:  paint and coatings, lubricants (oil and grease), and all the massive amounts of plastics used in your car, your home, your phone, your computer, your TV, your glasses, your clothes, your shampoo and toothpaste, your combs and brushes, your appliances, your food packaging, your makeup, and more.

A pure-electric car would still consume a lot of oil to manufacture and still require more oil to keep it running.  We can't stop using oil.  It's as much a part of our lives as water and air.

Also, while a lot of people assume oil generates most of our electric power in the U.S., it doesn't even come close to coal.  Not even in the same ball park.  Coal is king.  Coal producers are not in the big oil game, they have their own game.

Cheers!

Read More

Software Repackaging: Why Bother?

If you already deal with repackaging, or deploying software, silently, unattendedly (new word, I called it first!), to mass numbers of massively anti-IT users, you can tune out on this one.  You already know the song.  Choir: meet Preacher.  I said I'd have something to blabber about and here it is.  I hope you enjoy it as much as I enjoyed the beer while typing it.

I've heard this from business folks, end users, neighbors, relatives, and my kids' friends: "So, do you just copy the the CD/DVD to a hard drive and install it on all the other computers from there?"  It's a fair question, coming from neophytes and non-technical folks.  But is that how it's done?

No.

It's not that simple.

I wish it were that simple.

I wish software vendors gave a flying shit about making our lives simpler.  Rather than caring only about sales and shareholder value.

I wish just TWO software vendors would work from the same playbook when it comes to what features they support for installing their products.  You know, like maybe Adobe, Autodesk, Microsoft, Oracle, Apple, Symantec, IBM, HP, Intuit, Siemens, you know, those little mom and pop shops like those.  Microsoft has tried to define some game rules, via Windows Installer, and platform guidelines, but even they don't eat the same dog food all the time.  Take a look at the installers for SQL Server, Office, Windows, RSAT, Configuration Manager, SharePoint, .NET and Silverlight.  It could be described as a school teacher telling kids not to do drugs, while meticulously packing the crackpipe and bringing the Butane lighter up to it slowly, all the while never breaking cadence with the DARE speech.  The kids are confused.  Do they follow the teacher?

No.

They prefer to reinvent the wheel.  Why?  Because reinventing wheels can be profitable.  Forget what your school teacher told you.  Forget what you've heard and read.  Reinventing wheels is not only profitable, but it is now the predominant business model for American industry.  Why do they reinvent wheels (translation: invent their own installation methods)?

The answer is:  Because most, I repeat: MOST, software vendors suck at making installations.  MOST of them do not even bother trying to make their software easy to install from a command line (a standard requirement for unattended deployments).  MOST of them do not bother with making it easy to preconfigure options and incorporate them during a silent installation.  MOST of them don't bother using a licensing or activation process that works consistently with other vendors.  MOST of them not only assume all of your users are local Administrators, but expect them to be.  MOST of them just SUCK.  Period.

Then I hear from the smaller vendors that they can't afford to adopt tools like AdminStudio, or InstallShield. They would rather use some rusty old version of INNO setup, or roll their dope-smoke, bong-water, shag carpet with crumbs and hair balls solution that they call an "installer".  Wow.  Some of them just make you want to take a dump and read a month old newspaper.

Try this on...

You come back from a cool conference or presentation and your head is bursting with all kinds of new information you can't wait to put into use.  Things like streamlining security settings, administrative tools and capabilities, automation and more automation.  You start locking things down.  You start cleaning house.

Then a bunch of the software the minions use starts breaking.

Then you start breaking out the tools to see what's broken so you can devise fixes for each of them.

You start making progress, but as you start construction fixes and trying to automate their deployment to the masses, you get more reports of broken things.  Soon you are fighting them off like the bugs in Starship Troopers.  You can either exhaust all your bullets, snacks, drinks, and forget getting any sleep, or retreat to a new defense line.  That's more common than you think.  So many IT shops have had to retreat and give up some security protections in order to mitigate the impact on the software applications that keep the business running.

After all, it's one thing to brag about how tight your security configuration is, but see how well that grin of yours holds up when Mr. CEO **SCREAMS** across the conference room at **YOU** that *YOUR* "awesome security changes" are breaking business operations, and managers are **SCREAMING** about downtime and lost productivity.  Now your cool efforts are costing money.  It feels like telling Don Corleone that you accidentally chopped off Michael's finger while opening a bottle of wine.  Yep.  Not good.

Guess what?  IT is almost always viewed by the suits as being a "Cost Center" as it is.  As soon as you cost them more, you're putting on a clown suit and singing "I'm a fucking dumbass, please beat me to death right now?!".

Don't know what a "Cost Center" is?  That's ok, you're an IT guy and probably didn't study those stuffy MBA books while cramming for your CS exam.  A "Cost Center" is the opposite of a "Revenue Center", which means that while everyone smiles and loves the cute little "Revenue Center" for bringing cash INTO the business, your "Cost Center" is the ugly pug-nosed, crack-whore that "COSTS" the business money.  Sales?  Revenue.  Marketing?  Revenue (indirectly).  Support? Revenue.  IT?  COST.

This is unfortunate, since with a little effort and careful strategy, you can make any IT operation appear to the suits as being a "Revenue Center", but most IT folks aren't focused on that side of the battlefield.  The secret is in the numbers.  Remember:  Numbers are to MBAs as bribes are to politicians.  You can say you are saving the business money, but you have to put that into numbers with pretty charts and slick reports.  Works every time.

I'm straying off topic here.  Can you tell?  That's ok. I'm going to circle back around soon.  Hang in there...

With all this crazy bongwater drinking going on with software vendors, and their team of monkeys cranking installers off like an over-caffeinated wack-a-mole session at Chuck-E-Cheese's, you have an assembly line of crap coming in one door.  Then you have labor costs going out the other door.  You have to close this gap between crap installers and IT labor related to installing it on your computers.

This is the crux of the problem.   Read the last sentence above again.  Never mind, I'm going to repeat it for you...

You have to close this gap between crap installers and IT labor related to installing it on your computers.

This is tantamount.  This is epic.  This is vital, not only for your business, but for the value proposition of your entire IT operation with respect to the microscope being focused on your CIO and down from the CFO and above.

At the very least, you cannot continue looking ineffective and haphazard.  Just because you think things are great and nobody complains that you still handle things like it's 1998 and Prince is topping the charts, doesn't mean the suits aren't talking about your habits at cocktail parties with the heads of IT consulting firms.  Maybe IT staffing firms.  In any case, a few smirks and contorted faces from hearing how you handle tasks is enough to trigger the MBA response: "Oh?  Well, how would YOU handle this differently?" To which the other party will say "Well, for starters..." and it goes on for 30 minutes of (translation:) "Here's why your current IT staff is a bunch of clowns who couldn't herd frozen dead cats with a bulldozer"

Don't be that guy.

Take some time to bundle up the crapware and make it dance like a pig with lipstick.  This is what we repackagers do.  It can be unglorified at times, but for the most part it's actually not bad work.  It can be interesting.  Challenging.  Perplexing.  It will make you smile and growl, laugh and cry.  It will make you want to pick up the phone, dial the vendor and tell them how fucked up they are, then slam the phone down and laugh like a mad scientist, spilling Red Bull all down your shirt and shaking like a heroin addict on Monday morning.

Caveates

There's always caveates.

If you support a dozen computers or less, this may not apply to you.  If all of your computers use the exact same software, you probably handle that with imaging (Ghost, MDT, etc.)  If you support computers that don't have human users touching them every day, you many not have issues like this either.

Here's a quick self-test:  If I handed you a disk and said to install it on EVERY computer in your organization, along with custom settings, a license key, and make it work regardless of the users not having local administrative rights, would it take you more than a single business day to complete the task?

If the answer is "yes", you might qualify for all this mess I discussed above.

Read More

Autodesk Revit 2012 and Configuration Manager 2007: Win7 vs XP

While packaging Autodesk Revit 2012 Architecture Suite for mass deployment (via Microsoft System Center Configuration Manager 2007 R3), I encountered a problem where Windows 7 clients installed just fine, but Windows XP SP3 clients did not.  The error was 1603 or 1619, but the client log did not indicate any more specifics.  I ran the installation  (deployment) manually (interactively) and it worked fine on both platforms, but through Configuration Manager 2007 R3 it would not successfully install on Windows XP SP3 clients.  At all.  Ever.

Until...

It's an old trick that sometimes works, and in this case it did:

Within the Package, under the Program properties settings, on the Environment tab, check the option...

"Allow users to interact with this program"

It now installs on Windows XP SP3 clients as well as Windows 7 clients.

Read More

Voting Time: Help Me Out?

I need to get a better view of how I should manage this blog if I'm going to keep at it. I'd like to know how you typically discover new posts:

A. Announced on Twitter
B. Announced on Google+
C. RSS subscription feed
D. Repost on another site
E. None. You just visit the site when you feel like it
F. Someone e-mails you a link
G. Announced on Facebook

G. Is just joking. I never post my blog updates on Facebook

Post a comment to share your vote. Thank you!

Read More

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.

Read More