3 IT Process Automation Innovations for SMB

Henry Ford

Henry Ford did not invent the automobile. He figured out how to mass produce them by adapting the assembly line, which was actually invented by Eli Whitney to manufacture muskets. Prior to Whitney, muskets were made one at a time by a craftsman’s hand. Whitney invented the assembly line and built muskets with standardized and interchangeable parts. His muskets were produced faster, by less skilled labor, were less expensive, more reliable and easier to repair.

Fast forward almost a 100 years and organizations find themselves faced with a similar set of challenges. IT process has become complex, arduous, time consuming and error prone. But “What if?”, like Whitney and like Ford, new techniques can be applied to simplify IT process, make it more efficient and do it for less money.

1. Use Workflows - Avoid Jobs

In traditional batch lingo, a "job" is a unit of work that is triggered to run at some time or by some event. Then, dependencies need to be created between jobs to form streams-- allowing the success or failure of one or more jobs to start the next job in the chain.

Simple Yet Flexible

A workflow functions at a higher abstraction level than a job. Instead of building many jobs and loosely stringing them together, one creates a workflow that consists of one or more specific atomic tasks wired together with intelligent edges. This greatly simplifies engineering an organizations automated support and business processes. And overtime as the organizations processes change the workflow can change with it. A task is analogous to a batch job, but unlike a batch job, no task ever stands alone. It is always part of a workflow and it is the workflow that is "scheduled" or triggered by any number of different events or another workflow that provides a flexible automation solution that is simple to manage.

Self-documenting Process

Rather than decomposing "what you're trying to do" (your process) down into a set of jobs, Workflows lets you model your entire process in whole, visually and in a very self-documenting way.

2. Replace Scripts

Batch tools typically run scripts or batch files that do all the real work. A workflow allows you to break scripts or batch files down into smaller units that perform much more specific, atomic functions. These scripts become tasks within a workflow.
This does three things.

1. It makes what scripts you do have to write small, simple and very straightforward.
2. Next, it makes the scripts reusable. Because they only perform one specific operation, they can be used in other workflows that require that operation.
3. Finally, it lets the control flow (when and how the script is called) be managed by the workflow where there is less complexity. This is important, and here is why...

5-10 lines
(<1 hour)

150 lines
(+2 hours)

250 lines
(+3 hours)

350 lines
(+4 hours)

More lines
(+more hours)

More lines
(+more hours)

Let us assume for a moment that you need a very simple script to move a file to a particular computer and then run a command to load that file into a database. It's a trivial script -- maybe 5 or 10 lines of code.

Now, you want to run the script on 20 machines and you need e-mail about each failure (150 lines of code).

Then it needs to fetch the list of machines from a database (250 lines).

Now you have 50 machines and it's going too slowly. You need it to act on each computer 10 at a time in parallel and still get the failure e-mail (350 lines).

Now because of some new regulation, the file transfer to some of the computers has to use a different username.

Then, one of the core routers went down in the middle of the copy and the script hung for an hour causing all kinds of problems. Because the script hung, no e-mail was sent.

Things often start simple and end up being overly complex. Consider the number of developer hours accumulated in just this one simple example. Incorporate a workflow tools and rid yourself of scripts.

3. Separate Behavior from Configuration

Behavior -- the steps taken to perform an action. Things like environments, (Dev, prod, Q/A, UAT, DR) are configuration -- what to act on.

Use toolsets that provide the ability to build support process behaviors and then inject your configuration, be it simple variables, a complex configuration object or a database. 

The ability to easily integrate sophisticated data models and make those data models available to automated support process is key. Very often companies already have a CMDB that holds configuration data about their environment. How much easier would it be to setup automated support processes that can truly say things like “... on the production web servers” in your jobs?

True Separation

True separation of configuration from behavior in your automated processes means the same workflow that starts your system in your development environment is the same as the one that starts it in Q/A, Chicago, London and Sydney, etc.

Because of this separation, fewer workflows need to be created and maintained and testing them in dev first is promoted. Without it, as with other solutions, changing one thing can lead to changes in dozens of places leading to "cut and paste" errors or just outright omissions and ultimately process failure.