I like this breakdown and concur that “cloud” is primarily around the codification of processes – both operational and business – as well as the premise that there are steps, building blocks as you call them, to achieving full “automation”. Building an agile infrastructure requires you to be agile in its construction, which was one of the points I was trying to get at in Repetition is the Key to Network Automation Success.

That said, I think “process automation” is too vague a term. I’m not sure if you’re referring to operational processes or business processes. The former belongs higher up, I think, as it requires that all components comprising the process be automated already, and the latter as you point out may belong in a 4th tier, though it would also seem to fit well in the 3rd tier.

It’s definitely an excellent start to building a maturity model.

Lori
@lmacvittie

And I use small text in the comments, so don’t worry about length – especially when it is interesting and useful like that!

Let me know if or when you start Tweeting too. I will look forward to it.

Andi.

I agree with your analysis completely and offer the following observations.

Process automation belongs in the infrastructure automation category when it is being used as it is delivered in the box as a platform for automating infrastructure.
Process automation belongs in the service automation category when a particular solution is built on top of the platform. Specifically by combining a process automation engine that handles the heavy lifting of the computer interaction with an appropriate front end for the task at hand (sometimes a service desk, sometimes a service catalog, sometimes a bespoke interface) you get a very rich and customizable human to computer capability. This is very similiar to the approach of using a process automation engine as the core of a virtual lifecycle management solution. The process automation engine does all the computer interaction of provisioning and decommisioning while a user interface layer is added for self service.
I also agree with your comment regarding workload automation (although many of my former workload automation colleagues may disagree). Whether you are talking about traditional batch processing or modern event driven automation the fact it that the vast majority of uses are for automating the non-transactional elements of application architectures and secondarily for automating simple IT activities (not processes). Seldom does workload automation cross over into the realm of service automation. This is partially due to limitations in the technology (dependency management rather than workflow, lack of appropriate connectors, etc…) and partially due to what I call legacy lock. Job scheduling has been around for well past 20 years. It is mature and established technology and the number one consideration of most users is not how to figure out how to use the technology in new ways but rather that what they’ve built operates reliably like a utility. This actually creates a disincentive for innovation in the user regardless of the technology innovations provided by the vendor.

Enough from me or my comment will be longer than your blog (call it CTO syndrome). Glad to see you in the blogosphere and you may even have convinced me to tweet!