How do you define IT process automation?

Recently, EMA has been seeing several new products described as “IT process automation” solutions. These products cover quite a broad territory with both small and large vendors claiming that their offerings fit into this category. The questions for us are how do these all fit together, how would you define ITPA, and how would you see your organization making use of such tools.

First, we should attempt to qualify some broad boundaries so that we don’t try to include everything but the kitchen sink. (Actually some products do resemble the kitchen sink, but that’s another story.) The idea of an IT process specifically excludes business processes. Business Process Automation (BPA) will eventually link up with ITPA and then we can all turn the lights out and go home, but for now let’s keep things separate.

An IT process is a set of tasks that an IT manager or operations staff member would take to deal with some situation or operational requirement. Note that this should be a set of tasks – one simple automated action does not qualify as a process. Some examples might include the preparation and execution of backup procedures, change management including audit capabilities, or establishing new user resources.

There needs to be some way to visualize and draw processes, or to include process diagrams from external sources such as Microsoft Visio or a store such as a configuration management database (CMDB) or other metadata repository. Another interesting question is what tools do you use to draw your organization’s processes? Or do you have your processes mapped out at all?

And, finally, it must automate those processes. To my mind, this goes beyond sending e-mail notifications or alerts, or collecting SNMP data. Let me give a couple of examples.

Some of the ITPA products are connected with a CMDB – one of the hottest emerging markets. These products periodically or continuously run a scan of the IT infrastructure, run a difference check against the devices and configurations recorded as current in the CMDB, and can take rule-based actions as far as alerting, changing configurations, or disconnecting devices. One example of this type of product is IBM’s Change and Configuration Management Database (CCMDB) and its associated Process Managers.

A much simpler example would include job scheduling and other operational actions. This is an example of a new acronym giving pep to an older market. After all, more often than not, new markets reassemble a mix of new and more established technologies within a more compelling context.

“Runbook automation” is a category of products that seems to be emerging and perhaps driving the market for ITPA. Products in this group provide the connective tissue between lower-level management applications for networks, systems, applications, etc., and higher-level tools such as a service desk. CA has an offering like this, as do RealOps and Opalis.

Should all these examples really be included in the same category and should it be called ITPA, or are they really separate areas that have separate identities? (More acronyms – we need more acronyms!) At one point, we were calling such things “policy-based” solutions, but the immaturity of the products five years ago gave that term a bad connotation. This is really a development of that concept into a whole paradigm rather than isolated actions.

Finally, where do you as an IT manager see this all going in the future? We are moving toward one vast, automated infrastructure – autonomic, self-healing, policy-based, and similar visions. We could imagine it all being ultimately included in IT governance, which currently starts at a higher level with portfolio and project management, but which could eventually include the “hardening” and connection of business processes and IT processes to assure compliance, security, IT-business alignment, optimized resource use, predictive notification of capacity needs, and all things bright and beautiful. Or perhaps you see this as the ultimate bad idea. But at any rate, that’s probably at least a decade out, maybe even 20 years, so our jobs are all safe for now!

Let us know what you use and what you think. We’ll report on your suggestions, views, tools, processes, and nay-sayings in a later column.