Cloud Foundry: Design and Architecture
Derek Collison discusses the goals, the design premises and patterns employed in creating the architecture of Cloud Foundry, VMware’s open source PaaS, unveiling internal architectural details.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Can any process be automated?
Posted by Boris Lublinsky on Aug 11, 2010
With the advances of BPM there are more and more processes that companies are trying to automate. A common question asked in these situations is which processes should be automated and which ones should be left the way they are. A new post by Julian Sammy discusses when the processes are beyond the reach of automation. According to Sammy, there are three main categories of processes for which automation is not possible.
Impossible Automation: This category includes processes that can’t be automated. Based on Douglas Hofstadter book "Gödel, Escher, Bach: An Eternal Golden Braid", hero’s assertion is that in a closed system there are two kinds of things:
- Things that can be proven, and
- Things that can not be proven.
Sammy deduces that:
... any computational device - computer, brain, anthill, whatever - can run into problems that it can never solve. It also means that the brain in question will know some facts - things that are true - which it can never, even in theory, prove to be true.
In practical terms, this means that some processes are too complex to be automated. There are too many exceptions in their behavior and the description of all these exceptional situations does not seem to be feasible. It is possible to implement automation for some of the situations, but there will always be situations which require human intervention.
Unaffordable Automation: This category includes processes that technically can be automated, but the benefits of that automation do not justify the investment. As Sammy summarize it:
Sometimes you know how to automate a process, but it just takes too much investment (people, processes and tools) to make the change, or it’s too risky.
Irrational Humans: This category includes processes that technically can be cost effectively automated, but no one is going to approve it due to lack of trust. The examples given by Sammy include such processes as pilotless passenger planes and driverless cars. According to him:
Eliminating pilots and taking your hands off the wheel won’t happen soon, if ever. Humans are awful at taking rational risks, and happily demand a sense of control in preference to actual control (there are many other cognitive errors and deficits that make us human). Any attempt to implement changes that impact these irrational factors, is in for a rude surprise.
In his opinion, one of the fundamental requirements for being a successful EA is the ability to lead without actually owning anything:
If you don't have good leadership skills, the rest of it fundamentally doesn’t matter... If you do not lead and do not take the risk to lead, the transformation won’t occur. One of the barriers for the profession today is that many architects are not prepared to take the risk of leadership.
Although theoretically there is no limit to automation’s capabilities, Sammy’s post emphasizes the necessity to carefully evaluate every business case for automation. As described in Joe McKendrick’s post on automation, this should include the following:
- Justify the project for business purposes.
- Cost-justify the undertaking.
- Build support and get sign-on from affected constituencies.
Automation should be implemented only if the business analysis shows that automation’s benefits outweigh expenses and there is enough support for the undertaking.
- This article is part of a featured topic series on SOA
- See more SOA content at: http://www.infoq.com/soa
- Other recent content items in this topic
LOL
by
ego maniacs
Posted
partial automation
by
Neil Murphy
Posted
Re: partial automation
by
bruce b
Posted
-
Appdevs are hilarious. They think they can and should automate anything and everything.
What about automation for open-source developers? -
I have mange several BPM projects where we partially automate the process. We assumed that someparts were so reliant on human judgement that we automated 80% or mroe of the process, leaving some key decision ponts to be with the handlers. I am thinking specifically of Claims handling, where much of the work relies on watiing for events and doing mundane clerical work. But the claims handlers can be quite skilled peopee, so we assumed that we woudl create a tool to support the handler ratehr thean to replace them.
This allowed us to deliver projects to reasonable time and cost, while delivering substantial (and measurable) benefits.
It came down to applying the 80/20 rule and being clear about what benefits we were aiming to achieve. -
Htere muts be an automtaed rpocess tranpsosing lettres
3 comments
Watch Thread Reply