Is Your Team Wasting Time with Scripting?

I'm an MVP Award recipient from Microsoft, primarily for my work with its PowerShell technology, and you don't often see me use the words "wasting time" and "scripting" in the same sentence. But now it's out there: I truly believe that a lot of IT teams -- if not most -- are wasting time messing around with the scripts.

Let me be clear and state that this is not a blanket condemnation of scripting or of PowerShell. Quite the contrary, in fact. I believe in the right tool for the right job. Scripting is the right tool when the job is one of two things: First, whenever you have to automate some business process that is unique to your organization, and which cannot be efficiently accomplished in any other way. Second, whenever you need to automate some process that is rarely performed. In that instance, you're not really automating something that's truly repetitive; you may be automating it because it's done so infrequently that nobody accurately remembers how to do it. Either scenario points directly to scripting.

So what doesn't point to scripting? The automation of tasks -- particularly complex ones -- that are common across our industry, and which could be better and often less expensively accomplished by a third-party tool

Some elaboration is in probably in order. First, you have to understand that I do not expect Microsoft to provide tools to accomplish every little task that every organization in the world might want to perform with the company's products. Microsoft's job, in my view, is to provide a baseline set of tools and a solid underlying platform, and to do so in a way that enables third parties (whether your team or ISVs) to build additional domain-specific tools on top of what Microsoft provides. If your organization, for example, frequently needs to scan through file and folder ACLs to see who has permission to what, then I don't necessarily expect Microsoft to put a tool for that in the box. It just isn't a universally needed task (although I admit that this particular example is becoming pretty widespread), and even amongst the organizations that do need to perform this task there's a lot of variation in how they need the results presented.

So, third-party tools are, and should be, a way of life. When should you not build them yourself, and instead go to a third-party ISV for them? When those tasks are a critical, almost daily part of your business. Let's switch examples for a moment and consider the need to collect Active Directory auditing events into a single, consolidated, searchable log. You could certainly write scripts to do that, and I have a number of consulting clients who've done just that. They're limited to the information in the event log, of course, and that information isn't always the most human-readable. Most of the examples I've seen required an administrator to spend about a week building, and then perhaps 10 hours a month maintaining and tweaking. So in the first year, that's about $7,000 in man-hours. Folks usually spend a lot more time consuming that data -- the two customers I've worked with who took the time to quantify that work spent an average of 40 man-hours per month sorting, filtering, searching and presenting data from those raw event logs. They spent another 20 hours per month doing what I call "dealing with" the data -- for example, translating event IDs into a meaningful message, looking up SIDs and GUIDs, and so forth. All work made necessary by the low-level nature of the data in the logs. They assigned a value of about $30,000 per year to that effort. Round number, $37,000 per year total.

That's a lot of money. These same organizations steadfastly refused to bring in a third-party change auditing solution for close to seven years, meaning they spent about $260,000 in man-hours. One of them is still doing so. The other got sick and tired of the additional hidden costs of scripting -- like when its Script Guru left the company, and someone else had to spend three weeks coming up to speed on the scripts ($5,000 more to the bill). That company runs a 6,000-user Active Directory domain, and their third-party auditing solution cost them $108,000 in the first year and about $20,000 in annual maintenance fees thereafter. Five-year cost: $188,000. It's in the first year now, and its time commit on those same tasks is nearly zero because it selected a tool that provides exactly what it needs, more or less automatically. Even reports are produced and mailed out automatically.

That's just one example, and the point isn't so much that one company's specific numbers as it is the general theme: Scripting isn't free. It requires man-hours, even just to maintain, and comes with a big risk that your "Script Guru" will leave you in a lurch at some point. You can mitigate that by educating more of your troops in scripting, of course, but do so strategically. Focus on the tasks that don't need to be run often (making script maintenance less expensive), or focus on tasks for which an affordable tool simply isn't available. The argument, "Well, if they weren't writing scripts, we wouldn't need those people" doesn't hold water -- there's always work for an admin. Let them be admins, not software developers. Look closely and you may find that tools to automate daily, mission-critical tasks are less expensive in the long run, provide better functionality than you could script yourself and do a better job of meeting all of your organization's business goals.

I'm not saying don't script. I'm saying script when it makes sense. Be a strategic decision maker.

Posted by Don Jones on 04/25/2011 at 1:14 PM