TSG was part of a presentation on at the Document Strategy Conference two weeks ago.  One of the follow-up items was our thoughts on an ECM Roadmap.  Tied to our earlier post on upcoming ECM disruptions, this post will present our initial thoughts on defining a roadmap and approach for modernizing an ECM System.

Where does the roadmap start?

Most of the time, clients that are asking us for a roadmap to a modern environment have an existing ECM solution.  Typical of the existing ECM systems fall into one or many of the following scenarios:

• Image Processing – 1990’s – we still see a significant amount of FileNet, DB2 Content Manager and other Legacy ECM systems that were built in the early 1990’s to early 2000. Back then, some clients were making the move to paperless and added scanning components and other image processing capabilities.  Depending on the vintage of the system, we might still see proprietary file formats and viewers.  Many times the systems have either been updated to include newer components or users have developed workarounds to address system deficiencies (example – users printing out documents just to scan them in).
• Early Document Management – we also often see Document Management systems (example Documentum) that were last updated before the last downturn of 2008. These systems typically have more modern capabilities but might still have some legacy components.   Many times clients made significant investments in their ECM capabilities but haven’t made new investments to keep them up to date.
• Mix and Match – Document Management – with mergers and acquisitions, many times clients will have a variety of different image and ECM solutions that have been cobbled together. Combined with SaaS providers, SharePoint and other tools, clients struggle to have one consolidated view of their documents.

Challenges for the Roadmap

Given an existing ECM infrastructure, challenges for developing and implementing an ECM roadmap include:

• Budget – trying to do “too much” can result in a large effort and budget that might not get approved. Successful roadmaps should have a strategy to proceed at a cost justified pace to gradually replace the old infrastructure rather than trying to do everything in one risky big bang approach.
• Resources – ECM is not the robust environment as it relates to IT and consulting resources it was back in the early 2000’s. Many of the ECM experts have moved on to different technologies.  The resources that built the old system have often either left the company or moved to different responsibilities.  Finding the resources to help understand the old system, as well as all of the integrations, along with help move to the new system can be a challenge.
• Delay – with an old system in place, too often management can just pay another year of maintenance and “kick the can down the road” to delay any ECM roadmap to next year or next quarter. Typically the most difficult part of any roadmap is starting it.

What are the disruptors and why should they be part of the Roadmap?

A successful roadmap can’t just identify what we are doing now but help map a path to the future.  As we mentioned in our article about ECM disruptors, we see the following major disruptors to ECM that could address the cost/delay of modernization efforts and should be addressed in the roadmap:

• Infrastructure as a Service – a significant cost and complex component of legacy ECM was the hardware to support the solution. Infrastructure as a Service (IaaS) can substantially reduce the cost and complexity of ECM solutions and something we are seeing in all clients ECM (and IT) roadmaps.
• Browser Based Viewing – Clients want to pick not only the device but flexibility to leverage any browser. Legacy solutions that required client side Java Applet plugins, ActiveX or other client components are being replaced by browser-only viewing and annotation tools.  Modern solutions focus on agnostic browser solutions (Chrome, Safari, FireFox….not just IE) with reactive capabilities to address both PC and iPad/tablet/phone platforms.
• Software as a Service – Are there components in the current product set that could be replaced with external solutions? Docusign is an obvious example but are other services something that can be leveraged by the ECM.
• Open Source – we continue to believe that Open Source, whether replacing the ECM or just components around the ECM (Solr/Lucene for example), continues to drive innovation and cost reduction in the ECM space.

In our article, we identified Big Data and Analytics as possible future disruptors.  While we do see a future that might include Big Data and Analytics as components of the ECM roadmap, we don’t see a requirement to include them in the roadmap at the current time.

ECM Roadmap – Infrastructure as a Service vs. On Premise

Key to any modern ECM roadmap will be the replacing of not only the legacy ECM systems but also their legacy infrastructure components.

As we posted last week, we think the biggest disruptor of ECM will be Infrastructure as a Service (IaaS) with Amazon Web Services and Microsoft Azure leading the way.  We think the first step of a successful ECM roadmap might start with an evaluation and modernization of the application infrastructure.  For many clients, this will include IaaS in the cloud, but could start as an effort to replace legacy hardware with virtualized servers.  Rather try to pick an ECM tool, clients should look to determine their IT direction with IaaS or on premise with an eye to an eventual cloud move to help guide how they will be picking a new ECM.   New ECM architecture should be able to not only run in the new cloud environment but have significant support from the ECM vendor for the cloud environments.

ECM Roadmap and the Cloud – be careful of the infrastructure components

With our clients moving to an IaaS cloud provider, one of the biggest hurdles is getting the IaaS private cloud to really be an extension of the internal IT infrastructure.  Integration components include LDAP synchronization and authorization, VPN, and SSO.  We would recommend moving forward with the ECM modernization efforts while a parallel IT group is focused on designing and building the infrastructure components of the cloud.  Pushing ECM to “lead the way” to the cloud might be a significant technical and political hurdle.  To avoid a potential impact for the ECM roadmap, we would recommend:

• Delay LDAP and VPN implementation. Users are used to adding user names and security as part of their normal consumer internet experience.  Rather that causing ECM delay for the first cloud instance, consider the first implementation will require users to be maintained within the cloud and log on to a separate, non-integrated instance.
• Often times, the hardest part of replacing an old ECM system is the amount of integrations to/from other systems. Most of these systems are typically data driven solutions.  Consider an integration at the browser level or a push/pull process behind the firewall to lighten the load on integration requirements while not forcing an integrations with the cloud infrastructure.

By reducing the initial implementations reliance on networking and internal security, the ECM roadmap can focus on getting through the first new application rather than be delayed by infrastructure and security concerns.

ECM Roadmap –Picking your platform, components and services partner

Once the IaaS vendor or on premise strategy is determined, we would recommend picking the ECM vendor that works best with your chosen infrastructure components.  Key to the decision process will be determining not only the vendor that works best with your chosen infrastructure, but also the long-term capabilities of the vendor.  Picking a platform can be very difficult.  Some practices to avoid:

• Placing too much faith in the analysts – Too often clients can fall into the trap of following Gartner or Forrester in regards to deciding what platform will be the winner in the future. With ECM a mature industry, many of the vendors are coasting on their install base and not innovating.  Analyst firms tend to recommend based on market share, not growth.  See our thoughts on Gartner’s Magic Quadrant from last year.
• Vendors and IaaS – be careful of “we work with them” versus “we could work with them”. When asking ECM vendors about IaaS, many would say they could work with any IaaS infrastructure.  See our thoughts about Documentum on Amazon Web Services – while it is possible, it is not an approach Documentum supports as they have significant relationship with VMS from the EMC days as well as a new cloud offering with OpenText.  While a product might be able to be run on the IaaS, customers should be asking “how many clients do you have?” to make sure the vendor is supportable.  In many cases like IBM, Documentum and OpenText, the companies own cloud offering can get in the way of supporting other IaaS vendors.
• Placing too much time on features and functions – Too often clients bring out the laundry list of capabilities. Vendors will answer Yes or Soon and it makes it hard to rate.  Try to avoid the “we could do that” answers to the “we are doing that right now”.  With the maturity of the ECM market, most of the different solutions can handle most of the requirements.  Focus on an evaluation of the vendors focus and plans (to be) rather than their current market share and size.
• Placing too much emphasis on the ECM suite – similar to features and functions, we would recommend against too much value on trying to pick one vendor for all components. With the consolidation of the industry, many of the components, while owned by the same vendor (OpenText or IBM seem to be dominating) aren’t always the best choice.  See our article “Is an ECM Suite really that Sweet?”
• Pick and objective services partner – Too often, clients want a one stop shop for ECM software and the consulting services to implement those solutions. As a rule, consultants from software firms are not always objective when it comes to recommending solutions and often don’t have the breadth of knowledge to think “outside” the vendors products.

Good vendors should naturally fit together.   In evaluating vendors, whether they be ECM vendors, components or a services partner, try to analyze not only what they are doing now but how they will be able to be a true long-term partner in the success of the ECM platform.    Some general rules:

• Smaller focused vendors tend to be better than large, often times distracted vendors
• The services partner is more important than the product – when we get invited into an ECM implementation that failed, 9 out of 10 times it had more to do with the services partner than the technology.
• Brand new vendors can be risky (will they survive?) whereas legacy vendors can be living off their maintenance stream and not innovating. Key is finding vendors that fit the “just right” mix of stability and growth without the impact of legacy.

Thoughts on the different ECM Vendors

Full disclosure – TSG is pretty biased toward Alfresco as a modern ECM platform.  Alfresco does the best job of leveraging open source, working with the leading IaaS providers, particularly Amazon and seems to hit that “just right” mix of new and innovative while having been around for over 10 years so no concern about long-term viability.

While we mentioned Gartner and Forester, we thought we would share our latest thoughts on the different vendors and our concerns on some of the other vendors thinking about an ECM roadmap.

• IBM – In talking with others at the Document Strategy event, most of us thought IBM seems distracted with a massive Watson marketing push and the Box relationship. With the combination of what used to be DB2 Content Manager and then the multiple versions of FileNet, we are not sure they are really focused on ECM.  Word that the ECM tools are not under the Watson/Analytic group doesn’t help IBM’s ECM focus.
• OpenText/Documentum – Lots of concern about where the merger will take the combined companies. News of continued defections from Documentum as well as interfaces and a platform that even Documentum announced they weren’t investing in anymore before the merger has clients concerned.
• Highland – Has always been a niche player in the ECM space with mostly a focus on Health Care.
• Oracle – We have been doing a couple of Stellant migrations. Oracle seems to be a vendor that isn’t really focused on ECM.
• Microsoft – definitely making progress with Office 365 after SharePoint 2010. We see it more as a collaboration approach and extension of Office rather than true ECM.

Clients should look at their respective industry to line up which vendor platform seems to be winning in their industry.  We typically see IBM in financial services.  We see Documentum with some financial services, pharmaceuticals and utilities.  OpenText often combined with SAP across industries but heavily in manufacturing or generic ERP.  Highland within Hospitals and Healthcare.  Alfresco plays more of a platform with more cross industry clients but making progress in Financial Services – particularly insurance – manufacturing, government and non for profits.

ECM Roadmap – Who goes first – Consider Small and/or External

Often times a key factor in the success of a new ECM roadmap will be determined by the first application or business use.  We typically recommend that clients to consider either a “non-critical” component that can quickly show off the benefits of the system without introducing the risk of a critical component or a new use case that leverages the cloud/external access.

In looking for that first application, some factors include:

• Small is better than Big – ECM implementations can suffer when the first one isn’t viewed as successful. Picking a small, low risk approach can get momentum going in the right direction without the risk of a “big-bang” implementation.
• Excited Users are better than disgruntled – Introducing a new platform can be a big change to the users. Having users excited about the new capabilities (performance, functions, interface design) will help push support for the first and subsequent applications.
• A small migration better than big migration – more on this later but we have seen substantial reduction in risk by pushing for rolling or small migrations to allow for pilot groups.
• Content Management is easier than Workflow – we talk to clients about this often but workflow solutions require everyone’s buy-in whereas content management can be successful with just a few key users. We typically recommend implementing workflow once the content management components have been successfully embraced.

With the focus on minimizing risk, a successful roadmap will gradually add additional users and applications overtime to avoid the impact and risk of a large change.

ECM Roadmap – Migration – Plan – Practice – Plan – Practice

See our thoughts around best practices for migration as well as a Webinar we did with Alfresco, but key to migration is planning practicing.  Our recommendations:

1. Start Planning Early
2. Take inventory of all objects in the source system
3. Use migration as opportunity to “clean house”
4. Use the migration as an opportunity to “reorganize the house”
5. Take the time to perform benchmark testing during the planning phase
6. Identify and address migration performance bottlenecks
7. Break the migration down into manageable batches
8. Have a migration verification plan
9. Allow enough time to handle migration anomalies and failures
10. Plan to perform delta migrations

Some of the easy things to do during the migration phase include moving content to new formats (converting legacy TIFF images to PDF is a common example) as well as creating a better taxonomy and security paradigm.

Another item to consider during migration planning is a strategy for when to actually migrate the documents.  For clients with a relatively low number of documents, an all at once migration may be suitable.  However, for some clients that need to migrate many millions or even billions of documents, an all at once “big bang” migration may not be practical.  For these clients, we recommend a “rolling migration” approach where documents are moved from the old system to the new on an as needed, on demand basis.  Again – see our a Webinar we did with Alfresco for examples of a rolling migration approach along with other approaches.

ECM Roadmap – Remember Integrations

Establishing a successful ECM Roadmap must also include the vision and plan for integrations to other systems.  Typical legacy ECM systems have had integrations either built into the ECM interface or a back-end process that isn’t always forward thinking.

Successful roadmaps consider the options for integration to other systems with the idea that either the ECM system or integrated system might change over time.  Some best practices include:

• Loose rather than tight integration – for example, to integrate the source system and the document viewing interface, have the source system call the ECM system with a browser link and pass over information. This makes the integration easier to support and extend to other source systems.
• Build integration with common tools rather than custom tools promotes consistency across integrations. Typically TSG will build out file transfer tools with OpenMigrate to avoid adding custom integration points.

Summary

Building an ECM roadmap involves building an understanding of where the ECM systems are today and a vision for the future.  Keys to this process begin with infrastructure components and planning for how they combine with the ECM vendor.  Don’t underestimate the importance of choosing a great implementation partner.  Finally, avoid the ‘big bang’ and plan to move in small, manageable chunks.  Look for creative ways to gradually roll out solutions with a small subset of users/documents as well as a rolling migration approach to avoid a high risk big bang approach.

Let us know your thoughts or best practices below.