ITPA/WLA in a Cloud Computing Model – Infastructure or Service Automation?

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 ‘other’ 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.