Our story so far:
Cloud concepts are in the process of transforming IT organizations into internal service providers. This -- at its essence -- is turning into an organizational transformation challenge.
Organize IT around technology silos; and that's what you'll end up delivering to the business. Conversely, organize IT around delivering competitive services to the business, and that's what you'll likely deliver.
Smart IT leaders are quietly assessing their organizations, and figuring out how best to begin to implement these new constructs. Very often, they find a critical mass of key individuals who can morph to the new roles.
But with amazing frequency, these same leaders are coming up short in a key area when fishing in their internal gene pool.
They're often missing a few essential DNA strands that are incredibly scarce within most IT organizations, but surprisingly plentiful outside of IT.
And I'm guessing that -- before long -- we'll see some interesting recombinant DNA experiments as IT leaders start to pull in the missing profiles they'll need for success.
What's This All About?
Cloud is the big IT industry transformation -- no part appears to be able to escape unscathed.
For any IT organization operating at modest scale, this is turning out to be a major transition indeed.
IT organizations are challenged to do a 180 degree turn -- from facing inwardly towards the technology to squarely facing the business, and beginning to deliver the competitive services they crave.
Organizations deliver what they're organized to deliver. Give me 3 minutes with an IT org chart, and I can make a good guess as to what their business stakeholders think about the IT function.
Indeed, when I get in to the meat of the cloud discussion with customers and partners, this is where we always end up: it ends up being an exercise around organizational transformation and building new functions, and less about specific technologies.
I covered this discussion in some depth in a recent post "From Slios To Services", using EMC IT as an example of not only the end state, but the step-by-step evolutionary path we took internally.
The End State Model
The structure of the end-state is deceptively simple -- it's a three part model.
At the bottom we've got the traditional foundational technologies.
In the middle we've got a shared-services platform -- ideally, one standardized "factory" that produces the vast majority of shared services.
And -- at the top of the stack -- individuals who "own" the relevant services provided -- defining them, marketing them, obsessing over them, and so on.
As far as staffing and organizing the foundational technology function, the gap is manageable for most: yes, some of the technologies are different (or used in new ways), but -- at the end of the day -- it's just a new flavor of technology expertise.
Constructing the platform team is a bit more challenging, but often achievable. The natural tendency is to hand-carve customized architectures -- one per project -- which has to be re-oriented to creating standardized shared platforms that can support a multitude of service offerings. These people are still building things, it's just one big thing vs. a multitude of individual projects.
Making this part of the transition can be more difficult, but many IT organizations appear to have enough of the key critical skills here to make the required transition. Often, it's the crew designing and running the VMware farm that's best positioned to move the game forward.
The final portion -- and ultimately the most important to get right -- is the part of the stack that exposes the services, drives their consumption, takes feedback from the consumers (whether internal to IT or external) -- essentially being a mini-entrepeuneur within the IT function.
This same three-part construct can be used though out IT to deliver infrastructure-as-a-service, platform or database as a service, applications delivered as a service, or user experiences (e.g. desktop) as a service.
To be clear, this is not a new idea. Look inside most successful IT service providers, and -- yep -- you'll see the exact same constructs.
Makes a certain sense if IT is aspiring to be an internal service provider :)
Where It Gets Difficult -- And Easy
Think, for a moment, what your challenge would be if you were running a general store in -- say -- a seasonal vacation spot.
For starters, you'd understand your audience (vacationers) and you'd initially stock it with your best guess as to what people would want.
You'd certainly invest some time and effort in presenting your wares in an attractive and consumable manner -- you wouldn't keep everything locked in a back room.
You'd also keep a close eye on your customers -- what they were buying, and what they weren't. You'd stock more of the stuff they wanted, and less of the stuff that was moving slower.
If someone came in who wanted something you didn't have, you'd do your best to find something on the shelf that met their needs. As a last resort, you'd offer to special order something -- with all the complexity and delay involved.
It's not a unique perspective, is it?
Well, it seems to be incredibly scarce within the majority of IT organizations I've met. We hire people for their technical and operational skills, for their ability to be problem-solvers and collaborators, and so on. All important skills in the portfolio, to be sure.
But how many people do we have in IT who have that retailing and merchandising mindset as part of their DNA? Not many, it seems.
Look at it this way -- if you're going to invest in creating and exposing competitive IT services back to the business, who's managing the storefront? Looking after what customers want? Ordering up the stuff that people seem to want, and getting less of the stuff that people don't want? Setting prices that the market will bear?
Any time you walk into a retail shop, you'll see evidence of that mindset. Any time you speak to an IT organization, you usually won't have it -- you won't have it for serving other parts of IT, and you certainly won't have it for the business.
Making My Point -- Brutally
I'm in a customer conference room. They're getting defensive. They say they have a private cloud. They say they have a service catalog. I disagree, and decide to make a highly visible point.
Can you show me your service catalog right now? As it appears to potential consumers? What does your "storefront" look like?
Short pause.
Cue frantic scrambling for a long-lost powerpoint or spreadsheet, or maybe a dismal web page on the intranet. I look more closely -- the "services" are actually individual technology components -- CPU cores, GB of RAM, gigabytes of storage, network addresses, etc.
Who owns this? -- I ask.
A longer pause.
There's your problem -- I state. If I'm your "customer" -- whether I'm inside of your IT organization, or outside of it -- is this the best you can do for me? If I don't like what I see, or want to know more, or understand what my options are -- where is the shopkeeper for your store?
Very long pause indeed.
You get what you organize for. Organize around technology silos, that's what you'll deliver. Organize around individual IT projects, that's what you'll deliver. Organize around delivering an attractive portfolio of IT services, that's what you'll deliver.
Another thoughtful pause all around.
In Search Of The Entrepreneurial Genome
The world is awash with people who thrive on understanding customer's needs and continually finding new ways to satisfy them.
Our own IT organization at EMC realizes this, and is starting to seed the infield with this important strand of DNA.
I've seen it in a few customer examples, but not nearly enough.
Unfortunately, that's not the usual hiring profile with IT organizations today, is it?
And I can offer a safe prediction -- it can change, and it will change.
Otherwise, the consquences will be too dire for IT leaders to consider.
Comments