EMC Information Infrastructure for Microsoft

I think Microsoft technologies are poised to play an increasingly important role in the enterprise in the next few years.  Argue with me all you want, but I see it every day in most customer shops.

As you might know, my day job at EMC is running technology alliances, and one of the best partnerships we’ve ever formed is with Microsoft. 

Sometimes Microsoft gets a bad rap, which I think is unjustified.  Up and down the organization, they’re some of the brightest, straight-shooting and customer-focused people in the IT industry I’ve ever met.

And we’re doing great things with them across the board.  I’m extremely proud about what both companies have accomplished together.

About a week ago, I was asked by a customer “what is EMC doing with Microsoft?”.  I think he was looking for the 60 second response.

Well, it turned into a hour-long discussion that went all over the landscape, and I thought it worthy of an extended post.  I hope you agree …

Context

As EMC has evolved from primarily a storage company to an information infrastructure company, we’ve found more and more opportunity to work with Microsoft to better address customers’ needs.

As Microsoft was building their capabilities, and EMC was doing the same, we found example after example of areas where we could create synergy that benefited customers, as well as both companies. 

It wasn’t just one or two areas, it turned into quite a portfolio.

At the same time, we realized that we also had to invest in non-product areas to better present a complete solution that works hand-in-glove with how Microsoft approaches their customers.

I think it’s pretty close to a textbook example of how to build a good technology alliance in the IT industry.

The Beginnings – Storage

Way back when, it was all about the storage / server connection. 

We’d qualify our storage platforms and networks with various Microsoft operating system releases using our own methodologies (EMC eLab), and then work with Microsoft to pass their various certification programs (e.g. WHQL et. al.)

We also made sure that our replication products (e.g. SRDF, TimeFinder et. al.) worked well from Windows, and we integrated with newer Microsoft storage management interfaces (VSS, VDS and others).  All was good.

Along the way, we also became pretty proficient on setting up Windows in a SAN environment, implementing clustered failover, implementing SRM and file management in Windows environments, best practices for backup, recovery and replication, optimizing for performance, and so on. 

Quite a set of capabilities, most built around storage.

During this period, we had a unique value proposition: if you were doing serious stuff with large scale Windows deployments, we knew we were the best storage game in town.  That hasn’t changed substantially, in my opinion.

The Exchange Era

It didn’t happen all at once, but we gradually found ourselves talking to more and more customers about Exchange. 

There were performance issues.  There were backup / recovery / replication issues.  There were migration issues.  The mailboxes were getting pretty big, could we help with archiving?  And so on.

EMC at this time had become very acquisitive in terms of technology, and many of the new pieces fit into this new world.  The Legato acquisition brought backup and recovery capabilities, as well as a good archiving product, emailXtender, as an example.  Another smaller acquisition gave us some nice management tools for the Exchange administrator, and so on.

We realized we had a pretty complete Exchange offering.  We could solve performance problems by optimizing storage back ends.  We had SRM tools (ControlCenter) that knew about Exchange and how it interacted with storage.

Not only could we provide very specific Exchange backup and recovery capabilities, but we found we could add some “secret sauce” on top of replication to handle the specific nuances of Exchange.

As a result, we were one of the first vendors to attack the Exchange archiving problem. 

EmailXtender had a rules engine that could move targeted emails to an alternate location, but the user wasn’t aware that was being done.  This led to smaller mailboxes, the ability to do single instancing for larger attachments, easier backups of the production environment, ability to use tiered storage, and so on.

At the same time, the “save your emails” compliance wave was hitting financial institutions, so there was a whole lot of activity from that sector as well.  Before too long, we found ourselves with literally thousands of implementations around the globe.

But there were gaps – we found that it was hard to build the service delivery skills associated with large-scale Exchange products.  We had the technology, but we didn’t have (and couldn’t find!) the service delivery people to run these projects.

Before too long, we realized we had to make a major investment in professional services capabilities.  We ended up acquiring two gold-star Microsoft services firms (Interlink and Internosis) which formed the basis of EMC’s Microsoft Practice. 

All of the sudden, we had a small army of world-class specialists who could do just about everything for customers in a Microsoft environment, including Exchange.

This turned out later to be an extremely brilliant (or lucky?) move, as we’ll see in a moment.

Scaling SQL Server 2005

Along the way, Microsoft released SQL Server 2005.  Previous versions of this database were targeted at more departmental applications, but we saw enough in this product that we thought it could play in the big leagues.

I guess customers saw it that way as well.  Before too long, we were talking to more and more customers wanting to do the same kinds of industrial-strength applications that used to run on Oracle and UDB, and move them to SQL Server 2005.

Backing up a bit, over the years EMC had built a pretty serious capability with large production databases. 

We knew a lot about performance sizing and storage optimization.  We had great proficiency using local and remote replication for high-speed backup and recovery.  We had capabilities setting up enhanced test/dev environments using replication.  We had archiving tools (dbaseXtender) that could use ILM techniques to manage instance size.  Our SRM tools (ControlCenter) knew a lot about databases, and so on.

What we found is that we could take a lot of the same expertise and apply it directly to SQL Server 2005.  We knew what the big problems were in running big databases, and we could help customers create strong infrastructure that helped SQL Server 2005 shine.

Lots of activity in the SAP space running on SQL Server 2005, and – of course – our capabilities in SAP work there as well, but that’s another story, and another post.  And, of course, our Microsoft Practice made sure we had the skilled people who could help customers with large projects.

We now are running some of the biggest SQL Server 2005 instances around, and there’s more every day.

Documentum Meets Sharepoint

As you know, Office 2007 is really big stuff. 

From our point of view, it’s SharePoint that’s interesting.  For the first time, basic ECM (enterprise content management) features are now part of the Microsoft Office environment that we all use: things like forms, workflow, search, collaboration, a bit of content management, and so on.

During 2006, EMC invested in creating a high-definition bridge between the world of SharePoint, and Documentum.  We also made sure that Documentum ran very well on SQL Server 2005.

I think this is huge, and let me share why.

One of the most fundamental problems in ECM technology is getting people to use it.  If files have to be categorized by the user as a separate step, that’s not good.  If I have to jump out of my day-to-day environment to use workflow, or search, or whatever, that’s not good either.  You’d like everything to be seamlessly blended into the user’s desktop experience.

What we saw in this release was the ability for more and more people to make better use of enterprise-grade ECM capabilities in Documentum. 

Maybe the customer has a core set of capabilities implemented in Documentum that they’d like to get in front of more users. 

Or, more likely, they want to take steps to avoid “SharePoint Sprawl” the same way it happened in Lotus Notes and related environments. 

Or, perhaps they’ve got some things they need to do that aren’t found in the Microsoft product, maybe working with non-Microsoft applications, or advanced compliance features, or something similar.

Anyway you slice it, this is big news in this corner of the industry.  Customers get a unique combination of well-integrated desktop capabilities from Microsoft, plus an enormous portfolio of enterprise capabilities from EMC with Documentum.

Not surprisingly, when customers understand this, they’re extremely interested.  It doesn’t take a lot of explaining as to why this is so important.

And We’re Not Done Yet

A little bit farther out, you’ll start to hear about some great work we’re doing with Microsoft around integrating our Smarts offering with Microsoft Operations Manager (MOM).  The potential here is again a high-definition integration between Microsoft’s growing set of management tools, and the power of Smart’s model-based discovery and correlation engine.

Who knows? 

We think the new relationship between Microsoft and Novell has great potential.  There’s some interesting things we can do with RSA technology and the Microsoft portfolio.  And, when Microsoft releases their next round of virtual server technology, there’s a bunch of stuff we can do there, mostly based on the work we’re doing with VMware.  .

It just keeps getting better and better.

And, In The “Everything Else” Category

Most of my comments above have been about technology, but there’s a pretty extensive wrapper that ties all of this together and makes it work for customers.

One example is customer service.  Over the years, we’ve honed our ability to jointly tackle support issues in a combined EMC and Microsoft environment.  Our support guys know how to work with their Microsoft counterparts, escalate appropriately, and present one face back to the customer.  It’s not easy to do, but we’re doing it.

Another example is joint customer engagement.  Both EMC and Microsoft have invested in specialists that bring the two field-facing organizations together so that customers don’t have to tie the pieces together themselves.

Our engineering organizations regularly do roadmap reviews with their counterparts, not only to stay in sync, but to spot opportunities where we can do additional integration work. 

We’ve invested heavily in what I call “solutioneering”, bringing together multiple product sets from both companies, and documenting best practices around common use cases (e.g. migrating to Exchange 2003 or 2007, or maybe replicating SQL Server 2005).  These blueprints are freely available to our customers and partners.

Stepping Back A Bit

I think the EMC / Microsoft relationship illustrates well what technology alliances are all about.  Deep integration of technology that solves unique customer problems.  Thorough testing, qualification and solution validation around how customers will use the products.  A small army of trained specialists that can help customers translate theory into practice.  Joint support and customer engagement that makes life easier for everyone.  And so on.

It's not perfect, but I think you’ll agree, it’s a pretty broad waterfront of engagement points, and – taken in totality – it’s quite a story.

But I think we need to do a better job of telling this story, and that’s something I hope to address in 2007.

Comments

[Amy, Consultant]

Dear Chuck,

Thank you for the indepth response to the question: "What are Microsoft and EMC doing together?"

Here's a similar question, "How do Microsoft & EMC work together to provide a joint solution?"

You mentioned joint support and engagement in your blog but nothing specific about how that occurs. Should an established MSFT customer contact their rep or work directly with EMC? Please provide links to relevant info.

Thanks!

[Chuck Hollis]

Hi Amy -- great question.

No easy answer, but -- in general -- Microsoft is extremely proficient regarding the functionality of their products -- what features, and the business benefit they offer.

EMC tends to focus on infrastructure and consulting issues. How do you scale it? Migrate to it? Manage it? Backup, recover and archive it? Secure it? And so on.

A typical engagement point I've seen is our Microsoft Practice. Working with Microsoft team, they provide the project plan that bridges the gap between the potential and the practical reality.

This might include infrastructure design, migration planning, integration work, run book development, and the like.

Other engagement points are possible, but I can't cover them all here. However, if you'd like to drop me a note with more specifics, I'll see if I can help a bit.

Thanks for writing!