I was recently discussing EMA’s basic architecture for cloud computing. Essentially, this chart from a recent presentation, given to a workload automation audience, is starting to form the basis for a maturity model for cloud computing:
Cloud Building Blocks
In very simplified form – and heavily out of context – it shows how Infrastructure Automation, Virtualization/Virtual Systems Management, and IT Service Automation form the underpinnings for Cloud Computing, with security and compliance as ever-necessary guardians across all disciplines.
Now, this slide is specific to cloud computing, so I do not claim it to cover all IT or automation requirements. Moreover, it is intended more as architectural maturity model, describing how a lower level of automation must for the basis for, and subsequently extend to, a higher level of IT abstraction.
However, I was challenged by a client to explain why some advanced automation technologies – like IT Process Automation, or Workload Automation – were not in the ‘IT Service Automation’ category, or even in a high-level “Business Automation” category of their own.
Even given the specific limitations, audience, and missing context of this chart (and the broader discussion), I think that is a valid point, and worth addressing more publicly.
Firstly, on the location of IT Process Automation (ITPA, aka ‘run book automation’), I see this technology as predominantly managing machine-to-machine process automation, i.e. connecting individual tasks on separate systems or software engines, integrating and orchestrating these tasks, in order to automate complex IT processes.  By contrast, I see business or service processes as predominantly human-to-human or human-to-machine. This is why I put ITPA into infrastructure automation, not service automation.
Nevertheless, I do think it is reasonable in some circumstances to locate ITPA as both Infrastructure Automation and Service Automation – at least in more mature or emerging use cases. Certainly EMA is starting to see ITPA as a key enabler of business service automation, deeply connected to service automation capabilities like Service Desk and Service Catalog, rather than just for automating (for example) infrastructure activities like provisioning, change, security administration, or data integration. Arguably this is even a new category of its own (Business Service Automation? IT Service Automation?); arguably it fits into existing categories (Business Process Management?).
In any case, I do see a clear distinction between the low-level use cases illustrated in this chart, and more high-level use cases that are not clearly shown.
Perhaps Workload Automation crosses both areas too, but I would say considerably less so. Indeed, I am not at all convinced that workload automation – which by EMA’s definition differs specifically from job scheduling/batch processing by virtue of being cross-platform, event-driven, reactive & predictive, application-aware, and business-driven – is primarily a top-level business service function. Like ITPA, it does participate partially in higher-level Service Automation; however, I believe it is a technology that is primarily used by business service systems, and only secondarily a technology that uses other technologies. So I do believe it is still most appropriate to categorize Workload Automation – even more evolutionary varieties of Workload Automation – as Infrastructure Automation, not Service Automation.
In any case, the structure of my diagram does not preclude certain evolutionary technologies existing at multiple layers.
However, I do not think this chart in particular needs a 4th layer to represent Business Automation. Of course, my label of IT Service Automation may be overly simplified (or even plain wrong); maybe it should instead be called Business Service Automation, for example. It certainly aims to incorporate many of the attributes my client thought should be in a separate layer, around enabling and reacting to requirements that have real and clearly visible business impact. However, I specifically wanted to avoid the implication that the building blocks for cloud computing, from an IT perspective, required deep application integration (i.e. beyond batch or IT processing) in business-facing areas like ERP, BI, Data Warehouse, etc. I see these as desirable outcomes, rather than necessary foundations, for cloud computing.
Still, I certainly do agree there is an ‘other’ that is missing in this chart (well, several ‘others’ actually, but one in particular) – the business function that exists primarily outside of IT. It is certainly not clear in this slide, but it is without doubt fundamental to the intelligent automation of IT, that business needs must underpin cloud computing. Any IT department (whether using on-premise cloud or off-premise cloud, or even running a ‘traditional’ data center) that just automates IT with no regard for true business drivers and outcomes, should re-examine what they are doing, and why. While I leave the business inputs and outputs as assumed requirements in my chart, any IT organization that does not fully incorporate business drivers and outcomes into their processes – or worse, ignores them completely – is doing itself, and its business owners, a severe disservice.
Andi.
![vmworld2011[1]](http://pleasediscuss.com/andimann/wp-content/uploads/2011/06/vmworld20111-150x43.png)
Andi,
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
Thanks Charles, glad you found my blog (Google alerts?). I appreciate the comment. Interesting thought about ‘legacy lock’ in particular. Inertia is enough to stop any innovation in its tracks for sure.
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.
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!