Fully Automated: Optimized for a Single Work Vector

Nov 26, 2011   //   by Daniel Kranowski   //   Business  //  No comments yet, your thoughts are welcome

In the best of worlds, software automation is pushbutton. Just press a button in a UI, or type a single command-line at a terminal, or let a single scheduled task run, then the invoked script or procedure should take care of running a sequence of actions involving one or more systems. While it’s running you can do other things and stay productive. Processes that get automated are the repetitive ones you do a lot, like business activities, running test suites, or setting up systems and environments. Manual processes require lots of intervention and babysitting: start a script, wait 15 minutes, if it passed start another script, wait some more, copy the result file to another system, ad nauseam; such manual processes are a drain on worker productivity and prone to errors. A fully automated process is a smooth unbroken action – one work vector. A manual process is a broken-up, roundabout path with lots of procedural interruptions – multiple work vectors, which can only be processed serially. Each procedural interruption is a discontinuity that creates another work vector.

In the above visualization, an automated process can do the job in 100 minutes. A person clicking, waiting, and clicking some more takes longer: 125 minutes, because of delays moving from one step to the next. But the time lost is greater than just the extra 25 minutes, because a single unified script can run in the background while you get another 100 minutes of independent work done in parallel. When it’s a manual effort, the work stays in the foreground and you can’t reasonably get anything else done at the same time, due to the repeated need to monitor it and be ready to go to the next step. The optimized worker gets two jobs done in 100 minutes, which is 2.5x more efficient than the manual worker who gets one job done in 125 minutes. The most efficient organizations are those which have optimized their processes to get the most work done with the least effort, and rational automation is a huge part of that optimization.

What causes discontinuities in automation

Discontinuities in automation arise for many reasons. One reason is design-related: perhaps there was a concerted effort to automate that fell short due to incomplete understanding of the process. Say a developer writes an awesome script to automate parts A, B, and C of the process but wasn’t thinking about parts D and E – it helps, but you still end up with separate work vectors. Large enterprise systems grow organically over time, as well, so an automation that worked last year may not solve the problem anymore today. Innocent mistakes also include the simple lack of proficiency in existing automation mechanisms.

Not-so-innocent work vectors arise due to the organizational hierarchy of the enterprise: multiple departments or entities with overlapping IT responsibilities, building walls against each other. The larger a company gets, the more likely its IT infrastructure has been been split across budget domains: system of record here, business features there, operations somewhere else. Once a piece of IT moves into its own budget home, it gets a lot harder to make decisions involving that piece unless you happen to be the director of that group. Automation runs into big discontinuities at the budgetary boundary. If you’re lucky, there’s a strong API at the boundary and your developer can write a program that invokes functionality in the blackbox of the other budgetary domain, allowing for smooth automation. With a weak API, the program can invoke remote functionality but won’t have access to the other department’s data resources and protocol definitions that would help handle special cases and error conditions. And the most common case, which is no API at all, means you need to make phone calls and have person to person meetings each time data crosses the boundary.

SaaS (Software as a Service) and managed services are increasingly the guilty parties as IT organizations seek to offload functional requirements to external specialists. Outsourced providers are just as much of a blackbox as any other IT department with their own budgetary domain. Some SaaS vendors or managed service providers have advanced to the point where they offer an API to let customers automate their use of the outsourced functionality, but this is not the norm. Usually when you buy a subscription to some SaaS product, the usage model is that you login with a web browser and do a whole bunch of clicking. Or with managed services, you turn over the keys to have the vendor perform work specified by contract, and if you need some service you call their tech support or file a service ticket. Although you’re definitely getting something for your money here, it is incompatible with automation.

Solutions for smooth automation

Enterprise automation involves the coordination of multiple parties and systems, which is why the chief prerequisite of smooth, unified automation is management’s commitment and belief in its importance. The next requirement is a full understanding of the technical and business aspects of the process itself. Your technical goal is to achieve strong, scriptable APIs and deep understanding across domains. SOA (Service Oriented Architecture) is an increasingly popular way to present programmable interfaces between departments in a large company, but there are many other options, including client/server architecture, asynchronous messaging, FTP, email triggers, publish/subscribe and producer/consumer patterns.

Getting scriptable APIs means partnered development. In the case of SaaS and managed services, you have the option to shop around and choose different vendors. Let vendors know that you are interested in an API to their product to make it easier for you to gain the benefit of their services. If they don’t offer a sufficient API already, perhaps they will partner with you to develop it. In the case where your work process depends on other departments inside your organization, you can’t exactly shop around, and the political challenge of convincing departmental neighbors to work better together may dwarf the technical effort of actually developing the automation infrastructure. Successful inter-departmental collaboration can blossom from many seeds, such as persuasion, compromise, trades and barter, appeal to outside authority, or escalation to higher management. Ultimately the divisions of a well-functioning company should view one another as partners in a common enterprise.

When partnership is underway, the automation designers can get to the activities of requirements gathering and interface definitions. The goal is to simplify work vectors and make business more efficient, which means anticipating the procedural interruptions that typically occur in the non-automated environment, and designing algorithms which take them into account. At this point, the principles of good software development and agile methodology apply. Better software development practices will lead to a superior end product, simplified work vectors, and a better return on investment.

Please share your thoughts