I had an interesting discussion last night on Twitter with Tajeshwar Singh (@tsingh4IT), a thoughtful and experienced IT pro working with a leading IT outsourcing provider,  about the differences and overlaps between strategic and tactical CIO planning. It was triggered by the disdain I have for a new “Top Technologies for 2010” prediction I saw, which included the caveat that these technologies will have a “significant impact in the next 3 years”.

I tweeted that I think such predictions are useless when most CIOs must prove return on investment (ROI) for major IT projects in less than 6 months. Tajeshwar got me thinking more deeply about this idea with his reply:

“cio demanding roi<6 mnths r taking tactical view;3 year tech horizon must for taking strategic view & decisions”

Indeed, this is emblematic of a really interesting challenge for CIOs.

The demand for a rapid ROI, typically less than 6 months, and in some cases shorter, is a fact for today’s CIO – even more so today than before the global economic downturn. I firmly believe that CIOs demanding ROI in less than 6 months are simply realizing and reacting to the modern reality that IT can no longer be a pure cost center. Ask almost any CIO, and you will know that the ‘blue sky’ IT projects that delivered results in 2-3 year timeframes are a thing of the past.

However, as Tajeshwar implied, this demand works directly counter to the mandate for great CIOs to think and act strategically, executing on a long-term corporate vision. The same CIOs that are trying to contain or reduce costs – essentially a ‘cost center’ approach – must also be acting to make IT a strategic asset.

This does not mean that strategic CIOs are dead, or even a dying breed. On the contrary, the ability to accurately envision future trends and get a head start on competitors is perhaps more important than ever, because the rate of change in IT is so much faster, and the barriers to entry for new technology innovations seem to be always decreasing.

So to be a great CIO you need to act tactically, with projects that contain costs and deliver ROI in less than 6 months; yet also provide the business with a strategic launchpad for innovation, competitive advantage, and shareholder value.

What sort of projects can do this?

How about:

Virtualization

This is perhaps low-hanging fruit. My research for EMA clearly shows the key outcomes of virtualization are well divided between short-term ROI and long-term strategic benefits.

For example, in the short-term, virtualization reduces hardware, power, cooling, administration, rent and even software costs. Around 90% of enterprises report that it delivers real, measurable cost savings. Loading up 15 VMs or more on each physical server, allowing admins to manage on average a 10% greater workload, saving an average of $200 per system on administration costs, adding as little as $37 for each new VM in administrator staff costs (up to 28 times less than a physical system), and reducing power costs by an average of 17% are rapid and significant ROI values.

In the long-term, faster system provisioning helps bring products and services to market faster, better DR capabilities provide a strategic defense against disasters and epidemics, and better workload and resource balancing provides faster response times and better customer service – a range of strong strategic opportunities.

IT Process Automation (ITPA)

In the short-term, EMA research has shown that sites with ITPA improve their MTTR, provide almost 65 hours extra availability per year for 24×7 operations, and sites with ITPA (typically larger data centers) save on average around $500,000 more per year on staff costs alone than sites without it (easily offsetting marginally higher staff salaries). These outcomes all provide substantial short-term ROI.

Meanwhile, 95% of enterprises report that ITPA achieves one or more strategic goals, such as improving the ability to adapt to rapid change (like rapidly integrating M&A), freeing up high-level staff, providing better security and compliance, reducing business and IT complexity, reducing human errors, and integrating with best practices. Moreover, 76% report that ITPA helps achieve 2 or more of these goals, and 55% report it helps achieve 3 or more. ITPA also correlates with an overall increase in IT maturity.

Lifecycle Management

In published EMA case studies, automated lifecycle management reduced regular maintenance windows for 50 systems from 2-3 days to just 10 minutes each, and cut the cost of  distribution of a new version of Microsoft Office from $90,000 to just $30,000. It also can help to reduce overall software license costs, allocate and reuse hardware more effectively, improve end user uptime, and reduce or eliminate the (often substantial) travel, staff, and downtime costs of desk-side visits to install new software or fix problems.

EMA research also shows that automated lifecycle management helps to achieve strategic objectives. It provides faster and better service to end users (and ultimately therefore to customers), enables IT and business staff to be more productive, lets business users take advantage of new software and systems much faster, provides essential compliance reporting, and maintains strategic security values.

Part of the reason that these technologies are both tactical and strategic is that they can all be implemented in short, sharp, phases that deliver fast and specific results, while establishing a technology basis that can be leveraged – reused, over and over, in multiple new ways – to deliver strategic benefits with little or no additional cost.

For a great CIO, such technologies are invaluable. They show fast results, justifying budgets and building confidence; yet they deliver technologies they can continue to leverage for better and better strategic outcomes.

All of which meets the needs of today’s CIOs much better than blue-sky, multi-year, technology dreamings.

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.