It's become an obligatory part of most enterprise IT conversations I have -- what's the latest org structure?
I joke that most enterprise IT shops are always in one of three states: (1) in the middle of a reorg, (2) getting over the last reorg, and (3) preparing for the next big reorganization.
I have been unable to find any useful industry data to confirm my impression that many larger IT shops appear to be in an almost-perpetual state of reorganization and realignment. Much more so it seems than other corporate functions: sales, marketing, finance, HR, etc.
Which brings up the obvious question -- why is this?
And what does it imply for enterprise IT strategy in general?
It's Not Universal
To be fair, there might be some sampling bias on my part. I tend to work with larger IT groups in fast-moving industries. If things are hunky-dory in your world, I'm unlikely to connect with you.
Some IT groups I meet are comparatively stable: same leaders, same people -- maybe a bit of readjustment around the edges over the years -- but nothing too dynamic. Stable, predictable evolution.
Others seem to be in a constant state of organizational upheaval: new CIO, new exec leadership, people leaving, new people coming in, org charts and missions being perpetually adjusted.
Personally, I don't know how I could be productive in an environment like that, but obviously there are people who've learned to adapt and thrive.
I have my theories as to why this is -- maybe you have some of your own?
IT Inevitably Has To Flex With Business Cycles
When business is good, the business invests in IT: new projects, more people, entirely new functions, etc. Reorg time.
When the business is not so good, IT becomes an organ donor: cancelled projects, fewer people, collapsed and consolidated functions, etc. Reorg time again.
Depending on the industry you're in, the elapsed time between "times are good" and "times are not so good" might be measured in quarters or months.
So the IT organization gets whipsawed by business cycles, and -- in reality -- the lack of a long-term IT strategy that can transcend the usual business cycles.
A Change In Business Strategy Always Drives A Change In IT Strategy
When a company goes on the acquisition trail (or gets acquired), IT change is inevitable. If the company decides to transform to a digital business model, or go global, etc. IT change is inevitable. Any change in business strategy always implies a corresponding change in IT strategy.
Big shifts in company strategy aren't all that unusual these days -- it's a healthy, competitive scrum out there in the business world. Everyone wants a piece of your pie. And every time the business calls a new play, IT is inevitably affected, and a reorganization ensues.
And there are many businesses calling many new plays.
What The Business Expects From IT Has Changed -- And Continues To Change
There was a time when one could have a predictably good career just being good at IT topics: infrastructure, applications, security, etc. That still can be true, but if you expect to rise through the ranks, you'll need to rebrand yourself as someone who deeply understands the business, and also brings IT to the table.
Good IT-only people really aren't all that hard to find. If you need a specialist, there are lots of good ones out there. Good business people who understand IT are much more rare, and hence in demand. In the digital economy, it isn't that IT just supports the business, IT essentially *is* the business.
When business leaders start expecting IT leaders to also be business leaders, a shakeup is in the works.
Good Talent Is Hard To Find
Being a fan of dividing things into categories, one categorization I frequently use is "talent rich" IT shops vs. "talent poor". This is not meant to be deprecating or degrading to anyone -- it is a legitmate (although unpleasant) business strategy to attempt to build a function that uses an absolute minimum of scarce, expensive talent.
I can tell a talent-rich IT shop within 30 seconds of meeting them. Smart, motivated, knowledgable and engaged professionals. Healthy and far-reaching debates ensue, with no shortage of well-informed opinions. Probe a little deeper, and you can tell these folks are valued by the business: compensation, benefits, development -- all of that. Great when you see it.
I also can sniff out the opposite very quickly. A sea of well-meaning but essentially mediocre and disengaged people, buoyed up by a handful of good folks trying to do the right thing. Often, the teams spends more time fighting political battles than solving real problems. Always inwardly focused, almost to a fault.
Sad when you see it, but all too frequent.
Here's the problem: I see so many IT shops where it's not clear what they're aspiring to be: talent-rich or talent-poor.
If the IT mission is to do the minimum while paying the minimum, that's a game that's easy to understand.
If the IT mission is to bring innovation and differentiation to the business strategy, that's also a game that's easy to understand. Neither is inherently unstable, organizationally speaking.
But so many IT shops seem to play the game in no-man's land -- not sure which way they're leaning. And inevitable organizational instability results.
My view? In any organization, talent matters. If you aren't willing to find and keep the best people, you're not going to get the best results. That's the way life works.
Enterprise IT Itself Is Changing
The way you did enterprise IT ten years ago won't be the way enterprise IT gets done in 2020. You can see undeniable evidence that the old ways won't be the new ways.
It's human nature to do things that have worked for you in the past. As IT professionals rise through the ranks, they tend to do the same as before, e.g. let me tell you what we did in 1998 or 2005 or similar.
Alert: it's 2016 folks -- 2020 is less than four years away.
When IT leadership doesn't detect, accept and embrace structural changes, they become blockers, not enablers. When they are inevitably moved aside, organizational change inevitably follows.
The Good News And The Bad News
Change can be good -- it brings about better things. Change can also be needlessly distracting -- disrupting normal activities without a corresponding benefit. The problem is -- it's hard to tell at the outset, isn't it?
In my world, "good change" is where there are clear and obvious signs to better support the business in new ways. "Bad change" is where it's basically the same deal as before, just using a different org chart.
One thing is for sure, if you've signed up for a career in IT, you're going to get pretty good at figuring out the difference between the two, and acting accordingly.
Like this post? Why not subscribe via email?
I have been prattling on about cloud topics for over six years now, helping IT practitioners come to terms with the changing world around them. It has often become a soul-searching, emotion-laden discussion.
Maybe I should get business cards that say "Cloud Therapist"?
In the last few months, it seems that cloud angst has started to reach an entirely new highs.
No such thing as a short meeting when someone needs to pour their heart out.
I think that's because -- when it comes to cloud -- most enterprise IT thinkers are waking up to the realization that they've hit an architectural wall, and it's starting to hurt.
It Didn't Start That Way
Go back many years, and I was explaining to people what a "cloud" was, and how it was different than traditional forms of IT architecture. Intellectually interesting, but hardly relevant to the world of enterprise IT back then. As an abstract concept, it was at a comfortably safe distance from day-to-day reality.
After AWS burst onto the scene, IT leaders were pressured to understand what cloud did, and potentially use it for some of their needs. Frequently, there was an emotional tone to the topic, as public clouds could be seen as competing with what in-house IT was trying to achieve on their own.
After that, a wave of interest in private clouds: flexible, cloud-like on-premises platforms that delivered infrastructure as a service (IaaS). All good.
To be honest, I saw most of the demand as a defensive reaction to demanding users who kept throwing public cloud services in IT's face, and demanding something similar.
And, of course, private clouds demanded a new operational model that created conflict with the rest of IT operations.
The seeds of discontent were sown when people started to attempt to have their private clouds work with public cloud services. Not surprisingly, the two were architecturally incompatible. And overcoming that incompatibility turned out to be horribly complex, difficult and expensive -- almost to the point of negating any benefits.
But it's 2015. And it's clear that cloud is the new architecture for enterprise IT. There's no turning back now, folks.
A Simple Picture
Imagine you've built a cluster of servers using your favorite hypervisor. Any application running on that cluster will essentially get the same operational experience. The cluster is managed and supported as a whole, and not piece parts.
Now, instead of lashing servers together, let's lash together a private and public cloud to create a hybrid cloud.
We don't have a nice, flat cluster anymore, do we? We have two very different execution environments for applications. Two very different operational and management experiences. Two very different support experiences. And so on. Note: I'm not even getting into data movement issues here, just to keep things simple.
Assuming you can theoretically overcome the architectural incompatibility with infinite effort, we're not done yet. If a great degree of complexity is involved to move an application from public cloud to private cloud, or vice-versa, you're not going to do it too often. Plan with great care what goes where.
What ever happened to the vision of compatible hybrid clouds, seamless migrations, bursting and all that?
Vision Requires Execution
Simply put, most industry vendors have only been able to deliver on half of the equation.
The enterprise hypervisor vendors (e.g. VMware / EMC / VCE) were able to deliver on a portion of the private cloud vision for IaaS, but never succeeded in delivering a meaningful compatible public cloud option.
IT shops who bet heavy are now at an architectural dead-end, it seems. Maybe someday, but when?
The public cloud vendors could deliver decent IaaS, but failed to deliver on a compatible on-premises option that works for enterprise IT. Bet heavy on a public cloud, and you're now stuck at the other end of the wire.
If we had the time and space, I'd share with you my thoughts as to why this situation exists, and why it's unlikely to change.
Which leaves enterprise IT leaders in a very, errr, interesting predicament.
The Frustration Can Boil Over
The pressure has never been more intense on IT to have private and public clouds work together, and it shows no signs of abating.
The business demands the speed and agility of public clouds -- especially when it comes to application development. And at the same time, the business also demands the control and economics of in-house private clouds.
It's long been true that the architectural decisions you make today will be the house you live in three years hence.
Three years ago, private clouds made sense, and no one was overly concerned about having a compatible public cloud option.
Or maybe it was OK to develop apps in the public cloud, despite the obvious difficulties of bringing them in-house.
Things have changed.
And the conversation can get pretty heated at times.
The Way Forward?
If perhaps we've made some architectural decisions in the past that didn't work out, how can we start making better decisions about the future?
First, acknowledge that the world has changed yet again. What might have made sense several years ago might not be the best decision going forward. Spill your guts, and move on -- the sooner the better.
Second, start drawing the right pictures.
Stop drawing little, incompatible cloud bubbles. Instead, draw one big compatible cloud landscape that incorporates private and public cloud working closely together. The better they work together, the easier your life will be -- and the more you will be able to do with cloud. And acknowledge that decisions made on one side of the wire impact the other side.
Third, begin to turn the ship around.
If you've invested in a technology that doesn't have a clear, functional equivalent on the other side of the wire, maybe it's time to migrate to ones that do. Yes, that process will take many years, but why wait?
No one is going to show up with a Universal Cloud Translator anytime soon.
The Oracle Perspective
If you haven't spent time investigating the Oracle Cloud, maybe you should.
You'll find a full, integrated IaaS/PaaS/SaaS stack, designed for enterprise IT. Many of the on-premises technologies Oracle sells (hardware, software, etc.) have compatible equivalents in the Oracle Cloud.
And, trust me, it's going to get even more interesting from here.
Maybe you didn't consider Oracle when building your private cloud. And maybe you didn't consider Oracle when selecting a public cloud vendor. Public and private clouds didn't need to work together, right?
But if you see your future as public and private clouds working closely together, using a consistent architecture and operational model, you'll find a uniquely interesting proposition.
And maybe I won't need to be a cloud therapist quite so often.
Like this post? Why not subscribe via email?
The cloud discussion has been percolating through IT for about seven years now. It shows every sign of now going to a full boil.
Most every IT leader I meet is now accountable for having an acceptable "cloud strategy" of some sort.
Up to now, I think it's fair to say that most IT leaders have been playing what might be charitably described as an edge game, largely by keeping cloud at the periphery of the IT landscape, and far away from the core.
Time is running out.
Sooner or later, cloud is going to crash into the core of IT.
Just like two planets colliding, the result will look very different for both. And the decisions you make today will greatly affect what the new world looks like when the inevitable happens.
The Many Faces Of Cloud
Fully appreciated, cloud has multiple aspects: a consumption model, an operational model, a service delivery model, even a business model for enterprise IT.
Most importantly, the advent of cloud has fundamentally changed the way we think about things, arguably for the better. Sorry, there's no going back :)
Just as most IT shops couldn't have made it through the last decade without some form of staff augmentation, the exact same could be said for cloud in the next decade.
Going it alone will become singularly unattractive and unpopular.
What's Your Core Cloud Strategy?
It's hard to have a customer meeting without the topic coming up in at least some form. While the responses vary, the pattern remains the same: 95% of "cloud strategies" I see always involve the periphery of enterprise IT, and keep cloud well away from the core.
We've gone to using Office 365. We've built a low-end private cloud to keep people from going to AWS. We're using a handful of SaaS applications. We're experimenting with a few apps with AWS. We're messing around with build-your-own OpenStack. Something along those lines.
All well and good, really. Most often, a measure of benefits are there, and valuable experience is gained. I'm certainly not critical of these efforts.
But, let's be honest, these are tentative first steps in a much longer -- and more important -- journey.
I've now started to follow up the cloud strategy question with a somewhat controversial supplemental: what are your plans for cloud concepts at the core?
You know, the applications and workloads that really matter to the business?
The Pregnant Pause
After a moment or two, the IT leadership folks usually come back with a reasonable set of responses, once you look past all the addressable security and control concerns.
They usually acknowledge their core IT environment isn't at all compatible with the usual popular choices, e.g. AWS et. al.. Lots of coding and conversion to get any sort of reasonable operational compatibility, even for small stuff.
The people who've seriously tried uniformly agree, it's a lot harder than it looks on the powerpoint. Standalone apps, maybe you stand a decent chance. Deeply integrated core enterprise stuff, no way.
This inherent architectural incompatibility is clearly a formidable barrier to adoption at the core.
Coming Back Around
You either believe that IT is evolving to a hybrid cloud model, or you don't. By hybrid, I mean that external resources are a seamless extension of what's running in the data center, and not another bag bolted onto the edge of IT.
If you do have this belief, you quickly realize that both ends have to meet in the middle: your core IT architecture and operations will have to mesh near-perfectly with your intended target public cloud. If not, it's going to be awfully hard to guarantee service levels, drive operational efficiency, etc.
In the face of inherent architectural incompatibility, the entire proposition comes into question.
Unfortunately, most (but not all) of the public cloud options weren't designed with core enterprise IT use cases in mind. There's not a full SaaS/PaaS/IaaS stack. There's not the option to consume the identical offering on-premises or externally.
And you'll see a disturbing lack of what I call "same-same-same": same technology, same architecture, same operations, same support, etc. Without this, attempting to deeply integrate cloud into the core becomes a morass of complexity and frustration.
If hybrid cloud is the new architecture for enterprise IT, these desires for a complete stack, flexible consumption options and inherent "same-ness" are hard to argue with.
Depositioning False Prophets
I look at many of the claims other vendors are making, and I shake my head.
Amazon's pitch is that you should put 100% of your workloads in their cloud. Goodbye, on-premises.
That's a fundamental non-starter on just so many levels, not the least of which is that you'll be essentially recreating your core IT environment from scratch. Oh yes, and you'll have to figure out what you want to do for integrated PaaS and SaaS.
VMware's pitch is that, once you virtualize with their hypervisor, you can move to any cloud you want. Assuming, that is, at some point in the future VMware can offer you a credible cloud.
Theoretically reasonable for IaaS, but -- again -- what about integrated PaaS and SaaS? And would you be comfortable with VMware's hardware-agnostic support model?
To their credit, Microsoft has a better understanding of what portions of the enterprise might need, but still serious gaps through the lens of end-to-end critical IT applications.
HP, IBM, Dell/EMC, Cisco, Google, et. al. non-starters in this particular game.
One interesting one you hear occasionally is IT's desire to be a "cloud broker". Much like people try to get the best deal for an airplane seat or hotel room (essentially commodities), IT can "play the market" by freely moving workloads between wildly incompatible clouds with no concern for data movement, operational compatibility, etc.
Maybe that's a theoretical possibility in the distant future for non-critical workloads, but I have a hard time seeing this be a reality for core enterprise IT in my lifetime. Who wouldn't want a Star Trek transporter?
Which leaves us with Oracle.
Oracle Cloud offers full and integrated IaaS/PaaS/SaaS.
Oracle owns their entire technology stack: from app to chip. They can deliver the exact same experience on-premises, in their cloud, or any combination -- and -- by definition -- working seamlessly together.
Oracle's mission-critical IT credentials are impeccable. Not to mention, Oracle is uniquely able to support the complete stack at both ends of the wire.
If we're having an adult conversation about bringing hybrid cloud concepts to core enterprise IT, it's a completely unfair comparison with other industry pitches out there.
Preparing For The Inevitable
Vendor olympics aside, there are some inarguable truths to be grappled with in the world of enterprise IT.
First, sooner or later it will be demanded that cloud concepts find their way into the core of enterprise IT.
Simply doing a bit of cloud embroidery at the edges won't pass the sniff test.
Second, the architectural decisions you make today will dictate whether that's an easy thing to do, or a near-impossible thing to do.
I would argue that any vendor who can't show you a viable hybrid cloud option that mirrors the core of IT should be considered strictly tactical, and not at all strategic.
And for those of you quietly hoping something better will come along, let me remind you that hope is a terrible strategy.
Like this post? Why not subscribe via email?
It's sometimes depressing to realize that I have been in and around IT infrastructure types for at least 30 years.
I certainly appreciate how they look at the world, but I despair when I see their own interests diverge from that of the businesses they serve.
Even though I suppose that's human nature, it's certainly not ideal.
Case in point: building for the averages vs. building for the extremes.
Here's the synopsis: in an effort to "standardize" the infrastructure stack, huge opportunities for portfolio optimization aren't fully considered.
But what might work for IT doesn't always work for the business.
Inside The IT Infrastructure Mind
Not everyone thinks the same way, but there's certainly a cohort that thinks alike.
They view IT infrastructure architecture as a layered stack, with clear preferred choices at each layer: server, storage, hypervisor and so on.
The idea is to ostensibly pick the "best" for each component, and standardize its usage as much as possible.
While everyone appreciates a modicum of integration between stack layers (e.g. the hypervisor and storage), the bigger goal is to reduce dependencies between layers, and ideally produce an architecturally agnostic stack.
The stated goal of being architecturally agnostic is to minimize "lock in", and reduce the effort associated with potentially swapping out one layered component for another.
Interesting side note? Observed behavior is that vendor choices at each layer are rarely replaced, and often remain intact for many years, or even decades. It's not like you're going to wake up Monday morning and say, "hey, today's a good day to swap out my hypervisor". Curious.
The architectural model in turn drives the organizational and staffing model: familiar roles and skills, e.g. storage person, server person and so on.
Any meaningful integration, though, is after-the-fact and never deeply architectural. Usually, integration is thought of as adding yet an another layer to the stack, for example automation or monitoring. Compromises abound, as a result.
From an outside perspective, one can be very critical of these build-it-yourself architectures. They're assembled, not architected. Getting predictable results in a minimum of time isn't easy. Keeping them running and updated can be a massive drain on resources.
And there's no compatible cloud consumption option for snowflake architectures.
On the other side, the presumption is the fewer disparate technologies, the better. The theory is that IT can gain internal leverage by limiting diversity.
Arguably, this might work for IT, but how does this work for the business?
One Size Fits All?
Because IT infrastructure types crave simplicity and standardization, there's a strong incentive to think in terms of an "average" workload, and design around that theoretical ideal. Put differently, the notion is that a single architectural stack should do a "good enough" job on most (if not all) workloads.
The thinking is that any benefit that results around stack optimization for specific workloads is more than offset by the benefits that accrue from a simpler, more standardized environment.
But, once again, that's IT looking after their own needs, and not necessarily the business perspective.
That's why it's not uncommon to hear people say things like "we're standardizing on HP servers" or vSphere or EMC storage -- although EMC has such a broad and diverse portfolio it tends to undermine the original premise.
Considering The Extremes
Two obvious opportunities for optimization usually stand out at the extremes, especially in larger environments.
For unimportant workloads, "standard" choices might not be cost-optimized: hence the interest in open source, white box servers and software-based storage stacks. So another architectural stack is often born, one with different goals. Hey, it's all about saving money -- who can argue with that?
The other opportunity for optimization lies at the other extreme: workloads deemed very important by the business, and not necessarily IT. Hey, it's all about the best tool for the job -- or should be, shouldn't it?
However, it doesn't always work out that way.
It's not unusual to see IT architects "stretch" their preferred technology choices to provide the required levels of performance, availability, data protection and security -- compromising the results -- where just realizing that the requirements are different and something purpose-built is needed and makes more sense.
Case in point: I meet with customers who are both heavy Oracle database users, and big vSphere users. During meetings, they'll sometimes talk about their heartfelt desire to run their critical Oracle databases on vSphere. Needless to say, there are good technical and economic reasons why that's unappealing, but they press on -- it's all about standards, you know.
Looks like round pegs in square holes to me.
The Business View
So, rather than thinking in terms of a workload distribution function as seen by IT, we used a curve that reflected the business importance of a given workload? We'd end up with a curve that's very low on the left, and very high on the right.
It's hard for me to imagine how a single architectural stack wculd be ideal across the spectrum. Indeed, I've found that IT organizations that are trying to 'standardize' across the entire portfolio end up missing the important extremes in a big way.
At the far left, they just can't afford or justify the familiar name-brand choices. And, at the far right, they end up with highly visible gaps vs. stated requirements.
If I were a business stakeholder -- and knew my way around IT -- my message to the IT team would be simple. Folks, these are our most critical applications that power the business. Stop messing around, and put in something that delivers proven results.
Even if it doesn't conform to your notions of fashion.
But What About Converged Infrastructure?
That's a fair question, and deserves an answer.
Using VCE Vblocks as an example, the premise is that VCE assembles popular choices and presents a single "virtual" product.
The stated goal is to help minimize operational effort through integration, standardization and support -- and it does do that in many situations as compared to folks who try to assemble and support their own infrastructure.
But we end up with the same problem in a different form: the choices have been optimized for the averages, and not the extremes.
VCE has responded to this by offering different flavors of Vblocks targeted at different use cases; however it's still basically the same stuff with slightly different packaging. Because of the architectural choices made, it's hard to optimize it for either extreme.
Same story, different chapter.
Oracle's approach to IT infrastructure stands apart from just about every other major vendor in the industry. The premise is simple: most important applications use the Oracle Database, so that is what should drive business-critical infrastructure architecture, co-engineering, stack optimization and integration.
I fully realize that this view is not popular with IT infrastructure types that think in terms of landscape-wide standardization, largely independent of workload.
However, this singular viewpoint is surprisingly appealing to people who realize that database applications are highly differentiated; and not generic.
We're not talking about the conference room scheduling application here.
I am not discouraged: there are literally thousands of IT shops who have seen the light, abandoned their one-size-fits-all mindset, and provisioned Oracle engineered infrastructure behind their databases and applications.
Generally speaking, they say three things (1) the stuff works as advertised, (2) the products deliver the promised benefits, and (3) they'd do it all over again.
If only everything worked so well :)
With Architecture, It's A Contest Of Ideas
Most people think vendor competition is a battle of products: feature/function, price, support, etc. That's largely true when considering point products.
However, the real war is in architectural thinking -- how things should fit together -- and that's a contest of ideas.
All is fair, as long as the goal is to optimize business outcomes, and not necessarily IT-centric ones.
Like this post? Why not subscribe via email?
And while we're at it, where does the whole category of converged and hyperconverged vendors go from here?
Right now, this is the #1 question I get from colleagues, IT pros and industry-watchers.
Make no mistake: I was a passionate advocate of VCE -- at the time. Many of my colleagues have worked for VCE, or -- in some cases -- still work for VCE. By the way, a big shout-out to my colleague Nina Hargus, just promoted from being VCE's CMO to EMC's.
I tend to want to wish people the best, but unfortunately the future looks quite dark through my lens.
The products may not have yet changed, but the context certainly has.
The Big Idea
VCE was born Nov 3 2009 (yes, six years ago) as a response to a problem we all saw in the industry -- customers were getting killed trying to self-assemble infrastructure. To this day, many still are.
Folks would take storage from one vendor, compute from a second, fabric from a third and a hypervisor from a fourth-- and that's when the fun started.
Some assembly required.
Infrastructure projects became lengthy and complex, with uncertain schedules and outcomes. Worse, keeping everything patched, upgraded and operational was a huge drag on IT operations, not mention all sorts of support calls.
There had to be a better answer.
The idea was simple, yet radical at the time. Create a "virtual infrastructure product" (later dubbed converged infrastructure) that masked the end user from the inherent complexity of multi-vendor infrastructure. Effort spent on the plumbing could now be invested in other, more productive areas.
It might seem rather obvious now, but -- at the time -- it took some serious evangelizing. However, to this day there are still many IT shops who haven't gotten the memo that build-it-yourself is often a poor way to do infrastructure.
Competitors reacted quickly but never really caught up in any meaningful way. And a host of startups tried to one-up the idea by eliminating the need for external storage, dubbed hyperconverged.
The good news?
Generally speaking, Vblocks delivered on expectations. Once IT teams realized they were making themselves miserable trying to be system integrators, their world became better.
But thee's always more to the story, right?
Structural Problems Underneath
The goal of VCE was to hide complexity from IT users, but VCE had no shortage of structural complexity to deal with.
First, the VCE product itself is after-the-fact integrated using standalone technology designed and engineered independently by three entirely separate entities: VMware, EMC and Cisco.
Each company has its own technology agenda. Each company has its own customer agenda. Each company has its own sales agenda. Each company is trying to maximize their portion of the deal.
Trust me, it was an uphill battle at the time, and probably still is. Despite press releases to the opposite, there were never any group hugs, and we never sang Kumbaya together.
The expected divisive forces between the companies were held together largely through the efforts of John Chambers and Joe Tucci. John has since retired, and EMC is now being sold to Dell. Other than a shared desire to take care of existing customers, I don't see a lot of appetite to continue strategic investments in the original VCE construct.
To better serve its customers, VCE proliferated their portfolio like crazy. The singular notion of a Vblock has now morphed into a dizzying array of variations: Coke, Diet Coke, Coke Zero, Cherry Coke, Diet Cherry Coke, Diet Cherry Coke Zero and so on. What was once a simple discussion now had become complex once again.
The other structural problem I saw was the underlying business model: VCE is essentially an additional integration/sales/support function. Customers were paying for integration that arguably should have been there in the first place. Also, that means almost no money for things like innovation, R&D, etc. -- most of that had to come from the parent companies.
What Happens Now
Dell will eventually acquire EMC, and for all intents and purposes, VCE is now just another product group at EMC that gets to carry different business cards. While Cisco-based versions of their products will continue to exist for some time, that's not where the focus is going to be. Witness VxBlocks.
Using Dell technology will obviously be the new focus. Strategically speaking, there's little incentive for Dell/EMC to invest in Cisco integration, and vice-versa. And the two CEOs who made it all happen won't be involved going forward.
The other challenge will be to continue funding VCE's comparatively expensive business model. The elephant on the balance sheet is ~$50B in debt that has to be paid off sooner than later. If the folks at EMC and VCE aren't expecting a massive haircut, perhaps they should. VCE will be in a tough spot to keep up their high-touch model, invest in value-added differentiation, while they attempt to continue proliferating newer Dell-based models of Vblocks.
At some point, something will have to give, won't it?
Sorry, But There's More
All the horizontal infrastructure business models are getting compressed. It really doesn't matter whether we're talking about servers, storage, networks or hypervisors.
The twin culprits are commoditization and cloud. Margin compression means less money to spend on R&D, creating unique value-add, and delivering top-shelf customer experiences.
Integrating horizontal technologies into an appliance did create new value for a while, but now it looks like just another, bigger lump of commodity. It's like a movie sequel: we know what's going to happen.
Real and sustained differentiation takes money -- great gobs of it -- and that's not going to be part of the equation for the foreseeable future.
The best answer to escaping the infrastructure commoditization trap is to move up the stack: applications and databases. People spend real money on that stuff :) But there's almost none of that in the combined Dell/EMC portfolio.
The best answer to escaping the cloud trap is to have one, obviously. Dell/EMC certainly has sincere plans, but it's going to take a while, not to mention great gobs of, errr, money.
And unless that future cloud has very rich PaaS and SaaS capabilities that enterprise customers want to use, any future IaaS cloud will tend to be commoditized as well -- thanks to Amazon, Google and Azure.
Strategically, VCE is stuck in a nasty vise. And there's no way out that I can see.
Playing The Game
As any card player knows, the value of the cards in your hand depends greatly on what game is being played. If the game changes quickly, what once looked like a winning hand can end up being a struggle. That's how I would describe what's happening here.
So what should VCE customers expect?
To be clear, nothing is going away anytime soon. The VCE construct will certainly continue to exist in some form or other to take care of existing customers, provide upgrades to existing products, etc. Neither Dell nor EMC nore Cisco will ever want to walk away from enterprise customers.
But I think that the days of VCE as a growth story are over. When a part of the business stops growing, investments are capped, and it's turned into a cash cow on the consultant's chart.
That's how the game is played.
By The Way
I think Oracle has figured out a strategically brilliant way to escape the twin traps of commoditization and cloud.
Let's not forget, Oracle has a compelling array of applications and database technology to integrate with infrastructure IP it designs and builds itself. If an IT shop is heavily invested in the Oracle Database and the applications that run on top of it, it's not even a fair comparison. That's what you can do when you own the whole stack: infrastructure, database, middleware and applications.
And have great gobs of money.
Oracle has escaped the cloud trap by actually having one: the Oracle Cloud -- a comprehensive array of IaaS, PaaS and SaaS services clearly targeted at enterprise IT that can be consumed either on-premises or via Oracle's Cloud -- or any combination.
If the game has changed, Oracle is holding some extraordinary cards, and certainly knows how to play them.
Like this post? Why not subscribe via email?