A couple of ECM old-timers (Marko and Laurence) posted their thoughts on Content Management – a solution or a platform last month. This post will present our thoughts on the enterprise content management landscape and some of the history of the platform versus solution debate as well as our thoughts in regards to the impact of movement to the ECM cloud.
Content Management, Platforms or Solutions?
Word of Pie (Laurence Hart) post his thoughts on the Platform versus Solution approach back in June. Laurence comes from both the Documentum consulting side as well as a short stint at Alfresco. Main points of the article included:
- ECM failed because suites were loose integrations and not true suites.
- Companies ended up with multiple ECM systems through acquisitions or neglect of existing systems.
- Predicting that cloud vendors will pull together under a common umbrella.
- Makes an argument for the platform appeal for IT departments to offer frameworks when building solutions for business. While Laurence seems to acknowledge that IT departments can’t satisfy business user needs with a bare-bones approach, solutions are available from partners but partners may or may not be true “product vendors”.
- CMIS (Open API for ECM) was to address cross platform access but hasn’t been successful (and not even said by cloud vendors)
The article is concluded with a prediction about Open APIs from cloud vendors with a way to build real applications with different services.
Big Men on Content (Marko Sillanpaa) also posted his thoughts on ECM as a platform versus a solution back in January as well as a response to Laurence’s post on having ECM vendors use Oracle as a guide. Marko also comes from a significant ECM background including Documentum as well as a recent stint at OnBase.
Marko’s main point from both articles is that ECM solutions should follow the approach of Oracle, where, Oracle became a default platform for database activities that internal, vendors and other solutions relied on.
All three articles highlight some good points with regards to the struggles of ECM solutions. However, we disagree that the failure in the adoption success of ECM, either as a platform or solution, was the result of API, suites or other technology decisions. We would argue that the timing of ECM as an approach (late 1990’s) as well as the continued evolution of the influence of business on ECM decisions are bigger contributors. See our thoughts below.
ECM – why “one ring to rule them all” didn’t work – don’t blame the ECM vendors, blame the business
The appeal of an ECM solution, from an IT infrastructure side, was to have one common platform to support (rather than many). IT could be more efficient from the resources (People, Hardware, Applications) that can be supported from that one platform consistently. Businesses could pay less for shared support. The ECM vendors would love to have had the success of Oracle as a platform with support from most major solutions/vendors/products. One major difference, Oracle grew up when the database was everything and was able to squeeze out many competitors (IBM, Sybase, Informix…) with the exception of Microsoft. ECM grew up when content management was an add-on and lots of different options, including just file links in the database, were alternatives. Whether it was price, the variety of ECM options, or solution vendors, the marketplace never really evolved to allow solution vendors to bring in an underlying ECM solution.
When Oracle was growing up, businesses wanted the solution but delegated to IT to determine the database platform. Given the number of content management alternatives, Business didn’t like being told which content management platform they had to use for their business solution or wait for an IT bare-bones approach. If a solution wasn’t available or satisfactory from a vendor or partner for the ECM platform (or they just liked something better), business would often just pick something else based on a variety of factors. In working with our clients with multiple repositories, it is not uncommon to see one system for Accounts Payable, one (or two) for manufacturing content, a different system for R&D as well as different systems for different branches or departments. Some examples, Opentext for SAP, iManage for Legal, Documentum for Pharma Submissions…..
We would predict that the cloud will accelerate the business influence into which content management solution is chosen and IT influence will matter less and less. If a cloud vendor (ex Salesforce) has a content management solution or partner solution that business can purchase without IT involvement and fits a business need, would a business user care about APIs?
ECM and the Content Silo(s)
One of the other pushes for ECM to the business was that, by leveraging one consistent tool across the enterprise, other groups that needed access to documents could easily find the documents and the enterprise would avoid content being stuck in a “Silo”. Many times IT (and ECM sales reps) would use this argument to convince business users to stick to the ECM standard. Over the last 10 years, many business users have questioned if they want to support something that, if they are only using it for their department, they care about sharing across the enterprise.
Cloud vendors have only multiplied the silo choices. Over the last 10 years, we have changed our approach to not focus on everything evolving to one repository, but have instead focused on a publishing approach to move content between silos when appropriate. See our recommendation about publishing versus other cross repository choices here. The publishing approach provides some substantial advantages over the one repository approach while allowing business to leverage their previous investments.
APIs and Cross Repository Access – ECM Vendors (or Cloud) never really wanted to share anyway
Marko makes a great point that Oracle was able to establish themselves as a default platform where solution vendors would build/rely on Oracle. Some of that was the success of SQL, much of it was timing and a move to dominance as one of the top 2 database choices. ECM has never had a consistent interface like SQL and no single vendor ever emerged as a dominant platform. With the cloud, the number of vendors is increasing.
Some of the push to have a consistent interface resulted in the DMAPI in the late 90’s as well as CMIS in 2000’s. In our dealings with ECM vendors, we have never seen any of them really embrace an open API as a way to remove content from their repositories. Laurence hopes that API calls from cloud vendors will allow “the ability to begin cobbling together real applications using different services. If those new applications also have a fully defined API layer, then we are starting to make real progress.” Given the history of ECM vendors wanting to keep control of the repositories, we would think that cloud vendors would be the same.
In building our own solutions, we realized we had to build our own interface to repositories, OpenContent, if we wanted to provide our products and solutions on more than one repository.
The ECM Suite – more platform and not so much solution
Most of the vendor consolidation around providing an ECM suite was more of a horizontal integration of common ECM components as an extension to the platform rather than a push to provide more vertical solutions. For example, Documentum, as a platform, initially supported scanning/indexing solutions from Kofax or Captiva. When Documentum bought Captiva, it didn’t really have much of an impact on clients with the exception that Documentum sales reps could now sell both the capture as well as the repository. While the platform extension makes solutions easier (example Accounts Payable when scanning), we never saw the suite as anything more than giving ECM sales reps something more to sell to their clients.
Changing ECM IT Role – Tell versus Influence
With the cloud providing additional business flexibility, IT needs to change their role from telling business to use “this platform” to influencing business to leverage a platform when it makes business sense. TSG has provided this support for both business and IT clients. When making decisions about leveraging different internal ECM solutions or cloud solutions like Box or Dropbox, we have worked with both business and IT in an advisory role. This allows us to understand the different options from both a governance and support perspective.
A great example comes from one of our clients that wanted to leverage Box (cloud content collaboration) within an approval process. We were able to build an integration that allowed Box users to collaborate on documents but, when ready for approval, were able to access the governance and consistent storage capabilities of Alfresco. You can see a demonstration in an earlier post. Rather than push the business to only use Alfresco, we were able to influence business that liked the collaboration capabilities of Box to use Alfresco (platform and solution) for robust workflow and approval.
Summary – Integration Services
The “E” of ECM (Enterprise Content Management) had always hoped for a consistent platform within the enterprise. Business wants choices and the resulting choices have resulted in most large organizations having multiple ECM solutions and platforms. Businesses will always look for a way to implement efficiently and will pick solutions or products they can leverage from a consistent ECM platform if available and meet the business need. If the platform or solution doesn’t meet the business need, the business will look elsewhere with new cloud vendors as potential cost-effective alternatives resulting in content silos throughout the enterprise.
In this environment, our approach with our clients has been to provide products and solutions that can run across multiple repositories as well as innovative integration approaches like the publishing approach mentioned earlier. We would predict that innovative IT services would look to provide similar capabilities rather than fight a losing battle with business about the ECM platform, especially as additional cloud solutions enter the market.