Documentum Talent Revisited

I recently searched google for documentum talent and came across an article from a fellow ECM blog entitled, “Documentum Talent”. The issue I have with this article is that although it is informative, it only scratches the surface in terms of understanding what takes to create true Documentum Architect talent. Java: yes; OO design: absolutely; ECM experience at any level: priceless.

First of all, the tone of the article is conceited and has one of those boss man attitudes which says, “Technically, I know it all, so don’t question what I’m saying. You are kind of a smart guy, but you are all minions to my brilliance, mere duck tape to my superior abilities…” Some architects are arrogant, but most are mere mortals, stuck between a rock and a hard place, trying to please the users and the bean counters.

Ok, whatever the tone, let’s focus on what is missing:

Business Requirements
I’m sorry, but Java and OO design as core to Documentum developers is obvious. If you can’t find this core in a developer, don’t hire them period. What is much harder to find (and more core) is a developer with business requirements gathering experience. Hello, what does the User want? This is why User’s are flocking to Sharepoint, “Talent” as defined here have been too technical and not business savvy enough. They thrive on xml payloads and not enough UI, search, and ease-of-use. Not mentioning “business” or “User” anywhere in his article on Documentum Talent explains the disconnect that has been going on for years between implementation and design. Talent is not knowing webservices only, it is knowing the “why” behind integration needs? Why CMIS has taken so long to emerge. The reasons behind needing to integrate applications are just as enlightening as the technical solutions that make it happen. Business units fund these applications, IT builds them, architects integrate them, but what decisions were made in the past that required two document management apps, for example, or why was Sharepoint introduced?

Knowledge of Competition
Sharepoint didn’t just appear this year to scoop up ECM. It has been around for years, honing its functionality. Taskspace was a joke, it was buying time for Center Stage which was a few years late. Now we have Sharepoint and Alfresco taking business away in circumstances where the EMC licensing contracts are up and the entrenched Documentum Users are fed up. Technology focused architects have helped create this mess. Just make it faster and improve the SLA, the users will be happy…

Long-term, Goal Oriented
Beyond the politics within an organization, how projects are funded, who is technocrat of what services delivery group, lays the long-term vision of the solution at hand. What role does the solution have to the ECM vision in three years? In five years? What are the overarching goals of IT? Knowing how to work with these, question them, and design to them is very hard to find in our technically “superior” architects. Knowing how the historical impact of ECM has influenced the current design and plans for the future. Who is promoting collaboration and why? These are key to talent. In politics, bringing in Sharepoint is the equivalent of promising jobs to your constituents who have been suffering from EMC’s lack of attention to your needs.

Change Management
I’ve seen many Documentum installations that are OOTB with shortsighted object models, security, folder structure, workflows, integrations, etc. These are the result of profit hungry partners smirking as they write their SOWs. Some partners purposely put their blinders on when it comes to scoping their projects. They know full well that as soon as the current project is over the client will be begging for improvements. These partners purposely take shortcuts because they rely on their client signing on for more work. Technically, the project could be architected well, but the human interaction issues with the software may not have been fully addressed, leaving the user scrambling to duck tape their processes to a UI that is too constrained. Knowing when to give the users something for free is a key sign of good talent.

Sharepoint vs. Documentum: Analyst Perspective

It depends on who's perspective you want to take when you compare Sharepoint with Documentum. Every person has a unique take on the Web 2.0, its marketing and hype, but the bottom line is that it is cheaper than proprietary software and can be an open source application that eclipses both MS and EMC. When I think of Sharepoint, I think of projects and ease of use. When I think of Documentum, I think of content lifecycle management.

Resource Delivery Director: wants one solution, centralized with easy configuration. This person is usually religious on a programming language so depending which one .net or Java, this will be part of the decision. This person has pressure to deliver applications balancing this against resource expense.

Architect: wants scale, performance, and integration, plus local developers. This could be a problem for Sharepoint as good developers work for partners, they are not mature enough to contract on their own. Also, good luck out sourcing to India for Sharepoint folks. That will happen, but not yet. Integration and CMIS are also considerations. What apps are integrated, ease of webservice integration, identity management, workflow, etc.

Chief Bean Counter: wants a good ROI story. If a CIO has a preferred technology, she will find/procure a research study which is a proponent of it.

Users: want something that looks different than what they have, but they want everything they had. Do you put a new skin on an old application, or do you buy a whole new app?

Elephant in the Room: Open Source is coming, so EMC and MS are really on the same side here. Alfresco is not going away, neither are the other players. Google might trump everyone once it can’t grow everywhere else, why not tackle the source?

I have witnessed the demo difference between the two platforms and Sharepoint wins hands down. Partners selling these two products are the front line in this discussion. Partners who sell both are selling one short and hedging their bets. Find a partner who sells either EMC or MS and get their pitches, then write the matrix and gap analysis. Also, throw a third party in there for balance.

The main issues you have to matrix are business requirements and the key stake holders. Also, who’s a member of the steering committee.

There Is No Such Thing As "Unstructured" Information

All information, content, documents, chunks have implicit and explicit context and metadata associated with them, therefore they are structure to a certain degree. One of the major issues of keeping tracking and finding content can be solved if the “who” in the equation is dealt with.

Take Records Management. First, the concepts are agreed upon; second, “we have to get something out” requirements are decided on; third, the tools are picked; finally, the issue of how to tag the information is arrived upon. Oh yeah, the creators of the content. How to get then to change the way they tag information, their habits of thinking around identifying their content for world consumption?

The legacy content is another issue altogether. Are you going to force authors to tag and reorganize their whole c: drive? Are you going to auto categorize the share drive and hope your taxonomy is comprehensive enough? Are you going to set up a master/proxy that layers a meta metadata structure on top of everything? Will there be a hybrid approach to humanly sort out the who, what, when, where, how, why (Zachman).

The point here is that it’s the Users, the corporate culture, that have to change their modus operandi. Sound familiar KM? How many times do we have to come up with applications that work around the ultimate issue of training users to think in terms of the group and the community, of sharing not hording ideas and knowledge? Social applications like Facebook will slowly seep into the minds of corporate Users and break this road block wide open.

Let’s hope that Center Stage grabs this trend and really takes off. If it’s easy to configure during a customer demo like SharePoint is, then maybe it has a chance. The overworked, whittled down IT departments out there want easy to administer enterprise software, that can be mostly configured. As soon as Documentum builds in a more comprehensive configuration tool (yeah I know Composer, right, not quite) the issues of customizations breaking or being too focused will be a problem of the past.

File shares in corporations are not “unstructured”. They actually are very structured, but to an indexing application with a taxonomy, they are “unstructured”. The real issues are change management of User behavior and ECM applications, governance with a small stick, and software that IT can be lazy and cheap about. SharePoint is already the next dumping ground, but User’s have learned just a baby step more about tagging their content so that others can find and understand it.

Diagnosing an ECM illness

As ECM projects and systems grow through awkward teenager years and start to show signs of age, there inevitably comes a time when symptoms of an illness show themselves and can’t be ignored any longer. The existing management is usually blind to the issues. The issues are inherent in how they make decisions and thus restructuring the governance and budget process is usually part of the treatment.

Symptom:

• Lots of Testing on Production and extended down times for maintenance.
  

Diagnosis:

• Lack of QA environment that is exactly like Production to validate test scripts
• The more testing, the more risk of extended downtime and possibility of rollback
  Relaxed emphasis on testing and more attention to deadlines

Treatment:

• Create a QA environment which matches Production down to the hardware (to test server swaps).
• Establish a mandatory QA and Validation process for the QA environment, thus reducing the risk of running major tests in Prod.
• Schedule more time than anticipated for testing in QA
• Budget extra resources for testing
  

Symptom:

• Unorganized folder structures and search results that are useless.

Diagnosis:

• No taxonomy standards
• Lax governance
• Fuzzy goals for business requirements
• No discipline in term of awareness of others who are outside of the team
• No training of common principles of organization
• Poor change management
• No organized Taxonomy: lack of governance, training, standards
• Bad search results: bad metadata, values are too haphazard
  

Treatment:

• Establish goals and standards
• Create a governance structure that can force business units to change
• Study current structures and come up with a plan to rebuild them with the acceptance from the key stake holders.
• Train superusers on information architecture
  

Symptom:

• A call for “re-branding” an implementation

Diagnosis:

• Managers did not listen to the subtle whispers of dissatisfaction with the product.
• UI complaints accumulate, they don’t just happen.
• There are other factors that prevent upgrades to existing software or new software to replace outdated solutions.
  

Treatment:

• Illicit feedback and make changes continually
• Identify the lack of awareness of management to issues of business productivity
• Identify why the system lasted so long in its current condition without treatment
• Create mandates to leap frog to new technology every few years
• Design and architect for change

Symptom:

• Extended Downtimes in Production due to performance and scaling issues

Diagnosis:

• No Failover or HA to fall back on during inevitable times of failure
• Cutting corners on budgeting and resources
• No QA environment for performance testing
• Lack of enterprise architecture plan and resources

Treatment:

• Budget for failover contingency in hardware and software
• Create a QA environment
• Understand the lessons learned from the whole solution development lifecycle: where things went wrong and steps to take to remedy the issues.
  

Symptom:

• Postponing/rescheduling work execution due to emergency, “all hands on deck” system downtime triage

Diagnosis:

• Poor program and project management
• Poor resource management
• Resources that are not trained and experienced enough
• Sign of a series of mistakes during the whole project, no one resource is to blame

Treatment:

• Have clear goals stated up front
• Do not cut corners to meet bogus timelines
• Make sure there is enough time allotted for testing
  

Symptom:

• Slow performance

Diagnosis:

• No architecture plan for scaling of the application
• Lack of performance testing in QA
• Too much leeway given to power users who are not trained enough and only care about their own content
• Poor budgeting process
• No standards for change management

Treatment:

• Transfer the management of the application if this has been going on for a long time
• Architect a solution from the ground up which is flexible and scalable enough to deal with the use and capacity issues
• Think about dividing up the applications if the current one is monolithic

Symptom:

• Stealing infrastructure for other higher priority projects

Diagnosis:

• Poor communication from management of goals and forecasts
• Management is feeling pressure to succeed after a few failures
• Infrastructure procurement process is too slow to be effective
• Resources are frustrated from infrastructure and architecture to implementation teams
  

Treatment:

• Budget and purchase hardware well in advance
• Do not accept a project if it entails cannibalizing hardware and resources from other projects unless the whole teams is fully on board with the sense of urgency

Symptom:

• Infighting during deployment planning meetings

Diagnosis:

• Lack of cohesive governance
• Favoritism within the teams or from higher up
• Lack of trust
• Lack of common understanding of goals or standards

Treatment:

• Create common understanding of goals and standards
• Communicate often and effectively with the team(s)
  

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.

When An Interview Becomes Consulting

When you're interviewing with a potential employee and he asks a specific question about a current issue that his team is having with their content management system, how are you suppose to answer? If you answer vaguely he might think you don't really know what you're talking about, but if you answer completely and might cut the interview short and send you home in order to run down to his team and tell them how to fix the problem.

These days financial companies are the worst because they were used to living fat off the hog for the past few years spending big bucks on contractors to do their development work. Now they have a work force of implementors, but no one experienced enough with development to take on the new custom work. So what do they do? They go ahead and try the development tasks and get into trouble along the way. In the meantime they are creating an environment in IT that is toxic to developers so anyone with talent moves on and the manager is stuck in a never ending interview cycle. But, hey I have a great idea, let's get some really experienced developers in here and interview them and get their advice on our issue! Brilliant! Short sighted, just like this latest rise in the stock market.

So how does you avoid free consulting? Here are some tips:

1. Confuse the hell out of them, laugh and walk out
2. Say you want to meet with the developers themselves to solve this issue
3. Start answering the question, but stop short of answering saying they have to hire you to find out
4. Answer the question, but introduce other aspects of the issue and build in explanations of risk
5. Ask if they've ever tested their disaster recovery system, fully
6. If the manager is an ass, ignore his questions, talk around them until you get kicked out
7. Ask how large their IT compliance team is and whether they are hiring
8. Start saying "just kidding" after every other sentence

The bottom line is don't give sleaze balls free consulting. We're valuable and they know it. Now all we have to do is wait until they pay us the big bucks again in 2012.