Next Generation ECMS – Architecture Thoughts

We responded this week to a Documentum Pharma customer that, like many of our legacy ECM customers, is looking at what could be next for ECM and is particularly focused on systems architecture.  In prepping for the response, we thought it would make a good post to share with other readers and would tie well in regards to follow-up for both our 2015 ECM predictions as well as our current series on Hadoop.

ECMS – Overview of Functional Building Blocks

Our client was looking for feedback on specific areas including:

• System Access Points – ex: Browser, Mobile, Internal/External Users
• Integration points with other systems and technologies

Specific areas of interest included:

• Access Layer
• Core System
• System Integration
• Deployment Models
• Hosted or Cloud Models
• Other

This post will dive into each of those areas above to provide our thoughts on ECM approaches.

ECMS – Access Layer

In our approach, we typically focus clients to consider a REST-based Web Services approach to provide all access to the repository.  In this manner, all types of integration are possible.  Many clients struggle with a vendor specific solutions or trying to implement a standard (CMIS).  Many of our innovative clients have chosen the REST-based web services approach, either building it themselves or leveraging our product, OpenContent.   We like the “build your own web service” approach as in our experience (see related Documentum DFS post ), vendor support of products or open standards don’t always give clients the flexibility they can get in their own implementation.

Some specific points on the access layer we discussed:

• Seamless Access from anywhere with authentication – we typically see LDAP or other standard security to control access. Clients are implementing in the Cloud more often (or a Hybrid Cloud) to avoid excess firewall and other security complexities.
• External Access – Links and other access are via the REST Web Service layer with appropriate security. We often build a specific integration point for clients – see OpenContentURL.
• Strategic Partnerships – Third parties should be able to access the repository with appropriate security. Many times clients limit third part access/capabilities to specific content, lifecycle requirements and allow for changes over time.  For one third party access application for a Clinical Research Organization (CRO), we limit access to documents participating in a workflow  (with no search or browse) to allow only specific access to documents when needed for review/signature.
• Mobility – As we mentioned in our 2015 ECM Predictions post  – we see mobility moving away from client specific applications and more to HTML5.  This is similar to how our ECM solutions, given technology and bandwidth improvements, moved from client/server in the 1990s to browser based in the 2000s.
• Rich Client or 3^rd Party Plugins – Clients, particularly Documentum Webtop clients, have struggled with the Java-based UCF component that relies on a Java Applet for upload/download. See post from EMC World/Momentum 2012 where the audience actually booed the announcement that a Java Applet would be included in D2.  TSG has embraced a “zero footprint” focus on client machines as clients have struggled with supporting Java Applets/ActiveX/Flash across a wide diversity of access points.  OpenAnnotate is completely JS/HTML5 based and our latest update to the Active Wizard will remove Flash to go completely JS/HTML5 on modern browsers (ex:  Chrome, FireFox, Safari and IE9+).

The Zero footprint approach does come with some user compromise consideration.  Typical examples:

• Check-Out/Check-In – Without a browser plugin, browser security disallows the ability to place or retrieve a document from a specific location on the user’s machine. See an example from HPI check-out and in here.  Experienced ECM customers recognize the benefits from a support perspective.  Without a rich client, the user will both have to place the file (Save As) as well as identify the check-in file (Browse or drag and drop) with standard browsers.  HPI has taken the approach to only require file activities for check-in and out as most documents are displayed in the browser using a PDF rendition.
• Outlook Integration – Clients typically struggle with plug-ins to components like Outlook and maintaining both those plugins as well as a browser based application. A compromise is to do a “two-step” ingestion from Outlook to a browser-based ECM application as demonstrated in this screencam.

Other points discussed in the Access Layer included:

• Data Communication – compression or optimization – Typically we haven’t really seen our typical ECM tool leverage any. Looking forward to Hadoop as access points can be optimized with the replicated content being retrieved from the closest node.
• Off-Line Support – Most of the new clients focus on a check-out to edit mode with ability to check back in (user initiated) when done for off-line work. Supporting a model that provides for multiple offline updates with conflict resolution is something clients have avoided.

One point not discussed we typically like to see evaluated here is development environments.  Going hand and hand with API access, many vendors will provide a development environment, typically leveraging the underlying API.  We tend to recommend more of the Alfresco approach where API access is from a variety of innovative open environments rather than the Documentum approach were the API is buried under a proprietary development environment.

ECMS – Core System

Some focused questions included:

• Configuration – More and more solutions are focused on a configuration approach rather than custom development. Clients, particularly Documentum Webtop or xCP, have been very frustrated by customizing components only to have to redo those components with every upgrade.  Our solutions, including Active Wizard and HPI  have always allowed for configuration with more and more options coming available as demonstrated here.
• Search Performance – More and more, solutions like Documentum, Alfresco and our upcoming Hadoop offering leverage Apache Solr for quick and efficient search. Legacy implementations were tied to the database model requiring tuning and some difficult integration for full-text capabilities.  Solr gives clients and efficient way to search content in the repository with no management as well as external environment cache as mentioned in this post.    In thinking about Search performance, response time is one factor but, when considering user interfaces, making the user successful with robust ways to search easily with minimal training is almost more important.
• Rendition Performance – This client, like most Pharma clients, heavily relies on PDF for Review/Approval/Viewing. Turning a document into PDF is a key component.  We found Alfresco somewhat better than Documentum in that Alfresco implements more of a “real-time” rendition versus a queuing architecture of Documentum carried over from the AutoRender days.  We look for more improvement in this area, particularly in regards to high-fidelity renditions.
• Bulk Operations (Upload, Download) Performance – within our OpenMigrate practice, we leverage the ability to provide a threaded approach along with Delta Migrations as the best way to improve throughput on Bulk activities.
• Reporting and Querying – More and more clients want the ability to create a query/search as a way of adhoc reporting. Ability to quickly define search, save search and create output to excel is an easy way of adding robust user defined reporting.

ECMS – System Integration

This one was slightly harder as the client was looking for system integration “out of the box”.  Some thoughts:

• Publishing – We have worked with many clients that have decided to “publish” content from the ECM system to be consumed by other systems. This ties well to the idea that, for most clients, 70% of the users are consumers or read-only.  Pushing approved/released content to other repositories, web sites or file systems is something we do often with OpenMigrate.  OpenMigrate can be configured to allow for “synch” in making sure that both repositories stay up to date.
• Client Level Integration – Clients have struggled with specific integration points as keeping the connectivity to different versions of software (MS Word, AutoCad) can be difficult to support. Alfresco and Documentum both have integration capabilities for standard office products with partners providing additional supported platforms.  As a low-end capabilities, some clients look for WebDAV to allow the ECM system to just map a drive to allow for client access and version on every save.  We tend to stay away from those solutions when possible as putting rules into place for indexing/lifecycle and security are better controlled by a full client – typically on a browser.
• System Integration – We typically recommend systems integration in two ways. Either the content is pushed into the other system (see publishing above) or the other system can access the API to access the content.  One note of caution, some Documentum clients have chosen to leverage the Documentum r_object_id for connectivity between the two systems as it provides the fastest access.  See our post regarding long-term r_object_id issues particularly when upgrading or migrating to new Documentum instances.

Deployment Models – Hosted or Cloud Models

Most ECM systems now provide both on-premise, cloud or hybrid cloud implementations.  This particular client was looking for GMP (Good Manufacturing Practices) in support of a validated system.  While validation requirements vary from client to client, TSG has successfully deployed GMP systems in both Alfresco and Documentum with a variety of different solutions.

One topic that was brought up was in regards to migration being required for major updates.  This can be a touchy topic with Documentum clients as clients on either Wetop, DCM or FirstDocs would require a migration to move to the new D2 solution given changes in the document taxonomy required by D2.  Solutions that TSG implement, including Cara, typically do not have that same requirement.  Depending on the client’s solution, we will sometimes recommend a migration versus an upgrade in place in order to clean up the underlying data model or content.

Other – Viewers, 3^rd party vendors

This was an interesting discussion as the concept of “what viewers does your solution provide” seemed to be the core question.  Some quick thoughts

• TSG products typically rely on converting/rendering all printable objects into PDF and viewing either with Viewer.js or streamed to the browser directly (typically Chrome PDF Viewer or Adobe Reader). We have found that approach provides the cleanest support/installation capabilities for our clients.
• Other file types – Video, Audio – we typically rely on either Video.js or the browser’s native controls to handle the viewing.
• Desktop – if required to edit (ex Word), our approach has been to launch the native product on the desktop. Typically we will allow the user to view the document in PDF before initiating the download/launch.

Thoughts on ECM Architecture and Vendor Evaluations Overall – Focus on Current and Future

The toughest part of any product of vendor evaluation is focus on “what the product does now” versus where will the product be going in the future.  Too often we see clients struggle with a checklist approach (this feature versus that feature) to try to turn the vendor evaluation into a math exercise.  As many clients have found out over time, a checklist evaluation can miss critical success components over the long term.  Futures can be difficult to evaluate as, during a sales discussion the answer of “we are planning to do….” doesn’t always set a clear roadmap.  Some points to consider:

• Client Relationships – What is the vendor relationship like? Is the ECM vendor a true partner where they are working to shape the product(s) to better meet our needs after we have purchased or do they tend to always be just selling us more?  Software vendors tend to struggle as they always can be looking for growth areas rather than focusing on their current clients.
• Innovation – How quickly does the vendor adopt new standards and technologies? As an example of Documentum versus Alfresco, Alfresco’s leadership with CMIS and Lucene/Solr integration was years ahead of Documentum.
• Product Development Consistency – One issue of particular concern for Documentum clients has been consistency in regards to client software. Clients purchase and pay maintenance for licenses of products that don’t evolve.  For our Pharma clients, products that haven’t been maintained or improved over time have included DCM, Webtop and FirstDocs as Documentum moves to D2 and xCP.   Clients should look for a history of consistency in licensing and product development.
• Partner Relationships – What is the relationship of the vendor with their partners? Does the vendor have productive relationships that are win-win or are partners just resellers?  Do the partners develop robust offerings and co-promote the vendor products?

All of the above are great evaluation points to considering both ECM vendors as well as consulting partners.  Let me know your thoughts on other points to consider below.