"The legacy" is the 800 pound gorilla that's at the core of any serious enterprise IT transformation discussion.
People want to move forward, but what about the legacy?
I've now met more than a few service providers that are currently impaled on the horns of this exact same dilemna that their traditional enterprise IT brethren face.
They understand their existing model quite well -- pros and cons. But, at the same time, there's a growing realization that a new model is needed -- one that isn't a mere variation on the existing theme.
And, as I watch these discussions unfold, it's less about vendors like EMC, and more abou overall business strategy -- especially if we're considering a growing and thriving SP.
A Familiar Topic?
I took a stab at this previously when I wrote about how the infamous "innovator's dilemna" can apply to SPs as well. It's a bridge that any successful and innovative company has to cross at some point.
Your company figures something out. You get good at it, and then start to prosper and thrive. At some point, the world changes, but you can't. The very forces that made you successful are now preventing you from making the next change.
When I engage with larger and more established entities that fit my profile of an SP, I usually get to see the drama associated with "innovator's dilemna" up close and personal.
And I'm getting to the point where I can begin to predict how the conversation will go -- and the likely outcome.
Case In Point
This was my first exec meeting with rather large and arguably successful service provider. Most of the key roles were present: service delivery, business development, presales and the exec in charge of the P+L.
Although they'd been arguably successful with using a cloud-based approach to deliver services, it was pretty clear their model was starting to come under pressure.
My take? They needed to broaden and differentiate their service portfolio (without increasing costs), find a more efficient way to get to market (without hiring a bunch of sales and marketing people) and drive even more efficiencies from their service delivery platform.
The challenge? They had already built something, and it was working pretty well. Most of their value-add engineering came from the orchestration layer that they had been continually enhancing over time.
Communication service providers will call this the OSS/BSS layer (the precise meaning of this acronym escapes me now), but -- in a nutshell -- it's the layer that defines, provisions and monitors service delivery -- as well as provide input into a billing system.
To deliver this first round of this capability, they picked a few willing (and smaller) vendors a few years ago, and started developing to the interfaces from their chosen vendors. Over a period of time, my impression is that they'd made everything work pretty well.
Unfortunately, they now faced two problems with this approach -- none of them pleasant to contemplate.
The first was excessively tight integration. The conversation between their orchestration layer and the underlying infrastructure components appeared to be so welded that considering alternate suppliers meant a whole lot of re-engineering and re-validating this key layer of software.
Now, one can argue whether or not Vendor X is better than Vendor Y or Vendor Z, but we were talking about a level of lock-in here that took *all other potential vendors* out of any consideration whatsoever in their infrastucture.
Enterprise IT people will shudder at this level of lock-in as they know it's bad all around -- except, perhaps, for the vendor who is fortunate enough to be locked in :-)
The second challenge was potentially even more concerning -- what they had built themselves as an essential business enabler was now largely becoming off-the-shelf capabilities. Certainly, there were a few upper-level functions that they still need to do for themselves, but the "talk directly to the infrastructure components" part of their orchestration layer was in the process of being even further abstracted.
The Moment Of Truth?
I think I brought things to an ugly head when I showed them a Vblock as an example of the growing category of pre-integrated infrastructure, and EMC Ionix UIM 2.0 which provided an integrated set of APIs that abstracted the underlying (virtualized) infrastructure.
Their "buy the best components, test and integrate them ourselves model" was certainly going to be under pressure going forward from integrated infrastructure offerings like Vblock.
Their "talk directly to underlying infrastructure components via very low level APIs" approach was also going to be under pressure from more integrated infrastructure management platforms like UIM that also had their own APIs.
As the discussion unfolded between the people responsible for delivering infrastructure services (the back end) and those responsible for growing the business (the front end), the debate became clear: where this SP had added value in the past was now under industry pressure, meaning they had to seriously consider "moving up the stack" to find new areas where they could differentiate themselves.
Bingo!
Just to be clear, this wasn't an EMC-specific (or VCE-specific) discussion -- it was where we all thought the industry was going. We were just the first ones to bring this particular discussion to the table with them.
And, since this particular SP works in a very competitive marketplace, it wasn't really a question of "if" something was going to happen along these lines or not: the forces were already in play, and their only real decision would be what they wanted to do about, when, and with who.
Hopefully with us and our ecosystem partners :-)
Change Is Hard
I ended up having real empathy for the back-end engineering team. They had spent so many years making their service delivery environment work, and work well. Unfortunately, in the act of making it work so well, they were now in the uncomfortable position of being seriously locked into their existing approach.
Technology moves fast, as do markets. Lock-in -- whether you're an enterprise IT group or an aggressive SP -- is not a good thing. So much had been built around the legacy, considering a rip-and-replace is largely out of the question.
No, they'll probably have to go down the path of putting up the "new thing" next to the "old thing" and run both in parallel for quite some time. That won't do anything to help their operational efficiency, I know.
But the front end of their business can't afford to stand still.
Much like the enterprise organizations they serve :-)
Comments