This excellent blog post by John Allspaw caught my eye because of its interesting topic – how to divide work between machines and people. John discusses a couple of approaches in determining how to split the work between humans and computers and which types of tasks are more suitable to each of the parties. He ends the post with an intriguing question:can we imagine humans and machines as partners?
This question resonates really well with the current state of affairs in network security automation which is what we specialize in, here at Tufin.
A couple of years ago we established two internal guidelines:
- Automate what can be automated
- Simplify what cannot be automated
This is a simplification of course :), but it’s been useful as a means for focusing our strategy.
For example, when deployed in an enterprise environment, our system can take a network connectivity request, figure out the path, design the needed configuration changes for the relevant firewalls and even implement them.
As expected, the process is still not fully automatic. The limitations are exactly along the lines that John describes – where it is too complex or not occurring frequently enough to justify the cost of automation. Common tasks such as provisioning application connectivity requests onto the firewall security policy can be fully automated but less common tasks such as setting up a VPN tunnel, which is also relatively complex, still require manual work.
John quotes David Woods and Erik Hollnagel as follows: “Full automation should therefore be attempted only when it is possible to anticipate every possible condition and contingency.”
We clearly deviate here. Deliberately.
Had we taken this approach, our product would never be ready to ship. Computer networks today are so diverse that the ability to anticipate every possible condition would have required many years to develop and would probably be obsolete by the time anyone had achieved it (which reminds me of a story about the lack of startups in certain countries but that’s a different story).
Instead, our system takes a partnership approach which attempts to automate network changes but can escalate the request to human being when needed.
This partnership or collaboration is made possible by a simple but important design concept which we chose early on – a change is a process.
Rather than implementing changes in one blow, our system processes network changes as a series of tasks. This approach enables exit points in which the system can escalate a task to human being when needed, either as a pre-configured condition, which was designed as part of the workflow or as a contingency which was determined in “run-time”.
To summarize, I’d like to vote for the partnership approach but also to emphasis the importance of a process oriented approach as an enabler and, BTW, I believe this to be true of any type of collaboration, whether human-machine or interpersonal.
Don't miss out on more Tufin blogs
Subscribe to our weekly blog digest
