ECM: The Perfect Storm for Business and IT

The blizzard of ’78 conjures feelings of helplessness and anticipation of the thaw. Everyone knew it was coming and yet they went to work anyways which meant lots of folks were caught on highways and airports. The lack of communication as to the severity of the storm was obvious in hindsight. Likewise, with ECM, the lack of governance and communication usually culminates into a perfect storm of control and blame between the business and IT.

With so much marketing information on “best practice” solutions to legal holds, records management, learning management, business process management, etc., it’s easy for individual business units to fall in love with a solution before IT even knows about it. Good governance would never allow this wild west atmosphere, but growing companies are usually governance challenged. A chronic lack of IT resources over time creates easy ways for business units to push their own tools to innovate in areas the IT does not “understand”.

All this back and forth with whining on both the business and IT sides leaves an easy scapegoat: the ECM solution. It becomes easy for the business to exclaim, “The UI is so 1990’s”, or “I can’t find anything”, or “We don’t know what to delete so we keep everything”. Then IT chimes in, “It will take us over a year to upgrade!”, and “Why can’t we just use SharePoint, it’s free!”, or “We don’t have any functional specs, so what does the business expect?”.

The middle ground where the requirements meet software functionality and architecture is where the weak link sometimes is. This link is where the projects are vetted, resourced, and funded. The problem is that this middle ground is stuck between being not too business experienced and not too technical. The middle ground is constantly changing, but can be called portfolio management or business relations. If governance is not at the enterprise level for content management, then project priorities and resources are constantly stressed and projects fail.

Storm Formation

Sales professionals with hidden agendas sell the business on slick demos and solution X.0 capabilities. The business goes to conferences and comes back psyched to use the latest tools, only to find the dull, boring ECM solution in place. The business writes up requirements and gives them to their portfolio manager. The project doesn’t get approved. A year later the business pleads with their boss’s boss. The boss’s boss talks to upper management in IT and a pilot project is born.

History vs. Change
ECM Directors have with hidden agendas too. They have relationships with vendors, they know the software functionality. They are comfortable being experts with the system. They want to ride it out as long as possible. Change is too risky and fraught with functional gaps which the business won’t like, but meanwhile the business is secretly hoping for a new system. The license agreement has not expired and the cost to migrate is huge. There are always many reasons not to change if your vision is one to two years out.

Storm Aftermath
The period after the big storm affords some down time; hindsight to revisit any failures or damages sustained. Standards and rules have a chance to be implemented because there should be opportunists who understand architecture and governance who can exclaim, “I have a way out of this mess”. A new CIO is usually hired and new models are sold to IT. The new models promote ties with requirements and functions, budgets and accomplishments, and business to IT communication. The ECM system will most likely morph into something that is more suitable to the requirements, maybe a new application server (Sharepoint) or focusing the “E” of ECM to a system which archives and manages retention.

Open Text 2010 Sets Up Defensive Services

Open Text’s marketing of their new 2010 ECM suite and share services points to four distinct areas of focus: Lifecycle, Process/Transaction, Engagement, and Shared Services. Looking at these stacks, it is clear that OT’s has set up them up to deal SharePoint’s strengths and weaknesses. The Library services layer would have been revolutionary 10 years ago, now it’s just another ECM suite trying to be the archive and retention layer in an enterprise.

Also the initial release of ECM 2010 is for Windows 2008 R2 64bit until the 32bit is available. If this isn’t a concession to Microsoft, I’m not sure what is. Oracle gets a boost too with the 11g requirement.

“Management content and metadata in a consistent manner” is such a cliche at this point.

Lifecycle (“strong” hold): these are all set to be broken out as services.

• Document Management – lots of potential here, but each of these need to be services…
• Records Management – classification layer on top of document classes. One of the biggest potential services that could be developed, but currently is very embedded in the core CS product.
• Rights Management – a service which is used to encrypt/decrypt content.
• Digital Asset Management – “I want you tube”
• Archiving – this needed to be highlighted a long time ago. Flexible storage allocation was huge before EMC bought Documentum. Now everyone is following their lead.

Process/Transaction (decoupled service from content server for enterprise implementation)

• Business Process Management – separated from the core content server, this service is offered as a single instance which will integrate with many other repository services, including the content server.
• Capture and Imaging – This is separated out as well with connectors to repositories.

Engagement (up for grabs, here you go SharePoint, please don’t take anything more…)

• Collaboration: is this a joke?
• Social Media: right?
• Web Content Management: hmm, I don’t think so.
• Rich Media Management: If I have too.
• Mobility: get in line.

Shared Services

• Library Services (too little, too late)
  ECM suite, SAP, SharePoint, File system, Email system
• Enterprise Process Services – BPM above
  
  

So what would be a better alignment of services to appeal to experienced and frustrated folks? How about tossing out the authoring and collaborating side until Microsoft succumbs to Open Source formats and focusing on tagging, classifying, and storing information. In other words, focus on where the current pain points are which are not at the document level anymore, they are at the information architecture level and SOA projects are all custom after the designing part is done. Hmm, maybe Open Text can open itself up to services that really help information get organized instead of trying to compete with Microsoft in collaboration or publishing to website…

What happens when ECM is renamed to DMS?

When IT governance, steering committee, or strategy team renames a whole IT group from ECM to DMS (document management system) it is no small change. This change has many ramifications: changes to application software, data architecture, integrations, requirements, functionality, etc. A divide and conquer rationalization is presented. A “let’s look at all requirements from the stand point of: do we really need this?” Ok, but it’s not that easy.

What is lost?
Talent: it takes time to dismantle an ECM system into to smaller, more focused parts and personnel with attention deficit disorder will get antsy and want to jump ship.
Sense of cohesiveness in the lifecycle of content creation through disposition: application silos will start to appear.
Unlimited playground for the business to experiment in: the business will have more work to do to figure out what they really want to do and get measured by it.
Central administration of users and groups, access control, attributes, taxonomy, retention schedules, search, backup.
Source of record: How do you keep track of and archive content that need is mission critical and could be audited many years hence?

What is gained?
Broader understanding of the content lifecycle: because of more integration requirements, the business will have to know exactly where their content lives and is dispose of.
Divide and conquer mentality: separate groups tackling the tough business communication issues.
Better governance: now the strategy of cohesiveness of all the desperate applications will
Better data architecture
Better standards definitions and adherence: assuming there are strong governance and data architecture, standards should thrive and push integrations to new heights.
A distributed system which reduces the “too big to fail” issues of a centralized repository system.

Recycling the Same Issues
To what extent are we recycling the same content architecture, management, and publishing issues? Collaboration issues will be deferred to SharePoint, workflow will be spread among all of the applications, archiving will further muddled, group access control will be splintered further, regulation paper work will increase by the new amount of applications.

Content and Information Architecture Design
I have hope that this will be the golden age of the content architecture frameworks, that we will witness true policies which are governed by blueprints which can withstand the issues of silos of information, de-normalized data, historical metadata and the like. The framework would have to be malleable, yet strong. It would have to be clear and forward thinking to lay the ground work for all content and information evolution to come. Ok, I can dream can’t I?