When I was a graduate student in the history of science, one of my favorite books was about the development and deployment of numerically controlled (NC) machine tools. What stands out in memory after all these years is that NC machine tools did not develop "naturally" -- they were not brought to market by companies as a result of organic development in the space. Instead, their development was a hothouse flower, birthed and nurtured by the military, and with one driving goal: deskilling advanced tool and dye machining.

NC tools were competing with a very efficient form of record-playback (RP) machining. RP tools recorded the motions of a master machinist as he created a new object, then played those motions back to copy the parts. RP tools were for many many years faster and cheaper at producing the parts needed because they made the best possible use of the creative strengths of skilled people and the untiring and perfectly accurate efforts of automated tools. However, because RP kept humans in the loop, RP technology was rejected as still leaving the military at the mercy of labor: the object was not the best possible machining, it was automation and control.

Variations on this scenario are a constant in the history of technology, of course: the substitution of machine labor for skilled human labor is at least as old as the printing press. However, it is rarer for the substitution to make processes more expensive and less efficient, as was the case in the NC vs RP battle.

Within IT, we tend to be big fans of automating what can be automated -- admin scripts replacing manual repetition, for example. Automation is what makes it possible to operate 24x7, to have 5 9s of uptime, without breaking the bank on staffing. It is important, though, to keep the limits of automation in mind. Like NC machine tools, automation is limited to what you can tell it in advance how to do, and learning how to tell it to do even something simple can be anything but simple. Trying to force IT into using automated means for particular tasks before there has been enough time for them to evolve fully is like trying to force industries to use NC tools before they were more efficient than RP. Most automation aimed at security and information discovery is not yet ready to be turned loose without skilled minds to guide it, and because it is designed to accomplish specific tasks, it is limited in what those skilled staff can do with it.

For tasks that can be automated, the RP approach can offer a model for a more effective first-iteration automation by relying on humans to explore new territory and discover new possibilities, relationships, and threats, while offering support for automating the repetition of any of those explorations or actions. IT can work best if the tools not only support that automation but support the process of discovery and relationship-mapping -- by providing not just for record and playback (scripting and canned searches, for example) but also an ever more powerful and flexible set of master's tools aimed at discovering the relationships and patterns in the rapidly and unpredictably evolving IT context.