I had a really interesting comment posted on my "SharePoint 2008 Report" by Marko Sillanpaa. Marko is half of the team over at http://www.BigMenOnContent.com and has been around the ECM space for a long time. His question was interesting enough for me to promote the answer to a blog entry. Here's Marko's comment, (reproduced without his permission or any regard for whether he minds or not.)

Thanks Andy. This is a great conference summary for those of us who wanted to be a fly on the wall.

I’d like to ask a question about your first bullet. You said that SharePoint sees themselves as a platform. How should we look at Documentum, a solution or a platform? It’s easy to see how a solution and a platform would work together. But when I look at two solutions to solve the same problem or two platforms to build the same basic sort of solutions, I just don’t see the value.

It sort of like why have both SQL Server and Oracle in the same space. If I need to build a database application, I’d look to the one that does the most for me. I wouldn’t put some tables in Oracle and other in SQL Server. Nor would I necessarily start in say SQL Server and then move them over to Oracle, unless I was looking to warehouse the data. Maybe I answered my own question. Is Documentum a data warehouse for SharePoint data?

This is by far my most 'rambly' posting ever so I've highlighted the actual response in bold at the bottom. Ignore the rest, it is complete self-satisfying drivel.

Let's start with the most obvious question - is Marko calling me Andy because he knows that I hate that or was it just him being overly familiar? (FYI: I am not short of nicknames for Marko if we want to start playing the silly-name-game so bring it on.)

Secondly, my comment was actually that the attendees at the conference viewed SharePoint as a development platform. I know that Microsoft do but I was surprised that every single person with whom I spoke agreed 100%. I loved Marko's analogy of SharePoint and Documentum being like two database systems. He succinctly asked the question that I think a lot of people are pondering right now. Are SharePoint and Documentum just different flavors of the same pie?

I wonder what Marko expects me to say or what he thinks I might want to say if I wasn't under 24/7 Microsoft Taser watch. Would I say that we've been doing it longer, they don't know what they are doing, they are the new kids on the block, they'll be gone in 12 months, Microsoft is just an overgrown startup, SharePoint will never catch on, my ECM system could beat up your ECM system..? The answer is...all of the above!

Seriously though, it is a great question and no longer just some academic, positional or defensive debate. The truth is that the pundits who really understand what is happening in the market are past the "it is a head-to-head" competitive situation argument. The relationship between a traditional ECM solution and SharePoint is much more subtle yet fundamental than that.

Before I start my longwinded analysis I'd like to address a word that I hear banded around with regards to this relationship. "Coopetition" - this is used to describe the situation where two companies are simultaneously competing and cooperating. Firstly, I hate made-up words, (except voluntold - to describe when you are told to be a volunteer), and secondly that's not a true description of the relationship between Microsoft and the traditional ECM vendors. Let there be no doubt - Microsoft are competing head-to-head in some areas of the business but in my ever-so-humble opinion they are competing head-to-head in less areas than they are not. Grammatical elegance notwithstanding, what I mean is: the gaps between SharePoint's capabilities and a traditional ECM solution are larger than the areas of overlap.

Here are a couple of great questions - Why is there such a big gap? Are Microsoft incapable or incompetent? Let me answer the first question, (the guy with the Taser is staring at me right now so I might not address the second question at all.) It has taken Documentum 14 years to build the capabilities of their ECM system. If I was starting from scratch I'd realize that even the behemoth that is Microsoft could not do it all in a reasonable length of time. If I was Microsoft, owner of the desktop, master of the productive application & champion of development tool where would I focus? Hell, I'd make sure that my solution was not just unified or connected to the desktop - I'd make it a core, native part of that environment, I'd close that relationship tighter than a...insert your own euphemism here.

I'm an amateur quantum physicist, (really I am; I'm studying string theory and multidimensional universes right now), and I know that in a parallel universe somewhere this posting slipped back in time and influenced Microsoft to take this approach so kudos to me for this foresight.

If I seem to be rambling on interminably and you are getting bored then it is because I am high right now; 37,000 feet and 5 cups of coffee high to be exact. I'm on a 5 hour flight back from Seattle and if I am stuck in 14C bored you might was well share some of my pain.

So, SharePoint and traditional ECM solutions overlap. They both have a repository, they both provide library services, (view, check out/in, etc.), they both have clients, etc. I'd contend that SharePoint's focus is on integrations in to the Microsoft desktop at the client and integrations in to Microsoft environments at the back end. So where would a conventional ECM solution add value to a deployment of SharePoint?

• What about a situation where the content is not being created by an individual who is working from within a Microsoft application? A scanned image, a document created by a CAD system, a piece of transactional content, structured data, report output, bulk ingested content, etc. In many ECM deployments the majority of the content in the system was NOT manually created. In order to manage the ingestion of this type of content you need a mature platform with the ability to handle the subtleties of these complex data types. For example, a single piece of content created by some common Apple applications actually consist of a group of actual binaries - the master file and a set of resource fork files, same goes for many CAD applications. The underlying ECM system needs to know how to maintain these relationships, handle versions and deliver the correct objects in to the right locations for consumption.
• How about managing XML-based content. That's a nightmare area that if Microsoft have any sense they'll leave to those of us who thought it didn't look too difficult!
• What about long-term archiving? SharePoint is probably not the ideal location for content to reside in for the next 25 years in a dormant state. For that matter what about short-term archiving - if the content is no longer active then why hold it in SharePoint?
• Data aggregation. Do I need to say any more, 80% of my Blog entries discuss this.
• Breadth of solutions. Microsoft tend not to develop vertical or point solutions; they develop applications, platforms and tools. OK so their partners do this en masse but the ECM vendors tend to do many more of them and in a more unified, proven way. Typically if you want to manage physical content, adhere to HIPPA, enforce retention, manage complex web sites and digital assets from within SharePoint you can either go to five Microsoft partners and get five stand-alone non-inter-operating solutions or go to a single ECM vendor get them all, fully unified with access from the native SharePoint environment.

There are many more examples but the bottom line is...if you view SharePoint as owning collaborative, in-progress, manually created Office-centric data then it looks like a pretty good fit. If you then add traditional ECM to manage heterogeneous, specialized, multi-channel, high-value, long-term, process intensive content then you truly will have the best of both worlds.

The guys from Microsoft might not like the following analogical response to Marko's original analogy but cut me some slack, can you think of a better one? Here's my response: I see the "Oracle vs. SQL Server" comparison as being more like "MS Access vs. Oracle". Microsoft Access is an amazing database, especially if you work in a Microsoft environment and are doing standalone, departmental applications; it does everything a database needs to do but within a limited scope. If you wanted to roll out a long-term, shared, enterprise-strength, secure, scalable solution you'd either go with Oracle/SQL Server or perhaps you might back-end Access with an centralized Oracle/SQL Server system that integrates in to your other enterprise solutions. Obviously, SharePoint is a much larger, more integrated and more extensible solution than Access but as an analogy I do see the comparison as being valid.

Here's how I see it from my ivory tower - SharePoint is a great access point in to the world of real enterprise content management. It created an entry point in to full blown ECM that 100,000,000 consumers can now access from their native working environment.

Let me preempt Marko's next question, isn't it likely that Microsoft will simply grow SharePoint in to a true enterprise content management system? Let's be clear, I am not party to Microsoft's internal long term world dominance strategy, (unless you assume that world dominance is indeed the strategy), but from how I see SharePoint being positioned in the market and how it plays in to Microsoft's core market I'd guess that they'll certainly mature in the enterprise areas but never really address it to the level that a true ECM system would today. Also bear in mind that any savvy ECM vendor is not going to sit still, they will continue to dominate in the areas that SharePoint is not prepared to address. My assumption is that SharePoint will focus more heavily on being pervasive in to Microsoft's core businesses and will turn in to a hybrid of a development platform, pseudo file system and an operating system overlay for corporate usage rather than a heterogeneous ECM system. Why do I think that? Because the former market is much bigger, less high maintenance and more aligned with Microsoft's portfolio.

Comments? Other than expounding the virtues of brevity or decaf coffee.