Friday, January 15, 2010

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)

Friday, December 18, 2009

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).

Tuesday, December 8, 2009

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.

Monday, November 16, 2009

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.

Friday, October 16, 2009

Composer and ACHells

Hosed by Composer again! This time trying to install Permission Set from Dev to Test Repositories:

Environments:

  • Dev Repository name: LoserDev
  • Dev Repository Domain User: LoserDev
  • Test Repository name: LoserTest
  • Test Repository Domain User: LoserTest

  1. Created a Permission set in Dev, which set the ACL domain as LoserDev which corresponded to the LoserDev install parameter in Composer.
  2. Installed it into LoserDev and everything unit tested fine.
  3. Went to install the dar file to the LoserTest repository and got an error: “user LoserDev does not exist in Repository”.
  4. ** Don’t be tempted to create the user in the repository. This will allow the dar to install, but will really confuse the UI with ACLs that kind of work, but not really.
  5. Went back to the LoserDev Project and opened the LoserDev install parameter, typed in “dm_dbo” into the default value box, saved it, and created another dar.
  6. Went to install the dar file to LoserTest: same error. What the?
  7. Went back to LoserDev Composer project, check the LoserDev install parameter and the default value was blank. Hmmm.
  8. Type the default value into the user parameter value of dm_dbo again and hit the enter key. Ahha! Saved it, created the dar and the install to LoserTest worked.

Bottom line: In Composer make sure you have an asterix * in the tab, to guarantee that your work is getting saved to the underlying xml file which is used to create the dar file.

Documentum Composer Wrestles with Lifecycles

Hosed by Composer again! Whoever thought Composer was ready for primetime with Lifecycle management was really in the clouds. Here’s what happened:

  • I created a Composer Project (call it Poser) and a new lifecycle (let’s call it DOA) along with many other artifacts.
  • I installed the Poser.
  • DOA had issues with ACLs and was not working correctly
  • I thought it would be better to create a delta dar for modifying just DOA
  • I created Composer Project 2 (Hoser) and imported DOA from the repository
  • I fixed DOA and installed Hoser.
  • Now Webtop showed 2 DOA lifecycles.
  • Naturally I deny that anything wrong is happening and I choose the wrong DOA, try it and get frustrated.
  • I DQL, I look at ACLs, I search Powerlink, I download Doc App Builder 5.3sp65
  • So I go back to Hoser, import the original DOA and click the “uninstaller” checkbox to uninstall both DOAs.
  • I install the Hoser again.
  • Now Webtop showed the original DOA still installed…What the? What got uninstalled?
  • At this point I installed Documentum App Builder, created a docapp, imported the lifecycles and uninstalled them. I fixed the DOA and had no other issues. This is still the true work horse!

Bottom line: once you create a lifecycle and actions, stick with that project, don’t create new projects using the original artifacts.

Monday, October 5, 2009

Content Architecture using Memetics

Virus of the Mind: The New Science of the Meme by Richard Brodie, describes the foundation of memes as being distinctions, associations, and strategies. When applied to Enterprise Content Management there are some interesting comparisons. Advertisers know how to push our buttons to drive sales, just as content architectures know the best ways to describe and find content, or do they?


Distinctions

Example: It’s snowing, or our content is all on a share drive.

These are the ways to describe content that are particular to the business unit, the company, and the industry. This metadata is vital for survival of the content, in other words, can a User find it among thousands or millions of other pieces of content? What key information can be drawn out of the content file or its context to direct successful search result?

Associations

Example: Snow is dangerous when driving, or without metadata I get thousands of search results.

Relationships among content and its environment are key the understanding the thoughts (memes) behind the content. A taxonomy helps by categorizing a business unit’s way of thinking for its search or retention purposes. This taxonomy would have to fit into the enterprise as a whole. The issue here is to start at the level where the content is created and is useful to the local users, then expand the levels out in a way that doesn’t disturb the functional aspects of the original group. Too much of an imposition will get rejected or worse slowly ignored.

Rules and Regulations come in to play for controlling and focusing content for common delivery to people and interfaces outside of the company’s mindset.

Fuzzy vs. Absolute: Users want to be able to fill out metadata and find that exact content later. This means the content architecture has to balance the business unit’s requirements with the enterprise's.

Strategies

Example: If I have an all wheel drive I’ll make it through the snow, or with a taxonomy I can make sense of complex organizations.

Repetition: this is used to drill home the importance of certain ways of thinking (memes). For example, a naming convention will reinforce ways of thinking about content and its context (association meme).

Cognitive Dissonance: this is used to reward a User for taking the time to fill out metadata correctly. For example, filling out metadata and associations is rewarded with less change management, less hassle in the future when ways of organizing content changes.


Content Silos

However you want to attack the issues of content silos, they will always exist. The strategy memes of the business unit will always differ in meaning and scope from the enterprise. I’ve come to the conclusion that the best way to make importing and/or changing content the easiest on the User is the hardest to figure out in terms of scale and performance on the system. This means that finding the right balance of splitting up the system’s resources for each business unit weighing the content demands, the ability to find content, the access control, and the application of the latest rules and regulations. This balance when seen visually will make sense, but the challenge is to get agreement from all the parties involved, the governance. This is where strategy memes make inroads: they help far removed executives understand the long term benefits when seen from the past, present and future.