Get Rid of Custom Scripts to Reduce Risk and Improve Scalability

What are the advantages and disadvantages of custom scripts in your daily technology operations? It seems at first thought that using custom scripts for daily tasks such as database backups or ftp transmissions is a great way to keep down costs. Why pay for a product such as NetApp's Snap Manager for SAP when at first glance all it does is put the database in hot backup mode and then leverage SAP tools such as brbackup to execute the backup? The true "techie" baulks at paying for "fancy push buttons" when a good old shell script can accomplish the same thing. As a technology manager however you need to consider what the true costs and risks of custom scripts in your daily technology operations actually are. I make the argument here that the fewer custom scripts you have in your environment the better off you are.


Let me be clear on what I mean here by "custom script". I am referring to either UNIX shell scripts or Windows VBScript and PowerShell scripts. Let me also be clear on what I mean by "daily operations". Here I am referring to repetitive tasks that happen everyday in your environment such as database backups and file transfers. I am not referring to one time administrative bulk operations such as Active Directory maintenance for example.


Custom scripting introduces risk by building dependencies on the knowledge of the individual who creates the script.

We all know that we should have solid backups for individuals on our technology teams. In large organizations with hundreds of technology workers it is common to be two or three deep on every position. That is not the world most of us live in however. In the typical midsize organization with a 20 something head count in IT there is generally one or two "super stars" that have the technical horse power to automate daily operations with custom scripts. The more you allow these custom scripts to permeate your daily operations the more risk you bare should one of your super stars leave. Off the shelf products for daily operations counteract that risk in two ways. First, they ensure that through the use of best practice configurations and maintenance contracts that you have an 800 number you can call and expect support. With a large vendor’s support organization behind you, you should be able to sleep easier at night. Second, through the use of GUI interfaces and the publication of best practice documentation, you make it more likely that more of your technical staff, not just your superstars, will have a solid understanding of how systems are backed up, files are transferred etc.. The key concept here is transparency. It should be clear to everyone how things get done on a daily basis.


Custom scripting makes auditability of daily operations much more difficult.

Many technology managers today are feeling the pains of compliance with such rigorous audit and security standards such as SOX and PCI. Rarely will custom scripts be able to provide the robust set of operational reporting necessary for regulatory compliance. Auditors will also have certain packages that they are familiar with. Auditors will have specific things they are looking for relative to the most popular security and backup software vendors. Presenting auditors with a plethora of custom scripting and reporting that doesn’t "fit" their model will likely not bode well. I once had a technology manager tell me that auditors are some of the most unimaginative people he had ever meet. There is some real truth in that sentiment.


Custom scripts are not as scalable as off the shelf applications.

Even if you have a stable group of IT superstars, after a while custom scripts begin to get out of hand. After a certain amount of enterprise growth, it becomes difficult to manage the interconnected web that custom scripts can weave. Custom scripts may also not be capable of handling the sheer volume enterprise growth may bring to your organization. So, while custom scripts may seem cheaper in the short-term, their long term scalability should be called into question.

In summary, while true blood techies often espouse the benefits of custom scripts in daily operations, as a technology manager you should be aware of their true impact on your enterprise. Keep in mind the risks and scalability issues you may encounter by leveraging custom scripting versus standard products. Be aware that the true "fully loaded cost" of custom scripts may be higher than what you will pay for standard packaged software.

Asking “Should” A System Be Virtualized Is Not The Same As Asking "Can" It Be Virtualized

Like most IT managers, I recently had a virtualization assessment performed in my organizations Data Center environment. It was the garden variety assessment with consultants coming in and installing capacity planning software from VMware. We gathered statistics for several weeks and then formulated a list of virtualization candidates. Servers with average processing and memory loads within certain limits where classified as virtualization candidates and placed on the schedule to be brought into the ESX environment. There is nothing wrong with this exercise and it is absolutely necessary. It is however just the first step in identifying your virtualization candidates.

A recent IT manager panel discussion I attended on “Cloud Computing” made me realize how one dimensional the typical virtualization assessment is. One major topic of debate was security in the “cloud”. Who has access to the data, where is the data? These types of questions become paramount when dealing with regulatory issues such as PCI compliance. One IT manager at the panel shared an experience where auditors denied PCI compliance simply because their environment was virtualized. Other managers shared experiences where corporate politics and enterprise architecture standards prohibited systems from being virtualized. All this made me realize that to truly gauge a system as a virtualization candidate, a multidimensional criteria needs to be developed. Simply asking “can” a system be virtualized is not enough.

So, after your consultants show you the presentation with their capacity planner results your job is just beginning. You need to take each of your virtualization candidates and understand which business processes are enabled or impacted by that system. Understand both the regulatory, political and architectural implications of virtualizing that particular machine. Make sure you do a holistic virtualization assessment before you start cashing the checks you think you will get from your virtualization savings.