Practitioner’s View: IT Transformation and GreenPages’ Solutions Architect

Last week I had the chance to speak with EMC Velocity Partner GreenPages – specifically with Trevor Williamson, their director of Solutions Architecture. Trevor regularly speaks with CIO’s from Enterprises and SMBs about cloud computing and IT transformation. He has a refreshingly balanced perspective on technology… and on its impact on business. Follows are some paraphrases from our conversation late last week.

Lots of Talk About Cloud But…

Not surprisingly, Trevor noted that 80% of his customers are talking about cloud computing (who isn’t?) but only really 20% are doing something about it. 

Why: He’s noticed lots of reasons – having to do with resistance to change, the demographics of IT leadership, and more.  Trevor’s analogy was to that of an automobile:  Traditional IT looks like a basic car with a basic engine and basic drive train. Yeah, it basically keeps running for ever. But if you wanted to change something, good luck.  There wasn’t much room for upgrading without changing the whole thing.   Next, enter virtualization… akin to a car with Fuel Injection. It’s an upgrade – and the engine will run more efficiently. But in the very grand scheme of things, it’s still a point-solution (although quite valuable). Now finally, enter the concepts of automation and Cloud Computing: where the car’s components become completely different and independent – no piston engine, an electric drive train, etc.  So it’s much easier to upgrade components without needing to alter others.  Simply increasing the battery gives better range. Changing the electric motors gives better performance. Changing the engine might speed battery recharge.  But components now operate more distinctly and can be optimized independently.

On IT Finance, and Why It Might Be the Key to Change

Trevor also had a terribly pragmatic perspective on a simple but ingrained factor holding-back IT’s efficiency.   In the traditional (read: old) IT financial model, the IT Project Number was the key to all implementations.  Any change to a specific system got charged to that number. And the dollar size of that number got watched under a microscope.  However, bounding the infrastructure’s financial model with a single project number reinforced the technological stove-pipe-ness of the assets themselves. The financial model did not allow for any sharing of assets between systems – because each new asset of course had to be assigned to a single project number. So, one result was the wasteful sizing of each silo - and resulting horrific utilization of each silo.  Ergo, Capital inefficiency became a necessary result of a limited financial model.

Enter: Shared infrastructure that can meter incremental IT usage, and cost-accounting that can keep track of (and assign) incremental costs.  With these two tools, IT could now implement a shared (and, needless to say, virtualized) infrastructure. The improvement in utilization, and resulting improvement in capital efficiency, was and is a boon to IT.

So, Who Calls the Play?

When an IT department decides to go down the path of a private cloud, who makes the call?

Well, there are usually two models Trevor and GreenPages frequently see – either top-down (by decree), or organic (bottoms-up). More often-than-not, Trevor believes most initial deployments are bottoms-up. The typically the initial application is internal to IT, such as QA/Dev/Test – also because these use case customer needs are very dynamic and fast-moving.  Giving the engineers a self-service portal and ability to spin-up tons of cookie-cutter environments is a great fit and a great win.  And doing so internal to IT (in contrast to line-of-business apps) minimizes the number of approvers… also speeding along the project.

Most initial bottoms-up automation and cloud initiatives are relatively new implementations, *not* system refreshes – which surprised me. But for good reason: Refreshes usually involve a cross-application and cross-domain initiative. Which means more approvers and multiple teams.

Now, there are times of course when IT leadership “decrees” building a private cloud – and mostly the impetus is either to reduce costs, or to cater to the LoBs who are looking for agility that will result in making more money.  But when these initiatives are by leadership decree, they’re usually bigger (and slower) than their internal organic cousins.  In fact, the top-down initiatives are usually corporate-scale, even to the point where they’re ‘branded’ and ‘marketed’ cross-org.  But reading between the lines, all of the hoopla doesn’t make the top-down initiatives any faster than the internal approach.

Is building an Internal Cloud Bad (for IT Jobs)?

Trevor gets this question a lot. He’s not yet seen an instance where virtualizing and automating infrastructure has meant a reduction in jobs. Instead, he’s found more the case that it’s good for the *existing* jobs.  Building a private cloud helps IT personnel climb out of day-to-day fray, and frees-up their time for more interesting, higher-value work for the company.   We both noted that IT should be focused on extracting value from company data and partnering with the lines-of-business…. Rather than “keeping the lights on” laboring as a monotonous workhorse.

And Finally…. On Keeping IT Competitive

“Why does business go around IT?” I asked. Trevor was pretty firm on this one: Only when IT can get out of its own way and move at “market speed” will internal customers will choose them. He sees lots of use of external services by lines-of-business, and lots of IT organizations racing to keep up with them.

How to achieve market speed? Part of the answer is re-engineering IT as an internal service provider / service broker. IT must think of itself as a service bureau, right down to marketing its services to users in the enterprise. From an infrastructure perspective, IT also has to become more agile. It has to “stop plugging holes with humans” and start by leveraging automation as part of its DNA. Lots of point systems can be automated, e.g. provisioning OS, virtualization platforms, I/O, networking. And only then can Orchestration be layered across those automated systems to attain the speed and agility needed. Take it a step at a time, with the goal being competitive and customer-focused.