For those of you who haven’t seen it yet, Chuck Hollis from EMC has started a(nother) blog, this one specifically about the SP business and how it relates to EMC. I couldn’t be more excited. One of the reasons I started this was because of the lack of voices, and his is a good one to have. Hopefully other vendors (NetApp) will join in the conversation because the only thing more fun to read than an EMC blog is the back-and-forth between the vendors!
In his introduction to the blog he wrote something that really hit home for me:
The only downside — and it’s not a biggie — is that I meet a lot of SP-oriented companies that did a fair amount of home-grown IT to get themselves where they are today.
They built really cool stuff that served its purpose at the time, but — more often than not — it’s time to move on and step up to the purpose-built stuff. That can be sometimes hard for people who put their sweat and tears into very difficult and complex integration, scripting, automation, etc.
While it’s a pretty safe comment to make, after all what competent technology organization hasn’t had to build something themselves to get what they needed at some point, it speaks to a key challenge inside the SP environment: sometimes you have to be cold-hearted to succeed.
I’ve worked in enterprise environments before (telecommunications, health care, legal), and there were always a collection of “legacy” apps. You know the ones I’m talking about: old, cranky, at least partially developed in-house. They usually have that one guy on the IT staff who knows how to care and feed them, and they can persist for years and years, because there’s no real driver to make the investment in the migration and upgrade process.
At my company (and possibly most service providers), that concept is completely foreign. Sure, we build things in-house, but it’s always a means to an end. Once the product in question proves its business model we immediately start looking for a standard, supportable, repeatable way to deliver it, getting rid of all traces of the legacy environment. This phasing of the product sets is great for the business (if the product doesn’t work we haven’t stranded a lot of capital) and for the customer (they get new products introduced quickly), but for the engineering team who is involved in the service/infrastructure design there’s definitely some heavy hearts at times. We ask these guys to invest a lot of time and effort into building things that are usually complex and require them to dive deep for periods of time. It’s a badge of pride for them when a project turns into a product, because it means everything worked as expected. There’s always another project to work on, but it’s hard to let go of something they see as their baby. It’s even harder when your engineering team is a relatively young group of people, because they usually don’t have the long term perspective needed to let go and move on.
We are trying to teach them to be cold hearted and focus on the success of the company. That’s all that matters, not the longetivity of the platform.