ECM Framework Equals Aligned Goals

All organizations need an ECM architectural framework in order to move in unison toward common goals. I know all about the phased, lumbering approach of ECM deployments in the enterprise and everyone’s intersecting plans of what to do about it, but I have been through this before a few times and I have to underscore some ideas and questions.

I’m going to use a content management software upgrade as an example shock to the ECM system. My focus is on the results of a lack of clear goals around ECM.

Why use an architecture framework?

Silos of ideas need to be reviewed and galvanized into a commonly understood direction and focus. We all have visions, but are they all in line, fully clued into each other? There are budget forecasts, collaboration strategies, content management strategies, roadmaps of what will be executed and when, top 10 projects, ECM strategic meetings, but is everyone looking at the same picture?

• Budgets show the how many bucks and what quarter.
• Strategies based on Gartner or McKinsey reports overwrite each other.
• Roadmaps show what, who and when.
• But where’s the why and how?
  What are the goals???

For example, at the functional ECM level, how will an upgrade be impacted by SharePoint? What is the anticipated impact of a Usability report, can we start thinking about executing the obvious changes now? Have the mission critical regulation focused groups been frustrated with our services, why aren’t we working with them to implement their submissions to the FDA, shouldn’t this be our number one priority?

Due Diligence in a Vacuum
At the document management level, an upgrade should be done “in place” with limited scope and repositories should be eventually consolidated to save money and centralize control. However, at an ECM level, the approach to the upgrade is magnitudes more complicated and interrelated to other strategic and governance factors.

Ideas and questions around the upgrade and restructuring at an architectural level

• Will consolidation of repositories meet the imperative cultural goals of the company? What is the SLA threshold for upgrading a system? One week of downtime? Zero downtime? Plan for a year or execute in 2 months? Wouldn’t it make sense to isolate mission critical content by business unit and their specific SLA’s for FDA submission, audits, security, etc?
• How does the upgrade fit into a more tactical approach based on commonly understood ECM goals / strategies (framework)? If the long-term vision is to migrate away from LL, then let’s face it strategically. If we thought of ECM in terms of services like business process, records management, FDA submission, publishing, migration, security, library, retention etc., would this help us define our goals?
  
• Should the upgrade methodically move non-regulated content to a parallel upgraded system to free up the rest of the company from the rules and regulations of a validated system? Should we assume that Sharepoint will consume all of projects eventually, and if so, are we being methodical about this?
  
• Should the controlled repository be migrated to another upgraded repository, or should we separate repositories by service, for example, business process management/SOP (current controlled upgraded in place), file share sandbox and portal (new repository), etc.
  
• Should each mission critical business unit have its own repository (within the framework of the ECM stack) to be unencumbered by the goals/governance of other mission critical content of other business units?
  
• At one company I worked at the content, structure, security and business process were consolidated around common business goals and anticipated use: finance, portal, mission critical business units and remote sites each had their own repository with workflows and migration tools for integration between them. If agility in change management is one of our goals this distributed approach should be considered.
  
• What are the primary goals, mission critical drivers of ECM at the Enterprise level, Business Unit, and Service levels?
  

The mere fact that there are so many questions around an upgrade is why you should absolutely consider a framework for change management/deployment of services.

Here are a few among many: Zachman (IBM traditional) and TOGAF (ECM focused and complicated, but comprehensive).

eDiscovery Due Diligence Approach

Requirements, Requirements, Requirements

Define your legal hold requirements, not at a high level, but at very specific level. Create a few scenarios. For example, the chain of custody of a copy of information vs. “frozen” information in context will present itself very differently in court. These requirements, like records management requirements, filter down to all information in the organization. It is worth the effort to understand the intricacies of each existing system and their integrations.

As-Is Systems

Determine what information is needed for the Legal Hold tool to function correctly, for example, assuming identity management is important to discovery then is IDM/AD in good shape? If it isn’t, when will it be? Does the Information Security group have enough resources to deal with this new software?

Inventory the existing information repository vendors to determine if they have eDiscovery add-ons which might be adapted to or used out right. For example, Open Text has an eDiscovery module tailored to its Livelink software.

Integrations

Interaction of the proposed software solution with existing systems is very important. For example, how well does EMC’s solution adapted to Open Text repositories? A few more: Email holds? File system shares? Identity Management?

Tradeshows and Research Analysts Analysis

At tradeshows the players with the deepest pockets are going to wow the audience with all of the bells and whistles. “Yeah, we can do that”, but it’s a customization… Even the demos are usually canned and not real. The reality is that it’s up to your specific requirements. Gartner’s quadrant could be based on a pure play model not an integrated one. I agree with Gartner that solutions are still in their awkward stage, which is more the reason to develop specific requirements.

Search vs. eDiscovery focused

Autonomy is an excellent search tool, however, is it going to integrate well with our other systems specifically around the access control aspects? This could dovetail nicely into an Enterprise Search tool effort…

Security Group Participation

The Information Security group must be an integral part of this whole approach. Without their participation and buy-in from the start, it will be an uphill battle. They will obviously work in tandem with Legal to perform eDiscovery activities. They need to be comfortable with driving their cruiser.

Professional Services after the purchase

I’m not sure of the overall percentage of services vs. software in Legal Hold software, but I’d say it is substantial. Weighing the specific requirements against the software’s out-of-the-box offerings will be worth the effort.