The Most Destructive Force in the IT Operations World

What's more important:  Your job and income, or your personal right to get what you want?  Back up a second.  Do you even have a right to get what you want?  I'm talking about within the employer/employee relationship realm of course.  Legally speaking however, even in your personal life, you have no such guarantee of that "right" whatsoever.  You barely have a right to "pursue happiness", but even that has conditions taped all over it.  But, back to the question at-hand...

Which is more important:  The success of your employer, or your job?

If you said your job is more important, than you are like most Americans after a few beers or Xanax pills.  When they open up and give up on resisting their honest opinions.

This is aimed squarely at you folks who work in IT shops which are part of larger companies and organizations.  Big enough to have a "CIO" or maybe even a "CTO".

Based on discussions, emails, and social media indications, all anecdotal of course, but tempered with 30-plus years of working in the IT world (I'm allowed to add some seasoning to this meal), here's 5 examples of what most IT professionals seem feel about their jobs:

1. They don't feel their opinions are given much value.
2. They don't have confidence in their upper management as it pertains to decisions revolving around technology.
3. They feel too much focus is on a dollar, rather than a solution, and that in most cases, the proper solution would yield more profit.
4. They feel upper management is too easily swayed by articles and vendor marketing pressure.
5. They don't feel that their skills are being used properly or effectively.

Adding to item 3 above:  If your business doesn't match every cost-cutting move with a revenue-generating move at the SAME time, the business is doomed. You can only control revenue bleeding for so long, but unless you start work immediately on the healing part, the patient is going to die.

It seems that in the great American race to satisfy shareholders, win awards for revenue goals, and securing that big contract announcement, we lost sight of the really cool part of American business:  Innovation.  I'm not talking about tweaking and optimizing.  ANYONE can do that.  Innovation however is different.  In 2014 when it comes to setting our sights on innovation, we might as well be Stevie Wonder in a dark forest with an unloaded gun.

In fact, we're not even sitting on the right mountain anymore.  We sold that off to foreign interests.  America has ripened like a fat grape, and how we practically begging the rest of the world to come and pick away.  $5.99 a pound.  America, it seems, has outdone itself in the area of empowering every individual with the unwavering belief that they themselves are most important, and all other things are less important.

But getting back to the soul of this rant:  what is the "most destructive force" in the IT operational world?

Ego.

If you can't put ego aside to focus on the good of your business, well, you're fucked.  Sorry if my language offends, but that's the honest truth.

Some exercises that may help mitigate the effects of ego on your business:  Line your staff up and have them repeat the following phrases aloud:

1. I am not a master of anything, but I'm trying my best every day.
2. I will put aside my personal emotions to do my job the best that I can.
3. I will research everything before claiming I have the best answer to a problem.
4. I will listen to all inputs before making a decision.
5. I am not indispensable.  Graveyards are filled with indispensable people.

If you can't manage to get your team to buy into this, then try it yourself.

And then, ask yourself this:  Am I doing this task right now for the sake of being truly innovative, or to meet some deadline or cost-control initiative?

My New Book is Out! The AutoCAD 2015 Network Administrator's Bible

"The AutoCAD 2015 Network Administrator's Bible" covers everything from new features and requirements, to building Network Deployment Shares, to deploying with Scripts, Microsoft Deployment Toolkit 2013, and System Center Configuration Manager 2012. 

There are also tips for working with VMware Workstation as a test environment,  handling .NET dependencies on Windows 7 and Windows 8, and slip-streaming updates and service packs during deployments.

I hope you like it. Please post feedback on the Amazon site to share your thoughts after checking it out? I'd really like to hear from you.

Cheers!

5 Creative Ways to Settle Office Disputes

We've all been in the situation where two people strongly disagree on which direction to take with regards to a business or technical strategy.  One vendor or another.  One process or another.  One policy or another.  It can become very emotional at times, and often leads to lost productivity and bad feelings that can linger on for days, months or even years.  In many cases, the lingering emotional scarring can impact productivity and quality of services for everyone involved.  Well, there are some semi-proven ways to deal with these situations in professional, productive and positive ways.  And who doesn't like a gosh-darn 3-P solution to a problem?  Huh?  Golly.

Here's a short list of five (5) suggestions that might help improve the situation and make everyone feel better enough to give each other a big sloppy kiss, without any hidden sharp objects.

Tip 1- Jello Wrestling with a New Twist

This one works great regardless of the gender bias that may exist in the room.  Everyone has to consume 1 gallon of Jello powder mix, then drink a 1 liter bottle of soda, and then get in a ring and beat the living crap out of each other.  First one to puke all over their opponent, wins.

Tip 2 - Paperwork Shuffle

Everyone in office environments likes to brag about how they suffer with the most paperwork, email, IM calls, voicemails, and so on.  Perfect examples of "first world problems" if ever there were any.  Imagine trying to elicit tears from a starving mother and her starving group of babies, too famished to swat away the incessant swarm of flies and mosquitoes.  They will pity you for sure.  So how about putting your money where your mouth is, and challenge the opponent to produce enough evidence to back it up?  The one who shows up with the most weight (use an approved scale obviously), wins.

Tip 3 - Marching Band

When the other person won't shut up, start humming the tune to something familiar like "Glory Glory Hallelujah".  Start quiet at first, then gradually bring up the volume until you can barely catch your breath in between gasps to belt out that next glorius bar.  Bonus points can be earned by pretending to march in formation, by yourself of course, around the conference room.

Tip 4 - Zen

When the other person continues to argue their point, refusing to hear your side at all, just stare at them without blinking as long as you can possibly manage.  Never, and I repeat NEVER, blink or look at anything else in the room besides their eyes.  They are like source of energy.  Feed off of them.  If you can stare at them long enough, one of two things are most likely to happen next: (1) they will call security for help, or (2) they will scream like a wounded baby and run down the hall as if zombies are trying to eat them.  Either way, the original problem should now become moot.

Tip 5 - Levity

When violence fails to solve a problem, humor often stands a small chance of working.  That's what most of the infamous world fascist dictators would say, or so I've heard.  Try this instead of a gun or knife:  When the opponent begins to raise their voice and shake their head in disagreement over some aspect of the topic at hand, start stripping off clothing until you're only in your underwear.  Not all at once, but remove one piece of clothing after each time they speak a phrase in disagreement.  When they finally realize what's happening, look at them and wait.  If they remain silent, offer this, "if you stop now, I win.  If you continue on, I will have to add whipped cream to this and keep moving."

If you try any of these out, be sure to post a comment below to let us all know how it worked out?  We'd love to hear your thoughts on this.  Have a swell weekend!

What They Don't Teach You in School

Math, English, foreign languages, Biology, Comparative Religions, World History, bah!  Even the programming/geek/nerd stuff.... bah!

These are the most important pieces of education a young person could ever absorb before entering the cut-throat job market today.  So, please, for your career's sake:  Put down the bong and pay attention!

1. Office Camouflage

Never look like you need something to do.  Carry papers in one hand, preferrably with a pen, and a coffee cup in the other.  Undo your tie and roll your sleeves up.  Even if you're just going to throw some trash away, make it look like you're on a mission.  A mission to advise the CEO that the CFO and CIO are both TFU and the only person who they can trust is  Y.O.U.  Look busy!

2. Shoes and Stalls

Every day you get to work, make a mental note of what shoes the other managers are wearing that day.   This only applies to members of the same sex (or whichever sex/gender inhabits the same restrooms you frequent). Knowing what shoes the CEO/CFO/COO/CIO/CTO/CSO/CIEIEIO wears can mean the difference between being fired and being promoted.

Think of the typical restroom situation where you're chatting with a coworker; you're shaking uncontrollably at the urinal, while he/they picks lunch leftovers from their teeth only an inch from the encrusted mirror.  You get ready to say something really apolitical about someone high-up, but you pause to sneak a glance at the shoes of the guy, just beneath the stall partition panel, who's moaning and grunting in the nearby stall.  You make a strategic correction.

Instead of "Man, that department manager is a real asshole.  Did you see how he tore the head off that cat in the staff meeting?!", you recall those shoes as being the CFO's, and then you remember that the department manager is his son.  So instead, you say something like "Man, that department manager is awesome.  The way he used his bottle-opener on that cat was genius!  His dad must be SO proud of him.".  Next day you show up and there's a calendar invite to a private meeting on the CFO's yacht, dinner included, dress appropriately.  See?  It's just that easy.  And you thought "hard work" (whatever that is) really matters.

3. Big Words

If you can read a beer bottle, a Hunger Games chapter, medicine bottles, cereal box labels, a verse from the Bible (or other religious text of your choosing), you have all it takes to read another exciting book:  The Dictionary.

Learn a new word, at least once a month.  Instead of reacting to surprising news with tired, old, phrases like "wow!", try something more ear-catching like "Gadzooks!" or "Jumping Jehoshaphat!".  It shows you might be what they call "Educated" or something.  And we all know those suit-wearing folk LOVE them some good ole educated folk to hang out and chew the fat with.  I mean, "have a intelligible conversation and discourse with".

4. Statistical Stuff

Learn something about the sport and sports teams/leagues/players that you know excite the upper management.  Then you can combine it with the tips above, and then practice in the restroom, while urinating on the wall, noticing the CEO's shoes in stall number 3, who happens to be a Texas Rangers' fan, and say something clever, like "Wow!  Did you know that Nolan Ryan could throw a baseball through the armor-plating of an Army tank while blind-folded and drunk on Drano?!  Amazing!"

Wait for the reaction.  If you say something clever enough about their favorite sports thing, or NASCAR thing, they'll jump right out of the stall with their pants down, toilet paper hanging from their butt cheeks and give you a hug like a long-lost relative coming back from the dead.

5. Strategic Posing

Do not EVER look relaxed at your desk.  Stare intently at the screen as if you're watching a live broadcast of a hamster, slowly unhinging it's jaws to swallow a cow in one piece.  The look must be serious.  It must be practiced to perfection.  Nobody who does *real* work does it without some effort and nothing shows effort like that classic Clint Eastwood, tight-jawed, seven day constipated grimace of serious ass-kickery that just oozes the feeling of "I'm busy curing Cancer, and world hunger, so back off bitch!"

Helpful tips include frowning, squinting, pursing of the lips, rubbing your chin and nodding slowly up and down.  For extra points, combine them in pairs or all together at once.  Then slowly rise from your broken desk chair and back away without blinking, or looking away even once.  Say something quiet, but just loud enough so the nearby idiots can hear it, like "yes.  yes.   yesss!  that will change EVERYTHING." and then go to the restroom to practice steps 1 through 4.

Conclusion

So there you have it.  All the basic skills you need to master in order to excel in a tech job in America. After all, the real jobs are going overseas anyway, so you might as well enjoy the ride while the ship sinks.

Don't ever say I didn't try to help you get ahead.

IT Kool Aid Flavors: Vendor or Reality

There are two general realms, or flavors, that exist in most of the IT world.  The vendor flavor, and the reality flavor.

Case in point:

According to one reseller, the world is running, or eagerly in the process of pursuing, a "pure" Windows Server 2012 R2 and Windows 8.1 / Update 1 environment.

Other sprinkle-toppings may include flavor crystals like all the 2013 products (but don't forget SQL Server 2014), and of course, the ubiquitous "cloud" world and Office 365/Azure.  And don't forget, if you bundle you get a free kid's toy.  Is this for a boy or a girl?  Do you want to super-size that as well?

And, please don't get me started on how to properly pronounce Azure.

Anybody still using XP?  Vendor says: Pfffft!  I think not (p-shaaaa!).

Not so fast.

The uncounted, 70-90% of the computer-swilling world doesn't have the luxury of IT project plans, operational efficiency directives and SLA's to worry about. They're busy trying to make things, sell things, build things, fix things, provide services, and all that mumbo-jumbo. The kind of stuff that a lot of larger shops don't seem to have as much "direct / hands-on" exposure to anymore.

Nowadays, many larger shops have grown into detached sector/division/department/project/task-group/tiger-team environments, where they fit into a mesh of bean-counter menageries that eventually lead to something that tickles shareholders and keeps the paychecks flowing.

I have no intention of offending or insulting anyone by this (well, okay, maybe some resellers and sales-folks), but the truth can be summed up in a very simple example:

Kathy's landscaping shop has a few apps they bought with personal funds to help with designing backyard ponds, estimate water coverage, soil depths, and seasonal impacts on gardening.  They bought them when they bought their prized Dell or HP desktop they still use with Windows XP.  And guess what:  IT STILL WORKS.  In their view, shiny new touch-screen tiles and cloud things are not as exciting as kicking the shit out of the revenue numbers compared with the nearby Lowe's or Home Depot.

Their IT support center?  1-800-ASK-DELL or 1-800-WHATS-YOUR-KIDS-FRIENDS-NUMBER-AGAIN?

Sure, there are distinct, and tangible values to the new features provided by Windows 8 and so on, but for many (okay, dare I say: most) small businesses, and home users as well, the deciding factor is "why do I need to buy another new computer if the one I have still works?"  For many small "mom-and-pop" shops, the apps they depend on aren't tops on the lists of bigger companies.  They tend to be very industry-specific, and extremely function-specific as well.  Things that perform one task, maybe two, but do them well, and are also either cheap, or free.

Ask any software repackager who deals with more than a hundred titles, and they'll probably have no trouble recalling a list of those "oddball" apps that are tough to wrestle into a package, but for whatever reason, HAVE to be made available or the planets will spin out of orbit and gravity will dissolve.  Floral arrangement apps may seem stupid, but tell that to a small, family-owned Florist.

The consumer isn't broken. The rationale isn't broken either.  And neither are the products. What's broken is the sales pitch.

Remember the Daffy Duck salesman episode?  Hey Bud, you need a house to go with this door knob.

PS.  In case you're wondering, the photo depicts (for me, anyways), from left to right: me, a vendor, and a small-business owner.

Asset Inventory 101 - Myths and Realities

This post is the result of trying to explain IT inventory to multiple people, multiple times, and them still not "getting it".  Rather than wear myself out, which I will probably still do anyway, I plan on pointing them here to read my thoughts on it, and I can then go back to babbling incoherently to myself.  I promised to post a "tech-oriented" article soon, but this is borderline, so nanny-nanny-boo-boo, I'm counting it as tech-oriented.

If you ask me about Inventory, I will ask if you read this article.  If you say "no", I will tell you to read this article and walk away, probably while laughing.  If you say "yes", I will say "go back and read it again", and laugh even louder.

What is Inventory?

Definition...

(noun):  A complete list of the things in a place".

(verb):  the act or process of making a complete list of the things that are in a place : the act or process of making an inventory". - Merriam-Webster's Dictionary

Go back and read that again.  Got it memorized? Okay, let's look at the noun side...

Inventory Science 101

What is "inventory" really?  Basically, it's supposed to be about tracking and reporting what you own, or what you have, and where it's located.  But there's usually a lot more to it than that.  Who's using it.  What it's used for.  Who bought it.  Who pays for it.  How it is configured.  What it's related to, or associated with.

There's also the Manufacturer. Model. Part Number.  Serial Number.  Contract number(s). Department/Division/Sector/Group/Team/Project names and numbers. And let's not forget the abstracts like category, type, family, class, species, and all that.

The goal of inventory, and inventory tracking efforts is, or should be, to confirm existence, disposition and ownership of assets.  The real goal being a financial implication of course.  What do you own?  Where is it?  Who is using it?  What is it used for?  Who's paying for it?  When does it "expire"?

The most common method for gathering and tracking inventory is what is commonly referred to as "input-output differential".  Capture what comes in (purchase order, or birth certificate), what goes out (inventory record audit, or death certificate) and finding the gaps.  The gaps are where the fun really begins.

What happened to it?  Lost? Stolen?  Transgender operation?  Was it really the property of the organization, or was it loaned to them for temporary use?  Was it a demo from a vendor?  The list goes on and on.

Just as a Census tries to verify you're still among the living, breathing creatures, who are paying taxes and adding to landfills... so are the aims of products like Microsoft System Center Configuration Manager, Solarwinds, Tivoli, Kaseya, LabTech, and (cough-cough) several products I've developed in the past as well.

So, in addition to what came in the door, and what is known to have departed, there is now a third status of "what's it doing now?"  Things that can be poked at to verify where and what an asset is, include Active Directory, network monitoring systems, PING, and so on.  An "Asset Manager" job title can often involve a lot of legwork.

What Constitutes "Things" and "Places"?

If we use YOU as a metaphor, then a human being is an inventory asset or item.  The place would be (or could be), your home address.  It could also be your employer's address, or your car (VIN or license plate).

Now, think of all the "things" that pertain to labeling YOU as an entity.  Your birth certificate.  Driver's license.  Voter registration.  Tax bills.  Credit cards.  Bank accounts.  On and on.

Do any of those things GUARANTEE your existence?  No.  Do they confirm you are still among the "living" (I'll leave that for you to decide on the definition)?  No.  They are simply artifacts that help SUPPORT the assertion that you exist.

Metaphorically Speaking:  Computers

Now that we've strolled off into metaphor-land, let's bring it back to the meat-and-potatoes: Computer assets.  Desktops, laptops, tablets, smartphones, appliances, routers, hubs, switches, printers, power supplies, storage units, MODEM's, peripherals of all kinds, you name it.

What is the birth date of a computer?  The date it was purchased?  The vendor warranty start date?  The OS installation date?  The technician-installation date?  If you base it on the OS install date, and you reinstall the operating system, what happens to the birth date then?  Does it fall back to something else?

If you purchase it, and it takes a while to get from the warehouse, to the workbench, to the truck, to the technician to being delivered and setup, which event date are you picking as the "start" or "birth" date of that asset?  Have you consulted your Finance folks about this?  Your attorneys?  You should.

When you record the purchase and deployment of this asset, what then?  Do you track it during the rest of its life?  Do you track the retirement and disposal of it too?  Some places do.  Some don't.  Some are required by law to track some, or all of this.  Which are you required to track?

Just because you "Can", does that mean you "Should"?

If you are an IT person working for someone else (i.e. not self-employed), and you haven't sat down (or consulted with) someone in a legal and/or financial role in your organization, I strongly recommend you do so before embarking on any effort to track and report inventory of any kind.  I cannot stress that enough.

Even if you are self-employed, talk to an accountant or legal advisor about whether you need to track thigns, and what to track.

Some questions to ask:

• What are the tax implications?  
• What are the support contract and cost implications?  
• What are the regulatory compliance implications?  
• What are the IT support implications?  

Did you notice I put IT last in the list?

From my experiences, most businesses track more than they need to, and ignore things they shouldn't ignore as well.

Ah, Yes:  Software

Just when the folks feel good about their grasp of tangible hardware inventory, we open the gates and let the starving lions and alligators into the arena:  software licensing.

Definition:  Software = "the programs that run on a computer and perform certain functions" - Merriam-Webster's Dictionary

What does that mean?  What is a program?  Is that Microsoft Word?  Is that the Snipping Tool or Narrator feature?  Is that .NET Framework 4.5?  Is that Java Runtime?  Is that a DLL or COM file?  Is it a locally stored App-V or ThinApp reference?  Is that a shortcut to a MED-V or remote VDI resource (desktop or application)?  Is that a URL to a web application?  What is it?

What does that mean?

If you query a computer for what software it has installed, where do you begin?  Does it all exist in the Control "Add or Remove Programs" list?  Usually.  But not always.  How about crawling through that icky Registry?  More stuff, sure, but is it easy to parse and understand?  Hmm.  How about crawling the good old file system and parsing through EVERY SINGLE FILE that is known to have an executable capability?

The answer is yes.

Configuration Manager, and products similar to it, often dissect a computer from many angles.

This includes files, folders, the Registry, and my personal favorite: WMI.  Slithering through the various CIM repository stacks can yield all sorts of juicy bits of data about hardware and software.

But... Is this really what you're after?

So you have a product installed.  Now what?  Does that constitute a 'license'?  What is a license?  What kind of license is it?  Per-machine?  Per-user?  Per-CPU?  Per-network?  Per-domain or site?  Per-company?  Open Source?  What?  And what about FlexLM type licensing, where the node doesn't matter as much as the total, concurrent usage limit?

If you have the option to use floating/network licensing for groups of similar products, I always recommend that option if you can afford it.

Software Licensing Audits

If you've ever witnessed a license audit from an external investigation, it's not fun.  They tend to come in one of two flavors:  Vendor and BSA.  If the vendor audits you, that's good.  They want to keep your business, so they will try to negotiate terms to help avoid losing your business, if possible.  If the BSA, or another third-party entity, comes knocking, swallow whatever pills you have left and take a deep breath.  It may very well be an unpleasant experience, as they are paid by levied penalties and have no need to retain your business.

So, while you can get sloppy about hardware inventory, I would not recommend you take the same light-hearted approach to software inventory.  I've seen "settlements" applied that nearly ended a business due to the costs, but thankfully, in none of those situations was I aware or implicated of the neglect prior to the doors getting kicked down.  Don't be one of those businesses.

Okay, so that covers a bit of hardware and software.

Simple as multivariate Calculus and molecular bonding, and clear as mud.

Are you starting to drink yet?  You will.

Summary

If anyone says there is, or should be, "one inventory source" to answer all of these questions, they are brain damaged or stupid.  The desire is noble.  The reality is clear: a singular source of "authoritative" inventory data is impossible.  It has to be derived and reconciled from multiple angles.

Think about that every time you're walking through CostCo, Sam's Club or BJ's and you see a clerk scanning shelves to do "spot check inventory".  If there was one system to track and verify all of it, that wouldn't be required.

Every time I sit in a meeting where some vendor comes in to pitch some magical product to report all of their inventory without any outside help, I look at my shoes, smile and think about my next alcoholic beverage, saying to myself "here we go again..."

Dave's ill-informed, under-educated, dumbass "Top 5" Rules for IT operational success

Dave's ill-informed, under-educated, dumbass "Top 5" Rules for IT operational success.

1. Clear Direction

Can you state the reason, rationale and impact of any task or project in ONE SENTENCE?

Yes - Proceed
No - You are doomed to horrific failure

2. Chain of Command

Do you receive ALL of your tasking from your direct line manager?

Yes - Proceed
No - You are doomed to horrific gang-raping failure

3. Personal Cohesion

Do the people in your group, team, or project get along well on a personal and personality level?

Yes - Proceed
No - You might succeed, but you will eventually fail in a horrific way

4. Personal Interest

Is it fairly normal for the people on your teams to work additional hours because they LIKE doing what they do, as opposed to doing it in order to avoid getting reamed in the next status meeting for falling behind?

Yes - Proceed
No - You are doomed to tragic, catastrophic failures of Biblical proportions.

5. Vendor Agnosticism

Do most of the decisions regarding strategic operations (hardware, software, internal and external services, staffing, etc.) tend to be knee-jerk towards one vendor per category, or are they up for grabs during each review?

Yes - There is hope for your organization
No - Forget it and start putting in applications at another place as soon as possible

The IT Cross-Training Myth (That Never Dies)

I'm overdue for some deep technical stuff, but for now I need to express my pseudo-philosophical side a bit first.  I promise to post some geeky stuff soon, but in the meantime, drink some wine and ponder my stupidificationary tales of peculariarty...

(deeeeeeep inhale...... exhale.... and fart.)  let's start.

We've all heard "SMB" (small-to-medium sized business).  Then there's MLB.  That's medium-to-large sized business, not Major League Baseball.  Depending upon who's rule book you follow, that's anywhere from 1,000 to 5,000 computers/user accounts at the bottom end, up to whatever.  In those types of "enterprise" environments, the IT staffing environment is often well-organized (on paper), and there are distinct structural lines of communication and command.  In most; not all, but let's keep moving.

Depending upon the budget situation, which tends to follow economic cycles and industry lines, the staffing may or may not be aligned to what (a) IS being done, and/or (b) NEEDS to be done.  When it's out of wack, it tends to go in one of two broad directions:

• Too much staff, which is like a hammer looking for nails to pound, or,
• Too few staff, where most of the real "worker-bees" are struggling to handle multiple distinct roles, let alone putting out daily fires.  

Regardless of which type of environment exists, there's often that tired, old, edict that gets spewed out from the suit gang like tropical storms spew from the western coast of Africa to become hurricanes:  "Cross-Training".

Not the kind that Nike sells.  I'm talking about the kind where you get pulled into a room and given a nice, puffy, soft, sweet-smelling speech about how everyone is going to magically learn what the other folks in their department/division/sector/team/workgroup/squad/platoon are doing.  Not just "learn" what they do, but HOW they do it, to the level (supposedly) where anyone (read: ANYONE) of the other IT staff could "fill-in" to address a crisis situation.  By the way, this speech usually comes with a fresh side order of seasoned fries and a request to start documenting all the stuff that you do every day (aside from slacking off).

I've been working in IT for about 35 years.  I have NEVER seen this plan work.  Never.  I've never even heard of it working.  I've poked my head into quite a few different, diverse organizations from private sector to government, from small to large, from education and medical, to municipal and industrial.  Nobody I have ever spoken with, emailed, IM'd or grunted at in a McDonald's serving line, has ever even heard of someone's cousin who lived next door to a friend who knew a lawncare person that grew up with the Uncle of the neighbor who drove the bus to the elementary school of the kid who heard about another kid that knew of someone who married the best friend of another friend who took violin lessons from a lady that heard of this EVER working as intended.

Never.

I have no doubt it's been tried with passion and desire; tried with extreme effort and intent.  I'm not saying the folks involved haven't given it their best shot either.  The problem is that the model itself is inorganic and doomed to failure.

A bee doesn't learn how to be a butterfly.  A dog doesn't learn how to be fish.  Sure, a dog can swim and a bee and fly from flower to flower.  Neither qualifies as filling the other's role however.  I'm sure some of you are laughing, scoffing, hrmph-ing and puffing too.  "This Dave guy doesn't know shit."  That may be true.  I do know about shit though.  In fact, I stepped in some today while throwing the ball with my son, but that's for another story.

The goal is often lost in this effort: To gain efficiencies from avoiding staff bloat, while mitigating dependence on individual staff skills and experience (read: holding the employer hostage). But when you shuffle a bloated staff, or distract an overwhelmed staff, it's like a quarterback throwing the ball out into the parking lot.

Here's the fundamental problem with the IT cross-training model:

In scenario (A) where there are too many staff for the jobs at hand, there's no gain because the staffing is still inefficient, and now even more inefficient because they'll never retain the results unless they make a permanent transfer.  Cost is being flushed down the financial toilet already.  All that this new approach does is swirl the turds the opposite direction (remember that stuff about north/south of the equator?).

Also, in scenario (B), which is much more common, by the way, the problem is rather obvious:  In order to take time to learn another role, you have to give up at least one (usually several) other roles; resulting in performance and quality lags. Each hour they're away from job number 1, the issues pile up, and the digging-out effort is geometrically scaled, at best.

Also, if the person really wanted to learn about job number 2, they would have already put in some effort or a transfer request to indicate as such.  Did anyone bother to correlate that with the cross-training mapping list?  I doubt it.

Let's say you are one of those in an under-staffed IT shop, and your official duties include AD accounts management, password resets, group maintenance, and the usual admin toiletries.  Meanwhile, your real daily tasks include WSUS, GPO's, dealing with server issues, networking issues, firewall issues, backup issues, patching, patching and more patching, the ever-exciting application conflict and prerequisite horrors, tracking licenses, tracking inventory and don't forget...... DO-CU-MEN-TA-SHUN.  Which nobody has time for (unless you work in scenario A of course).

Ah, the smell of documentation.  That whole "operationalize" stuff.  It smells like, like.... like.... victory.  Oh wait, that's the stuff I stepped in earlier.  Never mind.

So, now you're told to drop all that you normally do for a day to go sit beside the foul-smelling person who handles the firewall and web filtering stuff, and learn about what they do all day.  Or maybe it's the storage folks, or the InfoSec folks, or the application developers (they have great coffee you know), or the tier 1 desktop support shop (the best place anyone could dream of, right?).  You've ignored your normal stuff for a whole day.  Nice.

Then you come "back" to your old, coffee-stained, scratched and dented desk, with that same Dilbert calendar page pinned on the cube wall, and you've got two days of backlogged problems to work through. Your desk phone message light is also blinking.  You may want to check that.

Meanwhile, all that stuff you took notes about (you did take notes, right?) is gradually fading from your brain.  After another day of yet more small tasks and a few bigger ones, some sports chatting, a couple of meetings and phone calls, it all starts to slip further and fuuuurrrrtheerrrrr away.  By the next Monday, you're right back into your regular routine.

In short time, you can barely spell the job title of the other person you sat beside and the note pad is stained with coffee rings and covered in more papers.  Net gain?  Zero.

Sure, there's potential.  It's not quantifiable by any means though.  I've yet to find one analyst who can show me a concrete example where this concept has played out to anyone's measurable gain.  The only gains I've ever seen are perceptual (it sure feels good to ignore the usual pains for a day or two, and management gets to say they've "executed" another process improvement plan.  they love that "execute" word don't they?).

It's a nice, easy to sell, easy to grasp idea.  But like peace in the Middle East, it just never seems to happen.  I mean, come on: How hard can it be for two people to sit and talk through their differences and just get along?  Hmmmm?  After all, the stakes are so much higher, it has to be more likely to work itself out than dealing with your silly little IT staffing challenges.  Right?

Every time I sit through another meeting where this topic is raised, it reminds me of how my parents used to look at the "latest teen sensation" and moan and roll their eyes.  Then I hit 40, and then 50 and realized what they were seeing.  It's the same old thing, wrapped in newer terminology and a prettier PowerPoint slide deck.  It's not a pig.  It's a pig with lipstick this time!!  Yeah!

Experts Guide to Home and Small Business Wi-Fi

Thinking of buying a shiny, new, extra-double-spiffy new Wi-Fi router at Costco, Sam's Club or Best Buy?  Maybe online?  But maybe you're not really comfortable setting it up yourself?  NO problem.  I'm from IT and I'm here to help.

1. Before you buy a new Wi-Fi router, be sure to try the standard IMNDSICUT process.  That's short for "If my neighbor doesn't secure it, I can use it".  It goes like this:
1. Turn on your mobile device (laptop, tablet, smartphone, etc.)
2. Click the link to search for active Wi-Fi networks.
3. Look for the ones that do NOT have padlock symbol.
4. Try connecting to each one until you get one that works.
5. (tip: Be sure to check for any applicable local, state and/or federal laws that might cause you some concern before doing this.  If you get in trouble, you read this on someone else's blog and my name is Bob)
2. Next, if the above process doesn't pan out and you're a small business, rent space near a Starbucks, McDonald's, or any other retail or fast food chain outlet that offers free wi-fi.
3. Next, if that doesn't pan out, run an ad on Craig's List for a room mate that is good at setting up Wi-Fi networks and also (this is important, pay attention) has a new wi-fi router.
4. If all of the above options fail, you need to buy a new router.

You're all set!  Good luck - and happy wi-fi-ing!

:)

IT Catastrophes: Triage and Compression with Fries and Coke

Triage (noun)
(b) the sorting of patients (as in an emergency room) according to the urgency of their need for care

Compression ()

The state of being compressed (re: reduced in size or volume, as by pressure)

(source: Merriam-Webster online dictionary)

This is another one of my silly-brained IT monologues about subjects which are rarely discussed.

What I'm talking about is a loose comparison and contrast with these two words as they relate to medical and technology fields.  It is however a very real subject (or subjects) for those of us who occasionally deal with critical outages, especially those which involve things like:

• Highly-Available Hosting Services (think: Google, Microsoft, Facebook, etc.)
• Mission Critical Systems (think: Defense, Lifesaving, etc.)
• Service Level Agreements (the dreaded SLA's)

It's kind of funny how most businesses feel their operations are "mission critical" or "highly-available", when they're being subjective.  From an objective view however, it's not always as "critical" when things go "down" for a few minutes; even a few hours.

By the way: Compression, as it pertains to this article relates to the compression of time in which you have to operate in.  The time between a failure and sufficient restoration of services.

When dealing with a system outage in a truly "critical" environment, the first steps are pretty much the same as what an Emergency Medical Technician (EMT) would have to consider:

1. What exactly is not working?
2. How serious is the impact?
3. What is known about what led to this outage?
4. How long has it been down?
5. How much time is left?

You were probably thinking of the Who, What, Where, When, Why and How sequence.  I kind of tripped you up with two What's and three How's.  (Technically, #4 could be a "when", and #2 could be a "who" or "where", but whatever).  Let's move along.

With regards to a human, the general rule of thumb is 4-6 minutes, total.  That's about how long the brain go without Oxygen and still recover.  Compression CPR is usually the first course of action to sustain blood flow; keeping the remaining oxygen-rich blood reserves moving through the brain.  Enough pseudo-medical blabbering.  The main point is that there is a "first-course of action" to resort to in most cases.

What aspects are shared between a medical outage and an IT system outage?

• There are measurable limits to assessing what can be saved and how
• There are identifiable considerations with regards to impact on various courses of action
• Techniques can be developed and stored for more efficient use when needed
• Steps can be taken to identify probable risks and applying risk mitigation

With regards to a system-wide outage, the general rule of thumb is not so clear-cut as the 4-6 minute rule.  It truly varies by what the systems does and who (or what) it supports.  Consider the two following scenarios:

Scenario 1

The interplanetary Asteroid tracking system you maintain is monitoring a projectile traveling at an extremely high velocity towards planet Earth.  The system "goes down" during a window of time in which it would be able to assess a specific degree of variation of its trajectory.  The possible margin of error from the last known projected path could have it hit the Earth, or miss it by a few hundred miles.  The sooner the system is back on line, the sooner a more precise forecast can be derived.

Every hour the system is offline, the margin of error could potentially be re-factored (and reduced) by a considerable amount, possibly ruling out a direct hit.  The best estimate of a direct impact places the date and time somewhere around one year from right now.  Your advisers state that it would require at least six months to prepare and launch an interceptor vehicle in time to deflect or divert the projectile away from a direct Earth impact.

Scenario 2

Your order-tracking system for MySuckyShoes.com is down and customers are unable to place orders for new sucky shoes.  Your financial manager estimates that during this particular period of the year, using past projections, combined with figures collected up until the outage, every hour the system is offline, you are losing $500,000 of potential sales revenue.  The system has reportedly been offline for two hours.  So far, that's $1 million bucks.

Which of these scenarios is more critical? 

Answer: It depends

What are the takeaways from each scenario?

• How long do you have to restore operations before things get really bad?
• Having the time window defined, what options can you consider to diagnose and restore services?
• How prepared are you with regards to the outage at hand?
• What resources are at your disposal, for how long, and how soon?

In the first scenario, you have roughly six months to get things going.  Odds would be generally good to assume you can restore services sooner than that, but what if the outage was caused by an Earthquake that decimated your entire main data center?  Ouch.

In the second scenario, the margin would depend on the objective scale of revenue your business could withstand losing.  If you're Google, a million dollar outage might be bad, but not catastrophic.  If you're a much smaller business, it could wipe you out entirely.

What's really most important (besides the questions about what systems are down, why, when and how) is knowing what the "limits" are.  Remember the 4-6 minutes rule?  SLAs are obviously important, but an SLA is like a life insurance policy; not like a record of discussion between the EMT in the ambulance with the attending physician back at the hospital ER.  One is prescriptive and didactic.  The other is matter-of-fact, holy shit, no time to f*** around.

QUESTION:  When was the last time you or your organization sat down and clearly defined what losses it can absorb and where the line exists whereby you would have to consider filing for bankruptcy?

Is your IT infrastructure REALLY critical to the business, or just really important?  In other words: could your business continue to operate at ANY level without the system in operation?

Forget all the confidence you have in your DR capabilities for just a minute.  Imagine if ALL of your incredibly awesome risk avoidance preparation were to fail.  How long could you last as a business?  At what point would you lose your job?  At what point would your department, division or unit fail?  At what point would the organization fail?  Or do you think it's fail-proof?

Stick Shift or Automatic: Software Deployment by the Numbers

No.  I'm not trying to promote sales of any books/ebooks, not even my own (cough-cough).  I am about to dive into a murky subject that many Windows-environment Systems Administrators and Systems Engineers have a very tough time understanding.  And, as if that wasn't enough, I would venture to bet that very, very, veerrrrrrrry few Business Analysts, Project Managers and executive management folks have even a basic grasp of this subject.

The irony of this is that this is about as fundamental to any medium-to-large scale IT environment as bricks are to building a big house.  But even a small business can benefit from this, so don't scoff and walk away just yet.

What am I talking about?...

Manual versus Automated Software Product installation, and Repackaging.

Two things which fit together like peas and carrots.  Or hookers and politicians.  Or Florida and hurricanes.

Yes.  It's 2014, and from what I can tell there is a frightening number of so-called "technology professionals" that sincerely believe that there is little or no difference in terms of cost or quality between these to approaches.  These two diametrically-opposed approaches, that is.  In fact, many think that manual installations are cheaper, even when dozens of installations are involved per product.  I am not joking, nor am I exaggerating.  Please read on.

Most of them, if fed enough beer, or Xanax, would bet their retirement interest on the assumption that the differences between these two are as close as driving a vehicle with stick-shift versus an automatic transmission.  That this is a monolithic, linear-scale, pound-for-pound comparison.

It's a good thing for them that the retirement interest on their fortunes is almost invisible to their overall balance sheet.  A few zeros can get lost in all that green I'm sure.  When you dig into the real numbers, the comparison is about as close as a boxing match between Mike Tyson on his "best day ever" and Richard Simmons after getting a root canal.

All kidding aside, let's do some math. mmkay?

Quasi-Scientific Analysis

Let's say product "Fubar 2014", from a well-known vendor, is required by 500 of your employees in order to "do their assigned job duties".  You have a minimum wage minion whip out a stopwatch and begin timing the installation on the first five computers.  The minion tallies up the results and hands it to you. It goes something like this:

1. Technician walks over to computer "123" in building 42, up on the 3rd floor, in room 112 and sits down. Time spent getting there by foot/bicycle/car/private jet/yacht or teleporter is, on average, 5 minutes.
2. Technician then logs on and opens Windows Explorer. 2 minutes (waits for initial profile setup)
3. Navigates to central file server share on the network (Active Directory domain environment) to locate the folder containing Fubar 2014 setup files and related files.  1 minute.
4. Navigates to "prereqs" subfolder to install individual products which are required before installing Fubar 2014:  Java  Runtime 1.5 (vendor says it can't work with 1.6 or later), then Apple Quicktime 7.1, Adobe Flash Player 11.5 (Fubar 2014 won't work with version 12), and a few other items.  10 minutes.
5. Double-clicks on Fubar 2014 "setup.exe" file to launch main setup. Clicks Next on the Welcome page.
6. Accepts default for installation target folder path, clicks Next
7. Checks the EULA terms and enters a license product key.  Clicks Next.
8. Waits for installation to complete. 8 minutes.
9. Goes back into Windows Explorer and right-clicks on a folder under C:\Program Files\Fubar to open the Properties form.  Modifies the NTFS permissions to allow members of the local "Users" group to have Modify/Change permissions on that folder and all sub-folders.  This is required since the users do not have local Administrator rights, so UAC has been a problem.  This has been known to resolve the problem, so your tech goes ahead with the routine modification.  5 minutes.
10. Tech goes into Windows Services and disables a service that Fubar 2014 uses to check for periodic updates, which users cannot install without elevated permissions, so this is a standard practice at your shop to disable it.  2 minutes
11. Tech opens REGEDIT, navigates down to HKEY_LOCAL_MACHINE\Software\Fubar\Fubar 2014\Settings\ and changes the value of "autoupdate" from 1 to 0.  1 minute.
12. Tech reboots computer, and waits for login screen to log back on.  2 minutes.
13. Tech logs back on (1 minute or less) and launches Fubar 2014 to confirm it works.  While still opened, Tech navigates into settings to change the option (Tools / Options / Data) to set the "Default library location" to a central UNC server path where all the users share templates and common items to maintain standards.  2 minutes.
14. Tech closes Fubar 2014 and logs off.
15. Tech goes on to next location and repeats this process.

Paying the Bill

If you kept track of the time spent above, that's 5+2+1+10+8+5+2+1+2+2 or 38 minutes.  That's without ANY interruptions or unexpected problems.  And that's assuming the computers are relatively new and performing well.

In reality, from tests I have witnessed over the past 5 years alone, in various enterprise environments from 5,000 to 50,000 computers, the average time to perform an installation of this magnitude is roughly between 35 and 50 minutes.  

When performed during business hours with people around in close proximity, the times averaged 45 minutes to 1 hour.

When additional problems had to be resolved, such as missing updates, recovering disk space, removing conflicting components, that range increased to around 1 hour 20 minutes to 1 hour 50 minutes.  

I haven't even mentioned:

• Time spent deactivating old licenses
• Time spent activating new licenses
• Time spent dealing with device drivers
• Time spent dealing with custom network interface settings
• Time spent on the phone dealing with vendor support:
• Large vendor: waiting on line, listening to 70's pop music, interlaced with endless repeats of ads for their other products, like their "new cloud services".  awesome.
• Small vendor: waiting for guy (company owner/programmer/tester/web admin/support rep) to move his cat off the desk so he can flip through his paper stack to find your purchase order.
• Impact on end-users while they wait for the tech to do their work
• Impact on production from unexpected conflicts with other line-of-business products which are only discovered after the installation because there was no lead-time testing afforded.

In situations where a previous version had to first be uninstalled before performing a new install of the later version (usually because the vendor didn't want to take the time to handle this within their new installation package) the time ranges increase to around 2 hours to 2 hours 30 minutes.

Simple:  35 - 50 minutes

Complex:  120 - 150 minutes

In beancounter English: that's a range of roughly 1 hour to 2-1/2 hours.

Repeat this times 500 and you get anywhere from 316 hours (simple) to 1125 hours (pain in the ass).

Multiply that times the technician labor of say, $9/hour (you're a cheap bastard, after all), and that equates to roughly $2,850 to $10,120 of labor.  For ONE software installation.

I'd guess you probably have more than a few products that would be handled this same way across your organization.

Are you starting to see where this is going yet?

Sanity Check Time

Now, let's crank this puppy through ONE cycle of repackaging effort and see how this spews out the other end of the meat grinder.

1. Software Package Engineer (hereinafter SPE) opens a CMD console within a guest virtual machine (VM) running inside of VMware Workstation or Microsoft Hyper-V (take your pick).
2. Navigates to folder where Fubar files are stored.
3. Launches setup.exe -r and completes a normal setup process.
4. SPE grabs the resulting setup.iss file from C:\Windows and copies it into new folder along with the original setup files.  5 minutes total by now.
5. SPE opens a text/code editor and loads a template script to enter some lines to handle checks for prerequisites like JRE, Silverlight, Quicktime and so forth.
6. SPE enters code to invoke the setup.exe with setup.iss and redirect the output to a new log file.  Total of 15 minutes by now.
7. SPE saves script and puts all the files into the new deployment source folder.  SPE launches a separate VM, which is configured to match the configuration of the computers in use by employees who will be getting the installation.  SPE runs the install using a command shell to ensure it runs "silent" and requires no user interaction whatsoever.  Total runtime, including launching the VM and logging on is now around 30 minutes.
8. SPE emails or IM's the designated customer SME (that's subject-matter-expert) who was nominated to be the "test user" and asks them to log into the VM using Remote Desktop and kick the tires.  Time spent contacting the customer about 1 minute.
9. SPE moves on to work on other packages or tasks while waiting for customer to respond and attempt the testing (parlance: User Acceptance Testing, or "UAT")  No time expended by SPE during this period by the way.
10. Customer gives the package "two thumbs-up!" and the SPE moves it into staging for production deployment.  SPE creates a new "Application" in System Center Configuration Manager 2012, creates a resource Collection with the computers to be targeted, and assigns the Application to the Collection using an Advertisement.  10 minutes (he's drinking decaf this morning)
11. Advertisement is scheduled to run after hours, avoiding impact on production time against the customer staff who will receive the new installation.  SPE does not have to wait for the installation because it is scheduled to run on its own, so he/she checks on it the next morning.

Total time spent:  5+15+30+1+10 = 61 minutes.

I realize I said "he" a lot, but "she" could do just as well obviously, so that's irrelevant.

Things I didn't include:

• UAT problems resulting in having to go back and make adjustments and retesting
• Pre-flight deployments to verify conflicts in production on a limited subset of computers.
• Next-day support calls for incidental one-offs like machines being offline or a service was stopped or an application was open and had a lock on a file that prevented the Advertisement from completing successfully.
• Cats walking across keyboards and causing a BSOD.
• Who knows what else.

Taking those things into account, the ranges can jump from 60-80 minutes for a simple scenario to 2 hours, for just a simple repackaging effort like the one Fubar 2014 involves.  

In the "real world" some products can be much more difficult to repackage and may consume days or weeks of development and testing in order to get a rock-solid package into production.  Those are rare, but even then, EVEN THEN, the savings when calculated across hundreds or thousands of computers, spread across multiple locations, states or continents, can be well worth the effort.  

Think of "mission critical" applications, where the time window to get them into production, with 99.999% success rate, is only an hour or two, end to end, over 20,000 or 30,000 computers.  That's not fiction.  There are industries where this is not uncommon, and they rely heavily on this methodology to ensure:

• Highest probability of success
• Consistent and predictable results
• Minimized impact on production operations
• Optimum transparency of all moving parts (think reporting and monitoring)

Steak Dinner Anyone?

So, this SPE makes $75,000 a year in USD, roughly $36/hour, and spent an hour building this simple package.  That's $36 to deploy one product to 500 computers over one evening without asking any users to step away from their computers during work hours.  

The cheapest scenario in the first example was $2,850.

The most expensive scenario in the latter example was $1,442.

Even if the SPE had to devote an entire week to one product, or roughly 40 x $36 = $1,442, that's a LOT CHEAPER than a $9/hour tech running around to 500 computers, or 10 x $9/hour techs running around to 50 computers each.

That's Not All

Billy Mays homage:  Now, if you go with the repackaging and automated deployment scenario, you have a mechanism in place that does the following for you without ANY additional cost:

• Provides automatic self-healing of deployments, to cover situations where a targeted computer is replaced or reimaged with a fresh Windows configuration.
• Provides simple, effortless scalability for future growth.
• Provides a robust auditing and reporting trail for accountability and compliance.
• Provides fault tolerance
• Provides coverage during non-production hours.

Still think that thumb drive is the way to go?  Hmmmm?

NIH

This may be a bit deep, but I just finished folding laundry at a nearby laundromat whilst a group of over-caffeinated high-schoolers pretended it was audition night for "The Voice" and "Tosh.O" in the same place.  After getting home and putting the goods away, I did dishes and consumed a tasty Dogfish Burton Baton and now my brain needs some playtime.  You've been warned.  Sit down.  Strap in.  Enjoy the ride....

To many folks, the term "NIH" means National Institutes of Health.  But to many folks in the legal field, particularly those specializing in intellectual property issues ("IP" law, that is), it means "not invented here".  It's a uniquely-American term, but the concept predates America itself actually.  Allow me to digress...

I learned this while doing some contract work in that field a few years back; patent drawings and technical procedure writing actually.  "NIH" refers to a policy some renown international corporate entities (I won't name any) have towards how they approach dealing with intellectual property.  This encompasses copyright, patents and trademarks, obviously, but it also includes service marks and more.

In basic English: If the item was "not invented here" they don't want anything to do with it.  In most cases, they mean "at all", as in "not in any respect whatsoever".  For example, if you invent some cool toy, and approached some particularly HUGE toy manufacturing corporation to negotiate some kind of "deal" (I'll leave their actual name to your imagination), and they adhere to the NIH policy, and you are not a direct-employee of that company, they will very likely ask you to leave.  If you continue to insist on a discussion, they may call security to help you find the door.

I am not joking.

So, during a recent discussion I had with some colleagues (past and present) about the subject of "why do so many IT organizations seem to abhor the idea of their own staff daring to develop their own tools for their own needs and then being so brazen as to ask their employers if they'd like to join in on the party?"  Keep in mind that this is not about selling the invention to the employer.  It's about asking the employer to put some elbow grease into it and help launch the airplane off the flight deck with a little more "umpf!".  Of the six or so folks present, and their recollection of some two dozen secondary contacts and colleagues, not ONE of them could recall ever hearing of a successful effort in that regard.

Not one.

I am very familiar with this, as I have been, without planning or expectation, in the center of such situations, many times.  At my last four employers in fact.  I was present during the putting-out of some particular fires (metaphorically-speaking), in which there were NO available "off-the-shelf" solutions to be had.  None.  So we built our own (or I built my own).  Like many contraptions, mechanical or otherwise, which are conceived to solve a "real" problem, they tend to gain a life of their own.  Problems, it seems, tend to recur so having a tool which is custom-fit to solve it tends to be very appealing.  Especially when that tool or solution was provided at no "additional" cost to the parties involved.

Yes.  No additional cost.  Translation:  It was conceived, built, tested and applied using existing funding and task vehicles (that's beancounter speak for "it was part of my job duties, so I did it").  Even the technologies involved with building the tool were 100% "free".  Things like built-in API's, and SQL Server Express, IIS, scripting, etc.  Aside from the already-paid cost of the operating system license itself, there were no additional costs required or incurred.

So, why the fuss?

That's a good question.  A lot of theories were discussed around this one key aspect.  Everything from businesses shying away from stepping outside of their "core competencies" to "perceived risk" to "obligatory support liabilities" and so on.  Blah blah blah.  Fear.  It's just fear.  I add laziness to that, but fear and laziness go together like hookers and politicians.

Then it dawned on me that it's really about NIH.  I realize that fear+laziness nearly equates to NIH in most respects, but it has a different sauce poured over it.

What's even more interesting about this entire mess is that in none of the examples we could cite were there any alterior motives on the part of the employee/developer.  It was all above-board and in good faith, in which they not only accomplished the item in question, but in how they approached and engaged their employer.  The employer however, no matter how the approach was toasted, garnished and served-up, consistently took a hostile, defensive stance in regards to their reaction to the employee.  As if indicating their distrust in the employee; probably assuming the employee concocted the whole idea just to negotiate a deal in the same sense as a blackmail operation.  Holding them hostage.  Whatever that could mean.

But the question remains: why?  Why not actually hold detailed, sincere discussions with the employee, rather than closing the gates and shooting arrows off the guard towers?

Legal risk.  Once again, attorneys, and their corporate financial overlords (retainer clients, usually) have successfully cultivated an atmosphere of risk-avoidance.  Risk avoidance is another name for "fear of innovation".  Imagine if Henry Ford were told that challenging horses would land him in court?  I'm sure someone tried it, but what if he actually caved in to that?  Oh boy.  You can argue that the environment would have fared better today than it has already, but think of the wider ramifications of that.  Now, start that idea-clock in motion today and imaging where it will be in 50 or 100 years.

It's already too late to save our federal government system from the corruption of corporate PAC influences.  Let's not let the rest of the baby go down the bathtub drain as well.  There's a few companies and entrepreneurs out there still taking risks (Elon Musk, Richard Branson being just two of them), so maybe there's still hope things will turn around in favor of imagination and risk-taking.  It can only work when it's cooked in the same pot as the money comes from though.  It seems those of us stirring around in the bottom ranks of the IT world are going to have to fight our way out day by day, in spite of the risk-averse surroundings.

But I digress.  Sweet dreams! :)

Walking the Walk

Quick post before I unplug and go comatose for the evening:  Tomorrow, when you get to work (or if you're in a different time zone and it's daylight right now) try this on:

1. Write down all of the key functions your IT group performs.  AD accounts, software deployment, patching, server provisioning, backups, storage management, cloud integration, etc. whatever.  List them out.
2. Identify the role(s) which relate to each of them:  Account Managers, App Packagers, App Deployers, Server Managers, Cloud Administrators, etc. whatever.
3. Assign actual names to those roles.
4. Compare that mapping with reality.  Grade yourself on a 100 point scale by checking off how many roles/people are actually assigned accordingly with what you are already doing today.

Let me know your score, what scale your environment is (small, medium, ginormous, etc.) and which country you're based out of.  Just curious how we all rate ourselves.

G-night!

The Professional References Dilemma

If you've held a job for more than a few years, especially the kind where you had to write (or borrow) a resume to qualify for an interview, you've probably had to list some "references" as well.

A professional "reference" is supposed to be someone whom you've known, professionally, long enough to tell a prospective employer good things about you.  Things like how well you work with others, your skill set, types of projects or operational work, and so on.

A professional reference is NOT someone you worked in the same office with, but didn't interact with every day. Nor is it one of your drinking buddies.

I'm not sure why, but I've been asked to give permission to list me as a reference for more than a dozen current and former colleagues.  I say that because my professional career path hasn't been the shiniest example for others to follow.  In some ways I consider myself the guy walking backwards through a minefield, giving out advice on how to detect mines.  Yeah, I saw that episode of Benny Hill.

The problem comes into play when someone you're friendly with, maybe really good buddies with, asks you to be a reference for a job they're applying for; but you can't honestly say you worked directly along side this person enough to vouch for every skill the new job is asking for.  Maybe you didn't work with this person directly at all.  The risk you take is that you may say "Sure, this guy/girl is an awesome ___. I'd hire them in a heartbeat.".  Then they get hired and things fall apart.  Now you're reference is devalued by having vouched for someone that just didn't cut it for them.

Granted, this is a risk for any such circumstance, but you greatly reduce that risk when you stick to your guns and only agree to vouch for people you truly KNOW about on a professional level.

This spills over into LinkedIn skill recommendations as well.  I can't count how many people have tagged me for a skill I barely know.  VMware ESX?  I played with it.  SharePoint? I can install it, configure it, build some sites and libraries and post pictures of cute animals.  After I started seeing notifications that so-and-so tagged me as an expert on these things, I began to go back and remove those items which I consider myself to be marginally skilled at best.

To be fair, it's not really something I can blame on my LinkedIn network, it's just everyone trying to help each other out, and that's very much appreciated.  But it also puts them at risk of damaging their street cred by saying I'm a pro at something that I'm really not that well-versed in.  To mitigate the chances of hurting their good intentions, I'm making the effort to clean up my skills list.  I think it's a good idea.

Back to ironing shirts for Monday staff meetings.  Cheers!

What $14 Billion Could Buy Today

Obviously, these are rounded numbers, but the scale is roughly accurate, even with regards to adjustments by fiscal year, geography, and so on.  Since very little is ever said about this sort of comparison and contrast, it likely indicates that most humans are comfortable with these priorities.  Enjoy.

• 1 new Nimitz class aircraft carrier (USS Gerald R. Ford)
• 39 F-22 Raptor jets (note 1)
• 65 completed MAX light rail systems (Portland, Oregon) (note 2)
• 9,333 miles of water supply pipe x 1m dia. (note 3)
• 280,000 artificial legs/limbs (note 4)
• 1,400,000 months of cancer treatment / chemotherapy (note 5)
• 13,725,490,196 miles of "standard" Internet cable (land-route, rural area) (note 6)

Notes

1. http://www.latimes.com/business/la-fi-advanced-fighter-woes-20130616-dto,0,7588480.htmlstory#axzz2stBhSgaU
2. http://en.wikipedia.org/wiki/MAX_Light_Rail
3. http://web.mit.edu/12.000/www/m2012/finalwebsite/solution/glaciers.shtml
4. http://www.disabled-world.com/assistivedevices/prostheses/prosthetics-costs.php
5. http://www.takepart.com/article/2013/05/09/cost-of-chemotherapy
6. http://www.timesunion.com/local/article/Rural-life-carries-2-647-cost-for-cable-2227166.php (based on $2647 cost for 2583 feet estimation)

BPA. The Other White Meat

I bet you expected a Chemical Engineering monologue about Bisphenol A.  Ha!  Fooled you.  Maybe you thought it was going to be about Business Process Analysis.  Nope.  I'm talking about the other BPA: Business Process Automation.

But: What is Business Process Automation?

Figure 1 - Standard BPA Results

If Business Process Analysis is the Systems Analyst of the MBA world, then Business Process Automation would be the Systems Engineer of the IT world.  I know that makes almost no sense whatsoever.

Some folks might say it (the latter of the two) is the practice of applying technology to execute tasks which normally require direct human involvement.

Some folks might say it is the practice of identifying which human-oriented processes can be handled by suitable application of technology.

Some folks might say it is the practice of applying technology to replace human labor to enable laying off human employees.

Other folks might say it's the culmination of hours and hours of studying to acquire yet another mysterious certification which nobody cares about besides them.

They are all correct.  Ding!  And they win what?  I will tell you what: hours and hours and hours of work.

How is a BPA expert made? What are the necessary ingredients?

1. Familiarity with the business on an operational level, from the bottom-most level to the top.
2. Familiarity with the business culture, at all levels
3. Common sense (okay. I'm just kidding)
4. A keen sense of humor (I'm serious about that too)
5. A healthy appreciation for caffeine and alcohol
6. Solid skills using Microsoft Word, Excel, Outlook, PowerPoint and a web browser
7. And, last but not least: an undying desire to stop any meeting, no matter how intense, and no matter who is in attendance, to ask "what the F**K are we doing here?!" (followed by an immediate return to playing with your phone)

You might think I'm joking.  I'm not.

Most BPA efforts go off the rails and directly through an orphanage house within a few days of starting the engine.  Why? Because they almost always focus on the HOW before the WHY. The WHAT before the WHEN and WHO before the WHERE.  Okay, I made those last two up out of thin air.  I couldn't mention just two of the W's (or a W and an H, or ughh, never mind).

BPA is really just a 2-stop process:

Step 1 - Analyze the living shit out of the process itself.  Do NOT... I repeat DO NOT, start working on the HOW part before you exhaust every angle of making sure the WHY is covered.  Is the process sound?  Is it as efficient and reliable as it could be?

Step 2 - Go back to step 1.  If in the efforts to refine step 1, you do not already trip over the optimal solution to the challenge, you didn't do step 1 properly.

Seriously: Of the last two dozen or so BPA-related projects I've been involved with, or was witness to in the past thirty years, I would say three of them actually followed this rule.  This covers everything from small private businesses to municipal, state and federal governments, to multi-billion dollar corporate conglomerates.  I've seen projects blow $50 million USD in the first three months before asking if the goals were really correct.  That's not an exaggeration.  In fact, the one person that did ask, was fired for asking. (no, it wasn't me, which is shocking, I know).

IT professionals are as vulnerable to this tendency as anyone else.  Mainly because we are creatures of toy fascination.  We like toys.  Program code, gadgets, appliances, algorithms, encryption schemes, formulas, you name it.  If it involves tinkering and refining, we're all in.  A bag of crappy food and some sort of liquified stimulant and we're game-on.  But that too often leads directly into the dreaded trap:

A new tool in search of a project.  Walking around with a hammer, anxiously seeking out a screw or cotter pin to use it on.

Tools are awesome.  But only as awesome as they fit with the task they're being used on.

Coming Soon - BPA Stupidity Part II - the Electric Boogaloo.

What is a Computer or Software Asset?

Is it a physical entity, or is it a virtual or logical entity?
Is it tangible, or is it an idea?
Is it a record of it being purchased?
Is it a box or envelope containing physical materials?
Is it a record of being on "the wire"?
Is it what YOU have a record of, or the what the VENDOR has a record of?
Is it an account in a directory database?
Is it an associated number in an inventory tracking database table?
Is it what was purchased or what is being used?
Is it what is being used or what was assigned?
Is it something you own or is it something you have a license to use?
Does it belong to the company or a person?

If you find 500 installations of a software product on your network computers, does that constitute 500 licenses?

If you purchased 500 laptops, and only have inventory reporting data for 400 of them, does that mean you own 500 or 400?

If you disposed of 1000 desktops but their accounts still exist in Active Directory, does that mean you still are using the licenses associated with them?

If I Were In Charge of Microsoft Right Now...

Yes.  This is extremely "pie-in-the-sky" stuff, but I need a mental break from working two jobs every day.  I'm sure you can poke a million holes in these suggestions, but whatever... enjoy!

1. Stop all work on the Windows OS and call a big-ass meeting to do a massive "reset" on that 400-headed beast.  Consolidate and streamline EVERY command utility, API, etc.  A common syntax for everything.  Eliminate overlaps and redundancy.  Retool for true 64-bit (or 128?) rather than the dragging on the current 32/64 band-aid stupidity.  Tell partners/vendors "f-u" if you don't comply with the new platform specs.  No more backwards compatibility work.
2. Redesign the interface so it adapts to the devices, rather than forcing you to use a tablet interface for a keyboard and mouse work environment.
3. Give away App-V for free (like MDT and WSUS are handled)
4. Get rid of MDOP as a product and make the rest of it (sans App-V) part of the Windows platform.
5. Get some fresh faces in the System Center group to retool Configuration Manager to be easier and simpler to (A) install and configure and (B) manage.
6. Revisit the "Essentials" idea.
7. Deploy physical "Microsoft Store" facilities, like Apple did.  Online shopping is cool but tinkering with shit in your physical hands shouldn't be ignored.  Oh, and include those nifty-ass Starbucks automated barista machines they have at their own campuses.  Those things kick ass.
8. Make ads that are funny.  If it doesn't make me laugh and cough my beer through my nose, then it needs to go back to the production room and get some more work.

Knowing Which Seeds to Water

(Warning: I've had some coffee today)

In The Beginning

In 1990, at the age of 26, I worked as a drafter for a small Naval engineering firm in Virginia.  It was my third job in the field of naval design, and I was assigned to work in the Piping Systems Division with maybe two dozen others, in support of contracts for overhauling U.S. warships.  It was during this time that PC-based CAD entered the foray in the defense industry.  ThisCAD and ThatCAD were everywhere, but AutoCAD was the eventual, and clear winner.  Until then, everything with "CAD" in the name wasn't even considered unless it ran on UNIX-powered hardware.

While learning to use this new "AutoCAD" tool, I tripped over something and looked down to realize that inside this little product was a shiny gem called "AutoLISP".  A customization programming tool, built right into the product!  Having tinkered with CMD and Batch scripting for MS-DOS and Windows, I was addicted from that moment on to programming.  Mainly because it made it possible to draw and "create" visible objects on the screen, rather than a bunch of numbers and text.

After a few weeks, I built some menus, functions (or "routines", as they were often called then), and eventually wrapped them in dialog forms and prettier stuff.  After sharing them with my coworkers, I began to get feedback and ideas started coalescing like a tropical storm into a hurricane.  The momentum continued to build and within a few months I had a complete "design package" for automating much of the tasks involved with creating and validating engineering and design drawings for piping systems.

Auto-Something-or-other

Not long after that threshold was crossed, I spread out into HVAC systems, and eventually into the other primary system groups involved with nautical engineering: Structure, Outfitting, Machinery, Electrical and Electronics.  Then it was on to building the top of this strange pyramid:  Notes, References, Sheet Formats, Materials Lists, Tables, and so on.  In much the say a Lego kit ends up becoming a city with elevated monorails and skyscrapers around a kid's room, I ended up gluing in data files, database tables and views, symbol tables, icon files, drawing parts (block inserts, XREFs, etc.).  Building on top of what a predecessor from our New York office had started, it became an entirely new animal.

My boss was supportive, as was the Department Manager, and the Division Manager.  But once it cleared the cloud layer, things got less clear.  I never asked for a raise or a promotion, oddly enough. All I asked for was the approval to tap a few key "power users" in each department to form a "team" to help improve this automation tool even further and faster.  Silence.

In 1996, I was contacted by a much-larger company, a nearby shipyard, to take on a newly created role of "AutoCAD Systems Manager" for an entire Division.  That meant a lot of things at once for me:  Automating the deployment (installation), configuration, maintenance and licensing of AutoCAD and AutoCAD Mechanical Desktop to roughly 1,300 users.  There were other Divisions, but they were tied to UNIX products and rebuffed any consideration of anything that ran on a scruffy PC. This offer also meant I'd take over licensing administration (i.e. FLEXlm), and my prized role: Customization.  Oh yeah, it also meant a considerable pay increase and better benefits, but customization was what I had my eyes on the entire time.

Project: Mariner

Within a few months of that new job, I began building an entirely new suite-based, collection of design automation tools to run on AutoCAD and MDT for Piping, HVAC, Mechanical, Hull-Structure, Hull-Outfitting, Electrical, and Materials.  This new beast grew a beard and a deeper voice and eventually was named "Mariner".  A fitting name I thought.  I sure get wrapped around the axle when it comes to choosing a name for software projects, but that's for another story.

This process continued to grow and I was allowed to form an unofficial "team" to help maintain and improve it as well. Once again, I never asked for a raise or promotion, but things seemed to progress much more easily.

Sometime in late 1999, this shipyard began contracting in designers from local firms to handle the capacity of work going on.  The contractors were required to learn this new abstraction layer, so I embarked on developing a training guide, a training course and even was authorized to issue training certificates for completion of the training.  Seriously, they printed some 1400 books with color graphics and sturdy permanent binder edges.  Nifty stuff!

Project: ShipWorks

In early 2000, one of the contractors asked if they could license this "Mariner" product to use back in their offices.  The rationale at the time involved a lack of physical space at the shipyard to bring in any more contractors, while the workload continued to rise.  I approached the corporate overlords, their legal masters and the contracts department gurus and soon there was a "first-ever" licensing contract produced to allow their "partners" to use this product.  Until then, no other such vehicle had existed, or so I was told.  Then, I inquired about approaching Autodesk or some other (no defunct) software vendor, to help take it to the next logical level: external marketing.  There was interest from nearly all of the outside contracting firms, as well as several software vendors.  The company said: "NO.  We are not a software development company."

Growing tired of the lack of management support, I accepted an offer to work for a local Autodesk product reseller.  I submitted my two-weeks notice and packed my belongings to move on to yet another employer.  On my last Friday, I received a phone call from the contracting firm that had initially approached our company about licensing Mariner.  They heard I was leaving and they counter-offered and, me being stunned and shocked, I accepted it.  I went to that new employer and, again, started development on a totally new product, incorporating all of the lessons-learned from the Mariner project.  This animal grew into something called "ShipWorks".  Much to the chagrin of Autodesk, it was not ever intended to run on Solidworks, nor was it ever attempted.  Still, they were obviously not too happy about the "works" suffix.  Just an odd side note now, I think.

That leg of my journey into the software technology world is where I officially transitioned from a mostly-engineering environment into a mostly-IT environment.  I absorbed managing Windows Server, SMS and Configuration Manager, WSUS, RIS and WDS and a whole bunch of other weird things that I found interesting and helpful, and which helped cut costs and make for a better computing environment.

In this new role, I was given a team, management support, resources and things finally to be on a good track.  Then in 2007, the company was sold and split apart.  I ended up bouncing to a consulting firm, which lasted about three months, when the economy tanked, and I had to make ends meet doing side work for a few months before crawling on my knees back to the shipyard and beg for my job back.  They graciously accepted.

From here on, I haven't touched AutoCAD much at all.  Most of the work I've done since involves things like ASP or PHP, along with SQL Server, Oracle, Active Directory, SMS or Configuration Manager, Inventory systems, Service Request systems, and so on.  Basically, gluing things together horizontally with a big bucket of sticky web application goo.

Looking Back

Every one of the places I've worked at, I've built something custom to help them operate more efficiently and tried to make the users happy with the results.  In every case, my immediate supervisors were very supportive.  In every case, when it went above my immediate supervisors things got shaky and less reaffirming.  The support and reinforcement began to vaporize the higher I went.

The Takeaway

Over the past twenty-odd years, I've seen more potential wasted because someone decided a project was not worthy of basic consideration.  Not even giving it a second thought.  The results could have been astoundingly helpful for a lot of people and businesses.  Too quick to judge, was always the culprit to killing the dream before it could begin to take shape.  I'm writing this today because I still see this happen too often, in too many places.

If you have a lone developer, or a small team of developers, within your business, official or not, and they are actually producing useful things, support them.  Especially if they don't ask for monitory compensation, but they simply want to see that management cares and wants to help them push it further.  Maybe it's outside of your "core business" comfort zone.  Maybe you never considered your business to include this mysterious thing called "applications development".  Try making it work anyway.  You say you have "gut instincts" for business, well, use them.  You might be amazed what good can come from it.  I'm not suggesting you rubber-stamp every app-dev project without checking on it's merits.  Verify and validate them all.  But just don't reject them simply because they involve "application development".  That's an unforgivable crime of business.

Cheers.