Because I work for a technology company, I frequently get asked to present on "the future of the data center". I think the expectation would that I show up and start talking about shiny new technologies.
While I can certainly do that, I often decide instead to hold up a large mirror to the audience, and instead present on how the nature of enterprise IT is fundamentally changing: new mission, new measurements, new roles and new models.
Collectively dubbed ITaaS (IT as a service), the idea is for IT to deliver IT services that business people prefer to consume vs. acting as a traditional silo'd technology shop.
From my perspective, the technology is moving very quickly indeed: far faster than the ability of most IT organizations to effectively consume it, providing yet another motivation for model change.
I get to see it both ways. On one side, I'm reasonably immersed in various technologies these days. On the other side, I can point to literally hundreds of customer and partner interactions over the last year or so.
And, for some, the gap is getting wider.
It's now gotten to the point where I have three distinct flavors of various talk tracks, depending where I think a customer might be: pre-transformational, transforming, or post-transformational. Why? EMC, as an IT vendor, has clearly started to put more investment into the needs of the post-transformational crowd, causing a certain cognitive dissonance with pre-transformational IT audiences, e.g. why the heck would you guys build something like that?
The more you work with a topic like ITaaS, the better you get at simplifying the core ideas down to their essences. I and EMC have been discussing IT transformation now for several years, and -- predictably -- we keep getting better and better at getting to the core essence.
Today's example of extreme simplification comes from EMC's Global Services organization. They've come up with three powerful graphics that boil a very complex topic down into into three largely sequential initiatives. They're so useful, they're now part of my standard deck I use on the topic.
See if you agree ...
The Big Ideas
The underlying motivations for an IT transformation are simple at multiple levels. At a macro level, business have to learn to thrive in a digital world, and have started to create digital business models. At an IT level, many IT organizations are realizing they need to learn to compete for internal business initiatives, and they're not exactly organized for success.
Or perhaps the motivation is more pragmatic: a need to dramatically lower costs and create new value for the business.
It's not really an IT transformation until that moment when the leadership team realizes that they're not organized for success going forward.
We're not talking about a simple rearranging of deck chairs; or a light coat of paint over an old house -- it's creating a nascent new model for IT, letting it grow and mature, and discouraging traditional approaches as confidence is gained in the new way of doing things.
So, at a high level -- what's involved?
#1 -- The Infrastructure Transformation
By now, most IT professionals are familiar with the new, emergent patterns: aggressive standardization using a handful of core technologies, pervasive use of virtualization, a preference for converged approaches, widespread pooling of resources, and so on.
The number of IT traditionalists arguing for a more bespoke, every-application-requires-its-own-dedicated-stuff seems to be dwindling rapidly. It’s clearly a losing battle: their historical approach costs more (capex and opex) but -- more importantly -- doesn't deliver the agility that the business craves.
It's easy to see why: in this model, IT essentially plays the role of an infrastructure system integrator: select the components, assemble them, test them, validate that they work as advertised, make sure they operationally integrate with all the other puddles of bespoke IT that are already there, and -- of course -- support the bespoke stack in perpetuity, including any new requirements that might come along -- like growth or new functionality.
I believe that most people have realized that this per-project system integration approach is both unnecessarily slow and unnecessarily expensive.
The primary technology that kicked this discussion into high gear was our familiar friend, server virtualization -- mostly in the form of VMware.
Widespread use of virtualization led to the demand for converged infrastructure. And widespread demand for both is the driving motivation behind the newer discussions around SDDC -- software-defined data centers.
What's holding back this transformation? It isn't the technology per se: everything involved is not only mature and fit-for-purpose, and there's a virtual parade of IT shops who've made the switch and are moving fast in the new direction.
No, what makes this particular hard is the amazing weight of the legacy processes around the infrastructure (procurement, operations, governance, etc.) which have to change for this model to be effective, which brings us to our next topic.
#2 -- The Operations Transformation
There are actually *two* transformations involved here: what the business sees, and how IT runs its own operations. Both need to change in the new model.
The way I describe the traditional business-IT interface is "everything is a project".
Sponsors need to be identified, proposal need to be made, justifications created, alternatives researched, funding acquired, organizational politics sorted out, etc. -- and that's before any useful work gets done!
Not that there won't be a few larger-than-normal requirements that can benefit from this more structured approach, but to force it on each and every non-trivial IT request?
No wonder that the IT service provider market is booming: business users now can get what they need without a lot of red tape. Sorry, IT guys, you're just too slow.
In any ITaaS model, the majority of IT is consumed as a variable service (hence the name) -- a constantly-updated set of high-level IT services that are easy to consume, showback or chargeback to help rationalize IT consumption choices, strong incentives for IT deliver services that the business wants along with strong incentives as well as strong incentives to the business community to consume what's already available.
It's basically the same model any competitive IT service provider would use run their business.
Behind the scenes, IT transforms to look more like a factory, and less like a group of artisans in their respective guilds.
As a result, just about every IT process that matters is re-defined and re-implemented around the new model. Job descriptions change, as do measurements. Familiar IT organizational structures disappear, and are replaced by new ones. Non-technical disciplines like marketing, finance and HR become far more important than before -- just like any other "business".
But make no mistake, your goal is to engineer people out of the legacy process – just like any other business person would want. But there's a bright side: almost all the IT organizations I've worked with have decided to take that new surplus, and re-invest in higher-value IT roles that deliver more to the business.
Very rarely does any IT transformation of this nature result in a long-term decline in IT headcount; the opposite seems to be true due to a virtuous cycle.
The business finds that IT is easier to consume -- and delivers more value than before, so -- naturally -- they inevitably want to consume more.
That increased demand by the business often leads to a secular shift in the enterprise's view of IT: it's now a value generator vs. a cost level.
The business starts to invest more in IT, and in IT people than before. I've now seen this dozens and dozens of times in my own little world – with very few exceptions.
But, stepping back, the role of all this IT stuff really boils down to creating value through applications, which brings us to our next transformation.
#3 -- The Application Transformation
If one can make an argument that we've been thinking about infrastructure the wrong way up to now, we can make a similar argument that we've been thinking about applications the wrong way as well. While there is certainly a case that can be made for "rationalizing the application portfolio", there's more going on here than just pruning the current application inventory, or consolidating functions.
A good starting point might be a strong argument for pervasively using a SaaS delivery model everywhere: not only for external applications, but internal ones as well.
The SaaS model is all about ease-of-consumption: applications are easy to find (usually via an app store), communities are created around people doing similar things across the organization (lower support costs and increased proficiency), and -- of course -- people pay for what they use, nothing more.
Whether a particular chunk of application logic resides inside or outside the firewall is completely transparent to the people using the service: IT is brokering the relationships for both, depending on the specific requirements.
But there's another important side of this -- the shifting views around internally developed applications.
The business appetite has clearly shifted to "app factories" just-in-time app creation, using agile methodologies. Once you get beyond the usual productivity and SaaS offerings, home-grown applications are really unique business know-how; codified and put into practice as quickly as possible -- it's the new corporate intellectual property in some sense.
Now, let's say you're a business person with an idea you'd like to put into practice. The norm might be six months of requirements planning, followed by six months of implementation, and concluded with six months of finger-pointing.
And executives wonder why the organization isn't moving faster?
That classical approach can't compete with a business user being able to see a mock-up of their idea in action in, say a week or two, providing some feedback, and turning the crank again. Most applications ideally are in a constant state of evolution: new enhancements are pushed every few weeks or months vs. every three-to-five years.
We've all grown accustomed to this in the consumer world; the same thing has started in the corporate domain.
The newer applications tend to use multiple data sources, presented in an easy-to-consume form factor, e.g. mobile. The cooler ones have a notable analytical component that helps better decision making by the people who consume them. And, of course, this is all best done on the newer frameworks using the newer methodologies.
Once again, we're really doing is re-engineering people and process -- the technology is already there.
Assembling The Pieces
Given this three-part discussion, it's pretty easy to see the logic behind the desired sequencing. Trying to create advanced operations over legacy infrastructure silos will be an exercise in frustration. And trying to build a SaaS consumption model or a next-gen app factory without the prerequisite operational model will be equally frustrating, but in different ways :)
But massive change can't happen all at once, can it? The crushing legacy -- investment, processes, perspectives, etc. -- has had a very long time to grow, institutionalize and very often has erected substantial barriers to change.
The most successful pattern I've seen is that IT leadership picks a place to start, and creates a new team that has the freedom to try things new ways: prove that the model works, make a few mistakes, and gain maturity.
And it should be no surprise that the new team needs a decent "air gap" from the massive legacy that surrounds them.
That's the role of IT leadership: recognize that a change needs to be made, and to create an organizational construct that enables progress to be made: slow at first, more rapid later, and eventually becoming just the accepted way of doing things across the organization.
As I've mentioned before, this is not theory. I've seen this movie now play out literally hundreds of times within IT organizations large and small, across different industries and geographies.
It's the new way of doing things. It appears inevitable.
If you haven't gotten busy on IT transformation, now might be a good time :)