Cloud concepts — whether private, public or a hybrid — represent a meaningful change in how IT services are delivered. More and more IT leaders are starting to realize that to make that next leap forward, they’re going have to significantly re-factor and evolve their IT organizations: new skills, new roles, new mandates.
Hi. We’ve invented this new thing called “airplane”. It’s faster, better and cheaper than other forms of travel, especially if you’re going a long distance. It works pretty well. However, we’re going to need some new skills around flying it, maintaining it, etc. It’s not much use by itself.
I was fortunate enough to sit through an all-day executive briefing where this important topic was the only one on the table: how will IT organizations transform themselves going forward?
The example on the table? EMC’s own IT organization.
And, if you care about IT organizational evolution, you should make the time to read this post.
A Different Kind Of Briefing
The vast majority of customer briefings I see are very focused on technology. That’s understandable — EMC is a technology company, and we’ve got a lot of it to talk about :)
This time was different.
We asked the senior functional IT leaders in a large, financial services organization to join us for a full day. We would put up similar leaders from our own IT organization, and talk in-depth about how their function had evolved, and where it was going.
No product pitches. No glossy powerpoint. Just a frank and honest discussion on how we’d done it ourselves, from the very people who had done the bulk of the heavy lifting around organizational change.
We had Dave Martin talk about how his CSO role had evolved. We had Darren Sullivan speak about how the business interface role had radically changed. We had KK speak about the role of the enterprise architect, and how it had become incredibly important. And we had Jon Perice speak about the evolution of his IT infrastructure role.
All the discussions were wonderfully insightful, and I hope to present the essence of all of them here -- eventually,. But I thought I’d start with Jon’s presentation as his infrastructure / desktop services function underpinned just about everything else.
A Bit About EMC
I’ve found you can’t really understand an IT organization unless you understand the organizational context it serves. Rather than bore you with the gory details, here’s what you need to understand about EMC's business to understand our approach to IT:
We’re a big and successful IT technology company, and growing very rapidly. We do business globally these days — not hub-and-spoke, but large-scale business operations around the globe.
A high proportion of our employees are skilled knowledge workers. We integrate tightly with an expanded ecosystem of suppliers, partners and ultimately customers. We continue to acquire companies at a regular pace, and would like to maintain our current track record for successful integrations.
We handle all manner of sensitive information routinely, and have to comply with information management regulations in a wide variety of industries and geographies. We take protecting our information assets very seriously, as you might expect.
Many of our growth initiatives are highly dependent on different forms of IT services. We like cost-effective IT service delivery as much as the next company, but what we really need is speed and agility from our IT team.
Enter IT Infrastructure
Jon’s role — if I understand it all — is rather large and complex. He runs all the data centers, all the infrastructure, all the desktop services, operations, help desk, and more. In the spirit of extra credit, he’s also responsible for IT integration when EMC buys yet another company.
And, like most people at EMC, I think he’s gotten pretty damn good at what he does.
A Useful Analogy
Jon’s original career was in the manufacturing world: building stuff at scale. He put up an interesting slide that detailed the changes he saw in the manufacturing world during his time there, and found powerful parallels in what was going on in the IT service delivery world right now.
The old days of manufacturing were very much like much of how IT is done today. Most of the work was done by specialists or craftspeople. Every operation was largely independent of every other operation — any integration was sort of done after-the-fact rather than designed in from the outset.
Manufacturing in those days was very much like IT is these days: lots of manual intervention when there was a problem somewhere. The efficiency of the processes largely constrained the supply.
And, like many IT organizations today, there was the thought that the people producing the goods and delivering the services were essentially a monopoly — that no other alternatives were available.
Compare that with the new view of IT service delivery. Designed from the ground up to be highly integrated, automated, consistent and with self-correcting processes. SLAs (service level agreements) are used to drive improvements back into the process, borrowing heavily from Six Sigma concepts. There’s clear visibility to true costs and an effort to allocate costs back to the parts of the business that are using the service — if nothing else, but to help people make better business decisions.
And IT competes for its business — just like manufacturing companies have to do today.
Implications On IT Roles
Jon then pulled out one of those great “money slides” that I’m sure we’re going to see much more of in the future.
In the center are three core functions of his operation. And he did a great job highlighting the “before and after” he was taking his organization through.
A good starting point is the design and architecture function.
Traditionally, EMC IT (like so many other IT organizations!) focused their effort on designing and architecting a dizzying array of “solutions”, one for each unique business requirement that came through the door.
This has quickly given way to designing and architecting a single shared service delivery platform (our private cloud).
Build it once, build it right, use it everywhere. Not to throw too many analogies at you, but he compared it to the difference between designing an automobile vs. designing a mass transit system. You do the first very frequently; you do the second infrequently but have to do it very well.
Different skills, different roles, different organizational focus.
The build and operate function goes through similar shifts as well. Most of the resources here have traditionally been tied up in building platforms, provisioning them individually to requestors, continually re-configuring their parameters, and the inevitable break-fix and problem management.
The new team is entirely focused on automation, capacity planning, performance management and IT process re-engineering. It’s a big change.
Perhaps the most important transformation lies in the product and service management area. The existing capabilities — focused mostly around responding to service requests — had to be completely transformed into a customer-facing, market-oriented organization that designs, develops, markets, sells, delivers an supports a catalog of service offerings back to the business.
Just like a real service provider would do :)
Another View Of The End State?
Jon then presented his end-state organizational model as a “stack”, best viewed from bottom to top.
Underpinning the IT infrastructure, you’ll still find the familiar labels of IT technical skills (networks, security, etc.).
But there are significant differences: fewer generalists are needed -- the required skill level is much deeper, and they work together in a very different non-silo model.
Next level up is virtual infrastructure management (or private cloud management, if you prefer). These people are responsible for the day-to-day operations of the infrastructure services. Management is a function of architecture — not only technical architecture, but — more importantly — process architecture.
The virutalized infrastructure is used to deliver distinct categories of foundational services: low-level infrastructure as a service, higher-level platform and enterprise applications as a service, and finally desktop (more properly user experience) as a service.
And the big insight? A new function that’s essentially the same as you’d find at any decent IT service provider: IT service management — defining, marketing and selling these services back to the business.
How Do You Get From Here To There?
If you’re with me so far, now we’re getting to the really good part.
Jon presented a sequence of organizational models that were signposts along the way. I found them extremely illustrative — perhaps you will as well. In particular, note the sequential org model steps that incrementally transitioned away from the legacy, and towards the new model.
EMC IT Infrastructure Organization -- 2008
The starting point would be 2008. At that time, EMC was about 20% virtualized — nothing exceptional in this regard.
Jon describes his org structure — at the time — as a traditional technology-driven “silo-ed” organization.
Systems architecture was in one group, with subgroups around UNIX, Windows and a central authentication group. Storage folks were in a separate group: SAN guys over here, NAS guys over there, and a group to backup and archive the data. The network team had the traditional telecom vs. data division, with responsibility for the NOC.
Finally, there was a distinct group responsible for the physical data center, a standalone security function and a standalone help desk function.
Nothing too remarkable here. Lots of IT organizations probably look something like this today.
EMC IT Infrastructure Organization — 2009
The first major step in the journey started in 2009. By this point we were roughly 50% virtualized.
Yes, I know it looks a lot like the 2008 picture, but with one key difference: note the consolidation of the “global command center and IT service operation” function.
Previously, each silo sort of supported operations for their particular piece. In the new structure, all of this was combined into a single, unified function.
Jon state unequivocally that this turned out to expose an enormous foundational problem.
Previously, there were pockets of operational automation here and there. Every silo sort of had their own way of doing things.
Putting everyone together (and make them all responsible for solving the problem!) and — voila! -- all of the sudden there was a new and massive understanding around just how broken the various operational processes were — when viewed from end to end.
Breaking down these organizational silos cleared the way for end-to-end automation and process engineering. Put differently, there wasn’t going to be a cloud of any sort until there was a foundational organizational basis for tackling the problem.
Jon shared that establishing this new function was not without its challenges. Previously, these resources lived within their legacy stacks. When the announcement was made that a new end-to-end group was going to be formed, the tendency was to perceive the new, strategic function as a less-than desirable career path, with the predictable results.
That issue was discovered and eventually rectified, but it does speak volumes to how IT organizations can think about change :)
The other thing to note — in case you missed it — was the establishment of a “virtual infrastructure” silo, alongside the existing UNIX and Windows team. More on this later ....
EMC IT Infrastructure Organization — 2010
Big changes between 2009 and 2010, but with more to come. By now, we’re 70% virtualized.
The first big change to note was the establishment of a consolidated management and automation team.
This role was pulled out of the individual disciplines. Because the centralized global command center and ops team had been operating for a while, there was a clear “customer” for centralized management and ops team to address.
One thing leads to another ...
The second big change shows up on the far right, in purple. A separate discipline — service management — was established, around the customer-facing, market-driven, compete-for-business principles described earlier. This new function had to be basically built from scratch — there wasn’t a critical mass of internal IT skills to easily morph into this new role.
Finally, please notice the small blue bar over the traditional systems and storage disciplines. They were combined to start form a new function — the new private cloud architecture group. Network and security disciplines contributed, but still remained separate stacks.
Jon made an interesting — and insightful — observation. Where the systems and storage guys were somewhat comfortable with working together in a combined group, the network and security teams — while willing to help — strongly preferred remaining in their own separate disciplines.
I commented that “gee, that’s probably the Guild Effect”, i.e. the people involved preferred to see their career paths within the discipline vs. across disciplines.
A certain amount of pragmatism is required when considering organizational changes :)
EMC IT Infrastructure Organization – 2011
A few weeks ago, yet another revision to the organizational structure was announced, and — in many respects — it gets us far closer to the idealized end-state that Jon outlined at the beginning.
The most significant change is the elevation of the now-functional IT Service Management team to front-end the entire organization.
If EMC IT is going to behave like an internal service provider, it’s all about the services: defining, implementing, delivering, selling and marketing them.
Looking a bit deeper, there is now a strongly formalized “private cloud architecture” group. There is no longer a formal systems and storage group.
Although it doesn’t show up on the chart, more networking and security skills are finding their way into this team — especially the now-robust management and automation sub-function.
Another View Of End-State?
Jon finished up with purely logical view of his end-state “private cloud” organization.
At the top, it’s all about service management. Not the traditional trouble-ticket processing view, but the new view of delivering IT services back to the business — as a business!
These are supported by the core platforms: infrastructure, applications and more. Behind that, competencies in foundational technologies.
Service delivery is orchestrated by a single global command and ops center, tightly aligned with the help desk function.
I found this a very clear and easy-to-grasp picture of what it means to be an IT infrastructure organization in a private cloud world.
It’s A Journey
Four distinct IT organizational models in three short years. Entirely new functions that require entirely new skills and behaviors. A complete shift in traditional organizational boundaries and associated power and influence.
My congratulations to Jon and his team for pulling it off. I’m sure there were many dramas along the way — with more to come — but the transformation has been nothing short of amazing in this very short time.
And, along the way, supporting a quickly growing and demanding business that has no patience for internal IT challenges.
In retrospect, Jon and his team makes it look so easy. But we all know it wasn’t. Needless to mention, big kudos for publicly sharing his experiences — warts and all.
So — how many IT leadership teams will have to do something similar?
I’m sure we’ll know the answer before too long ...
These insights into the organizational coefficient of drag are hopefully not lost on the leaders that undertake this kind of transformation.
Unfortunately, current organizational theory and practice does seem to be the common skill missing from most leaders tasked with the operation of Information Technology. They either organize in a silo or a matrix choosing one of the prevalent conventional models.
I think all Enterprises have struggled with this organizational dilemma on how best to aggregate skills to deliver the services. The advent of cloud computing just provides some sense of urgency to address the problem.
Most re-organizations are viewed negatively by the people they impact precisely because they happen so frequently with little benefit. I think your comment about pragmatism when considering these changes is a great starting point.
Posted by: Blaine Berger | February 17, 2011 at 03:51 PM
Thank you for the opportunity given to me as I look forward to the interview.
Posted by: Unoma Aneke | April 18, 2011 at 11:50 AM
Chuck,
Your article is spot on. The key here is executive level sponsorship, funding and support. We have been successful getting the right sponsorship at a couple of key accounts using a model based on Kotter’s 8 step change model. We built a webinar and white paper around it at http://www.itsmsolutions.com/ITIL_Training_assessment.asp
Keep the articles coming.
Rick Lemieux
Managing Partner
www.itsmsolutions.com
Posted by: Rlemieux134 | January 09, 2012 at 04:21 PM