The ECM App And the Turtle

Four years ago, I was a member of a consulting team who was trying to pitch their services to a large Pharma in New Jersey. It was for a clinical trial Institutional Review Board (IRB) solution. We had designed and developed a Webtop application based on compliance manager (Taskspace was still too buggy at the time to show). Our audience was a mixture of IT managers, architects, and one lower level business representative responsible for clinical trial coordination.

We were not prepared. We did not understand the requirements for an IRB. The first thing that our audience brought up was that they did not want to sit through any more basic Webtop or Compliance Manager demos. They had just seem an IBM demo which focused on the IRB functionality and proposed solution. All my work was out the window.

This was four years ago. Even now EMC Documentum does not have a core product to solve the IRB communication and content management issues. Why is this? I know consultants have created one-offs to this, but don’t these “xCelerate” into Documentum’s core offerings? Slide decks only go so far. Dog and Pony shows wow the first time. Real solutions which are designed from the users themselves are not getting recognized. They are being coopted by smart and motivated users who have tech savvy connections.

ECM applications in general have the base of offerings which give them a few year of advantage. For example, there’s an open source clinical trial solution which touts the ability to create and manage users and security, and control the UI configuration. This product has been improved over the past four years, but the point is at its inception, an ECM application could have been built on top of its core products which easily surpassed the open source and grabbed market share. Are ECM apps that hard to innovate? 

Do Partners Use DCTM products In-house?

So why is it that most Documentum professionals do not use Documentum products to manage their own content? Wouldn’t you think using the products that they tout as superior for their own use would be a no brainer? Even EMC doesn’t exclusively use its own software for content management! What’s the deal?

If we can understand the reasons why, then we might be able to figure out some core issues with the product suite. Using only DCTM software should be requirement to becoming an EMC/Documentum partner, but isn’t. What’s wrong with this picture?

Time is money

It takes “non-billable” time to build out the infrastructure, install the content server, application server, applications, then to configure the applications, users, roles, security, and so on. Management of partner resources is based on greed, not product enhancement. The focus is on exacting value from client’s basic content management needs, not leap frogging the product flaws, by building great products.

No Rules, no need

If partners and consultants had strict rules and were regulated, they would think twice about not using DCTM products. They would weigh the options of not using DCTM and realize that maybe compiling to its inherent rules in not a bad idea.

The carpenter’s house

Like a carpenter’s roof, consultants are notorious for not taking care of their own back yards in terms of using the tools and knowledge to fix things where they live. They build palaces for clients and come home to trashy trailers.

Sharepoint

The configuration and ease of use of Sharepoint is a huge and obvious issue. But do consultants create an uproar about this? Not really, most build both solutions and some have even switched to all SP. This is sad.

Share drive comfort

The share drive mentality is still strong in most companies. Why switch if the options are not compelling enough? For records retention just hold onto the content 8 years from when it was last modified. Done.

xCelerators

There is hope with the xCelerator movement that Documentum might be trying to focus on a few right things. One is stressing the “product” on top of the product for solving specific vertical business problems. But you can only go so fast in a Maserati when the road is curving and has cracks.

Conclusion

It’s time to consolidate the product talent and build a completely new stack (not 7.0: 1.0 again, this time leapfroggin). This stack should revolutionize the creation and management of content. Make the partnerships with other companies, use the cash reserves, get in the game!

D2: "Reality Distortion Field"

Having read Steve Job's biography and how he applied his "reality distortion field" wherever and whenever needed, I started thinking about Documentum's D2 purchase. What is the purpose of this new, "easily configurable" UI? Isn't just trying to divert attention away from the fact that Documentum has not been able to revolutionize the ECM market the way it could?

The core content server is still there. But, because Webtop was out for so long, most large companies with complex requirements have customized that hell out of it. When xCP came along the message was "case management" which had most developers scratching their heads? They were trying to figure out how to go from Webtop to TaskSpace. Ok, they finally worked that out, but didn't implement it. Then D2 comes out with a wink and nod saying it's easy to configure and don't worry about your Business Object Frameworks (TBOs and SBO), they will work. Ok, prove it!

Here's where the reality distortion comes in: what EMC needs is a flexible, change oriented layer for businesses and creatives to build vertically focused products. Yeah, EMC wants partners to certify their solutions and call them products, but I'm talking about a platform that blows away Microsoft's Sharepoint, which is just a web version of file sharing at it's core anyways.

So, what's it going to be, a distortion field or a completely new product from the ground up? I'm sure it is part of the reason that Newton left Documentum to build Alfresco. EMC has a window of opportunity, will they take it? 

From Form and Process to xCP

Inherent in a form, paper or electronic, are the fundamental components of an xCP application. The following are some of the possible components:

Goals

• What is the overall intent of the form?
• What will it to ultimately accomplish?
• Is the form one step in a multistep process?
• Is the form meant to automate a previously labor intensive activity?

Requirements

• Each field has a purpose toward the goals of the form. 
• Who is sending it? 
• What is it for? 
• When is it due? 
• How will you know it has been received? 

Validation

• When a field has a format or regular expression sometimes this will be explicitly stated, other times the recipient (or system) will be responsible for validating the values of the form. 
• Who will verify the vales of the form 
• What will happen if it is rejected? 

Security

• Who sees this form? 
• How is the sign off validated? 
• Who has the clearance to complete the goals of the form. 

Approval

• Are there required signatures? 
• Who signs off on the form? 
• When did they sign it? 

Activities

• Is there an assumed process in the form, for example, are there directions on what to do with it? 
• Is there a recipient of the form?

Process

The tasks of what gets done with a form should be documented and explained in detail.

• What event initiates the form?
• Who initiates it?
• When does the form typically get filled out?
• How is the form validated?
• How are the fields on the form used and stored?
• Who approves the form and what do they do with it?
• How does the initiator know that the form has been approved?

Exceptions

All processes have exceptions to the general flow of the work. The challenge is to start with enough comprehension in the workflow to automate the most important steps, thus allowing for superior human intervention occur in between. Chunk the process up enough to help people do their work easier, not to impede them. Many times I’ve seen large workflows which become the bane of an office worker’s day.

xCP

So you have the form that needs to be automated, the inherent process which is verified by talking with people who fill it out and who process it, and you know the pieces of xCP:

• Forms Builder: create the form with fields, security, and validation
• Process Builder: build each activity of the workflow, map the field data, route the form to the reviewers/approvers, complete the work of the form.
• TaskSpace: create an app, add the forms and workflows, create roles for the users of the application, build out the tabs and add forms to them, assign tabs to the roles and how the application will look to each role.

Plan out the application with each component in mind and how they work together. xCP is nothing new taken separately, but combined is a power tool which in many companies is taken for granted.

Is your ECM Portfolio Management in a Rut?

I recently had the opportunity to meet with a client that had implemented Documentum Webtop 4 years ago. I was part of that implementation. It was like being in a time warp to return after 4 years to see that really no further expansion of the initial roll out had occurred save for adding on lots more object types. This is an obvious sign that a painful gap exists between what the business wants and what IT delivers. Just tossing in a content management system will not fix issues of communication and lack of persistence.

Like the truck in the photo, Portfolio Management is stuck in a rut. It may not even exist. Here are some of the pain points of everyday users take for granted:

• Not being able to find what they know is in the repository.
• Wanting to be alerted when a certain document is approved and meets certain key/value criteria: this is a tell tale sign of lack of workflows which would organize and alert groups and individuals as documents are approved.
• Harboring grievances with DCTM interfaces and tools for years to no avail.

It is easy to blame the content management system for all the woes of just trying to get your work done, but most of the time the blame is on the company's lack of process around listening to what the business wants, how they work, when, with whom, etc. Listening comes first, then documenting, budgeting per business unit (not through IT), managing this portfolio, and, at the end, having IT get it done. Many mid-sized companies do not put too much emphasis on IT portfolio management, let alone content management. Thus if issues arise with content management, IT is blamed, not the breakdown of portfolio management.

The need for dedicated IT business analysts

What happens when business units have a phobia of workflow automation? Nothing, unless IT has a strong business analyst who works with the business to figure out the best ways to automate their headache routines, to detail content and approval processes, to advocate for the business with an eye to the reality of what IT can get done.

Lacking representative governance

Centralized governance for detailing and prioritizing content management projects is key to the success of ECM. The group can not be run by IT as they will bulldoze through projects according to the last technology conference they went to. Business goals and requirements must be the drivers of the projects and priorities.

Technical Architects and CYA

If you are lucky enough to have an IT Architect, hopefully he/she can communicate to both the business needs and technical aspects of them. Many company put IT and architects on a pedestal, which causes conflict if there is a "we and they" environment. If there is a "Cover Your Ass" attitude that usually means that a good chunk of productivity is lost to long winded emails and in battles among IT and between the business and IT. If there's CYA going on, then there's portfolio management dysfunction.

A Road Map to Health

An ECM roadmap, which shows high level goals and detailed ways to get there, is needed for the restoration of trust and communication between what the business wants and what IT delivers. This roadmap should be developed jointly between the governance group and IT with architects and business analyst in the room. If there is a person doing too much talking or pushing around, gently ask him/her to respect the needs of everyone. Having an outside study done would be a disaster and is usually sponsored by individuals who have an agenda that may not be good for governance and portfolio management as a whole.

D2 built on ruins

The "new" D2 client from Documentum is similar to how the Native Americans of Chaco Culture built their pueblos on the ruins of previous structures. EMC seems to like to reinvent the UI wheel every few years. To make our day to day lives a little easier. D2 is their latest attempt to make the UI configurable, flexible, and relevant to today's expectations in client software.

Chaco Culture: Pueblo Bonito

I am not going to dive into the improvements of D2. Let's just say there are many and it's about time. What I will say is that, like Sharepoint, D2 represents a progressive layer of understanding of how users use software to store, describe, and use content. It's another step up the ladder of awareness and better technology to get the tools into the hands of the users who need them.

Will D2 leapfrog Sharepoint as the slick configurator of content management UIs? I doubt it, but it will eventually help with migrations and maintaining consistency with platform upgrades, assuming that it is well tested. This is a big assumption. Speaking of migrations: there's a lot of work to be done moving WDK to D2. All of those customizations out there, all of the tireless hours of converting TBOs...

So the question is do existing customers leap to D2 or do they hold onto their WDK foundations until the last supported release is a year old? If the customer is an old timer (more than 5 years with DCTM) chances are good they will analyze the cost of migrating to D2 vs. another CMS. The leap may be too much to make. It might be cheaper to migrate to open source or another CMS, or DCTM 7.0 might be a must have. I'm hoping for the latter.

Upgrade to More Simple and Other ECM Trends

This image is from www.stickfiguresimple.com

Churn = Change in ECM
In general, IT and business stakeholder churn influences the evolution of ECM systems. As business units become more savvy as to what can be done for free in the public domain (ie, Facebook), they demand the same for proprietary software. For example, Documentum burned through a number of costly search engine deals before settling on open source Lucene. On the flip side, the business is preferring Sharepoint for its ease of use.

CIO Revolving Door
In the middle is IT, contracting development of custom ECM tools and integrations, pushing for automation (without a clue as the intricacies of the business processes--usually), thus burning its bridges within their own companies. Then the CIO leaves or is fired. The new CIO "knows" how to deal with the issues (Laughing at the CIO) which changes the information architecture stack under the guise of innovation or an inflection point.

More Simple Configuration
Microsoft Sharepoint started the trend towards simplification by copying everything that was out there at the time and being smart about configuration. To counteract this trend, OpenText is hopelessly behind and Documentum bought D2 to leapfrog toward Sharepoint. This direction will lead to more emphasis on change management as companies realize how disorganized their content is. Like Sharepoint sites gone wild, enterprise content has been built business unit by business unit, even if it was centralized. Simple configuration will mean more consistent rules and policies around metadata and taxonomy.

Consistency = Lower Costs
Consistency will help all ECM systems simplify their compliance efforts. Records managers will have to streamline their complexity, lawyers will get better at mandating search and destroy rules in order to avoid potential lawsuits, and IT will take one more step back in terms of their influence in providing information technology direction.

Leaner IT
IT departments will basically become shells of what they were. Technical architects will be specialized based on industry. Outsourcing will turn into product development, not customization. Information Architecture will take on a new, more important role as the roles of the IT Director will diminish.

Secure Knowledge for $$$
This is a long shot, but we'll see: When a generic UI for information architecture and content is created--a Facebook for Content--more focus will be on security and monetizing a company's content and knowledge. Sharing information for bucks will happen, however the stealing of information, ideas, and software will have to be dealt with. As a publicly owned Facebook is required to grow its investor's money it will buy other content and knowledge from outside sources. As ECM system owners realize that the content they have and the analysis that they learn from it could be just as valuable as their core business, they will partner up with the likes of Google or Facebook for this new revenue generator.