The Content Management market today seems to be moving in two contradictory directions at once. On the one hand, we see ever larger software players, such as IBM, Oracle, and Microsoft building or acquiring content management, driving it “down” into infrastructure. To IBM and Oracle, content is just an extension of their dominance in the data center. ECM to them is thus an extension of the database. Microsoft’s push, with both Windows SharePoint Services, and eventually WinFS (no longer part of Vista) is similar, but treats content more as the extension of the file system – the “back end of Office” as it were. While based on Microsoft’s very different perspective of working from the desktop inward to IT, it is still fundamentally an infrastructure play. Content management in this world is still fundamentally way down in the IT technology “stack.”
Yet on the other hand, we see customers increasingly funding content management from line-of-business budgets, and purchasing content management based on its ability to solve line-of-business problems. Performance, scalability, reliability are not to be ignored, but other questions dominate selection, such as: “Will we get more returns from our internet marketing efforts with this system?” or “Will our department be able to move up deadlines with this system?” In short, these buyers are positioning the content management system far “up the stack” as one or more different content-driven applications used to produce measurable line-of-business returns.
How can buyers be moving up the stack while the major vendors move down? The answer is part semantics, and part market shift. The term “content management,” including all of its current acronyms ECM, WCM or just CMS, is too generic. This is largely due to the fact that managing content itself is so new to both applications and infrastructure, that there it belongs in both places. Secondly, there is a real bifurcation going on in the market. The true infrastructure aspects of content management, such as optimal storage and retrieval, indexing, and library services are increasingly becoming commoditized and absorbed into the infrastructure software stack. But as these content services precipitate downward, they become too generic to solve any particular line of business problem on their own. This means that another layer of content-driven applications must emerge at the top of the stack, to provide the horizontal and vertical applications, such as internet and multi-channel marketing, something I blog about quite a bit. All of these very different offerings are today called “content management” with vendors for each moving down and up the stack respectively.
While technologists love the simplicity of block diagrams showing “the content management goes here,” the reality is that content management goes in a lot of places. For the foreseeable future, we’re going to have many systems, all of which do very different things, and yet all called Content Management of one kind or another. If you can better understand the specific initiative driving each new system or solution, you can better understand how your current systems do or do not apply, and whether you need to add more “content management” to achieve your goals.
Good observations.
I agree that the trend for Content Management has been following along two dual paths, one where CM is addressed as part of the infrastructure and the other where it is one component of high-level business applications.
On the infrastructure end, Microsoft and Oracle have both been trying rather unsuccessfully for years to integrate some level of CM into their software. Eventually they will probably get it right. Oracle’s Content DB shows promise. And given the number of years that Microsoft has put into WinFS, they may eventually get something usable too.
Dick Weisinger
You hit the nail on the head when you said, “…the reality is that content management goes in a lot of places”. For example, taking a granular view of just video content from an industry agnostic perspective, would you look within your marketing silo, regulatory compliance silo, learning management systems (HR silo), digital asset management systems (cross-organizational platform) etc.?
My view (on semantics) is that CTO’s should perhaps adopt an approach that positions tech-centric phrases i.e. “Performance, scalability, reliability” as business-centric phrases such as “consumer experience”. For internal applications, the phrase consumer can mean — the consumer of the service (as in a SOA context).
I also agree with your point on the emerging difference between the infrastructure layer and the application layer. Having worked on delivering components of IBM’s On Demand strategy, it is clear to me that the big boys will continue to dominate the infrastructure layer capturing the majority of the revenue from H/W, S/W & Services. They clearly have the advantage of existing data center relationsips and the economies of scale to support commoditized price points. However, the business logic that resides in the application layer will remain the forte of small application vendors, with open APIs, that can be plugged into existing architectures with relative ease.