• Save
EMC Documentum Compliance Manager Migration Revisited — What a Difference Two Years Makes
Upcoming SlideShare
Loading in...5
×
 

EMC Documentum Compliance Manager Migration Revisited — What a Difference Two Years Makes

on

  • 6,201 views

Momentum 2006 Presentation

Momentum 2006 Presentation

Statistics

Views

Total Views
6,201
Views on SlideShare
6,180
Embed Views
21

Actions

Likes
2
Downloads
0
Comments
0

2 Embeds 21

http://www.bluefishgroup.com 13
http://www.slideshare.net 8

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

EMC Documentum Compliance Manager Migration Revisited — What a Difference Two Years Makes EMC Documentum Compliance Manager Migration Revisited — What a Difference Two Years Makes Presentation Transcript

  • Allergan: EMC Documentum Compliance Manager Migration Revisited — What a Difference Two Years Makes David Mc Donagh Project Manager, EDMS Allergan, Inc. Jes Wills Migrations Practice Manager Blue Fish Development Group
  • Agenda
    • Overview of Allergan
    • Allergan & Documentum (a long history)
    • The DCM 5 Project (Project Snow Goose/CORAL)
    • Blue Fish Overview
    • Project Snow Goose Migration
  • Allergan, Inc. – Overview
    • Global specialty pharmaceutical & medical device company, headquartered in Irvine, CA
    • Neuro Science (BOTOX ® & BOTOX ® Cosmetic)
    • Eye Care ( Treatments for glaucoma, ocular allergy and infections, retinal disease and dry eyes )
    • Dermatology ( Treatments for various skin diseases including Acne and Psoriasis )
    • Allergan - Inamed (Facial Asthetics, Breast Augmentation & Reconstruction, Obesity Products)
  • Allergan, Inc. – Overview
    • $2.3B annual sales (2005)
    • 5,000+ employees globally
    • Manufacturing: USA (Texas), Ireland, Brazil
    • R&D: USA (California) & UK
  • Allergan, Inc. – Centralized I.S.
    • Global operations supported from I.S. based in Irvine, CA
    • Centralized I.S., little infrastructure outside of Irvine
    • Single Documentum server for manufacturing applications
    • Advantages / Disadvantages
  • Allergan’s History with Documentum
    • Documentum purchased initially in 1996.
    • Start: WorkSpace-based (pre-EDMS98) apps
    • R&D applications:
      • DCM 4.3 (March 2003)
      • Publishing (Core Dossier)
    • Web applications
      • Web Publisher (Inter & Intranet)
    • Manufacturing applications
      • 3 Different Workspace applications
  • DCM 5 – Beta Program
    • December 2003 – March 2004
    • Tier 1 participant
    • What We Said at Momentum 2004 :
      • Great to get experience with the software early
      • Software was not as ‘buggy’ as we expected
      • Beta program was short (2 months – not enough time to really work with the software)
      • Significant time commitment was required
      • DCM software was refreshed in the middle
      • PDFAqua not available until 2 nd month
      • Learning curve was steep & Little documentation available
  • Project Snow Goose
    • Project Snow Goose: “A North American bird that undergoes a long, difficult migration”
    • Aim:
      • Convert 4 separate apps, organizations and processes into a single DCM application.
      • End Users: Global Manufacturing & Global I.S.
    • Progress:
      • Prior to 2005:
        • Wait for R&D to complete DCM 4.3 project
        • Merge document types in EDMS 98 apps (Merge over 50 different types  7 document types)
        • Define Requirements based on streamlined business processes & DCM 4.3 knowledge
  • CORAL
    • CO ntrolled R epository for AL lergan Documents
    • Project Snow Goose Core Team
      • 6 full-time Allergan staff members on project
      • Focused consulting assistance
      • Extremely committed user organization
    • Use consultants only to complement existing staff
      • Defined ownership/ maintains internal control
      • Knowledge transfer at end of project CRITICAL
      • Especially technical expertise
    • Target completion July & August 2005 (2 distinct go-lives)
    • Migration critical to success
  • CORAL – Design/Development
    • Timeline restrictions => Rollout DCM 5.2.5. sp1 (build 132c) July 2005
    • Issues:
    • Java Method Server lockup (if more than a few (4-5) people were promoting).  Installed Media Server as part of the SP1 "C" build to process the promotion and notification events.  HP/UX required additional time to get fix.
    • Serial workflow functionality was only 25% developed.  Modified Quickflow to get required functionality.
    • 17 reviewer/approver limit - Never fixed in 5.2.5 sp1
    • dcmCheckin method used for custom check ins did not work
    • dcm_change_cd_properties audit event was not logged.  Fixed in SP1 "FCS" build.
    • Could not demote a document.  Fixed in SP1 "FCS" build.
    • Could only assign the document owner as the periodic review owner and all class coordinators would receive the notification.  We customized periodic review.
    • Search did not work as expected.  Customized simple and advanced search.
    • Future Implementations:
    • Implement a STABLE “.x” product.
  • Migration - Requirements
    • 1) Migrate ALL REQUIRED data
    • 2) Migration from a Network Filestore (Global I.S. documentation)
    • 3) Migrate from 3 different docbases (Manufacturing documentation)
    • 4) New standardised cabinet/folder structure in CORAL
    • 5) Property mappings
    • 6) Docbase migration: Complete migration within a “frozen” window of 5 days – NO docbase activity guaranteed
    • 7) Validatable
    • 8) Reusable
  • Migration – The REALITY (1)
    • How “clean” is the data you own?
      • Clean/consistent data required for migration tools
      • Do you really understand the scope of the data cleanup
      • Mapping of data from varying locations to consistent CORAL location
      • Focussed team reviewing and managing data
      • Inconsistent data = Initial docbase migration Failure!
      • I.S. Network filestore migration – Target July 2005 – Achieved
      • Manufacturing Docbase Migration – Target August 2005 – Not Achieved
  • Migration – The REALITY (2)
    • New docbase Migration plan:
      • Timelines agreed with business
      • Focus on data cleanup
      • Maintenance of data in clean state
      • Validate
      • Dress Rehearsals
      • Manufacturing Docbase Migration – New Target January 2006 – Achieved
  • Project Snow Goose Blue Fish Pedigree
    • What Blue Fish brought to the engagement …
  • Project Snow Goose What we said at Momentum 2005 …
    • Organization Challenges Addressed by:
      • Forming a global migration delivery team
      • Assigning team leads on local level
        • Give each decision authority
        • All team leads had a good command of English
      • Executing each migration at least three times
      • Business users auditing the results of each migration
      • Adopting an approach based on the Blue Fish Migration Methodology and product suite
  • Project Snow Goose The Blue Fish Framework
      • Identify the data to be migrated
      • Extract the data from its current repository/file store
      • Transport the data from its current location to the new location
      • Transform the data into the new structure
      • Load the data into the new repository
      • Validate that the data was transformed and loaded correctly
  • Project Snow Goose The Blue Fish Approach
      • Work with business users to define migration rules for each kind of document
      • Automate the conversion of business rules into XML
      • Leverage Blue Fish DIXI (Documentum Import/eXport Interface)
      • Allow non-technical business users to validate documents at each step of migration
      • Introduce an enrichment step to allow users and/or administrators to perform meta-data enrichment
      • Automate the process to allow repeatable test migrations
  • Project Snow Goose Theory and Practice
    • How we used the framework and methodology to deliver the Project Snow Goose Migration …
  • Project Snow Goose Migration Specification Matrix
    • “ Work with business users to define migration rules for each kind of document”
    • The entire migration was broken apart into separate lots of documents, where each lot was a collection of documents that were all handled in the same way.
    • The behavior of each lot was specified as a single line in a spreadsheet. Other tabs in the spreadsheet defined attribute mappings, lifecycle information and the like.
  • Project Snow Goose Migration Specification Matrix Document Group Source Docbase Content Location
  • Project Snow Goose Migration Specification Matrix
    • “ Automate the conversion of the business rules”
    • The completed Specification Matrix is automatically transformed into XML and fed directly into the system
  • Project Snow Goose Re-architecture
    • Project Snow Goose involved not only a migration, but also an information re-architecture.
    • This re-architecture involved systematically determining the target object-type, attributes, lifecycle, content and location of a migrated object, based on the object’s previous incarnation. While the source repositories held a significant amount of information, this needed to be validated for consistency and then made accessible to the migration system.
    • Many facets of this re-architecture were complex.
  • Project Snow Goose Examples of complexity – Assembly Rules SOP#1, 2.0, Obsolete SOPs Released SOPs SOP#1, 2.0, Current SOP#1, 3.0, Current SOP#1, 4.0, Current Master SOPs SOP#1, 4.0, Current SOP#1, 3.0, Retired SOP#1, 4.0, Current + SOP#1, 3.0, Retired + SOP#1, 2.0, Obsolete +
  • Project Snow Goose Examples of complexity – Naming Conventions A naming convention describes how to break apart names into their meaningful elements. An example of a naming convention specification is: type – pla_state – unit_size – batch_size – destination – formula The elements of the name are used in other components of the migration, for example to determine the name of the destination folder in the target repository. An example target folder specification would be specified as: formula – 0525 – batch_size An example of a name that conforms to the convention, and its target folder: ointment – production – 30mg – 600 – waco – F245 F245 – 0525 - 600
  • Project Snow Goose Reduce Complexity
    • To manage complexity, and to allow the system to develop as it needed to, we adopted a model where we could develop individual components to handle a single aspect of the migration processing.
    • Each component addressed a single element of the process.
    • We then arranged these components as a ‘pipeline’, where the processing steps required for each migration lot could be executed or skipped as necessary.
  • Project Snow Goose Pipeline Operations
    • Folder Naming Convention
    • Detect Duplicates
    • Select Lifecycle
    • Attribute Mapping
    • Cascade Attributes
    • Set Owner Name
    • Check Effective Date
    • Strip Unwanted Content
    • Post-export Selection
    • Detect Split Trees
    • Process Annotations
    • Document Name Convention
    • Set Lifecycle State
    • Perform Document Assembly
    • Remove ‘do not migrate’ objects
    • Set Paper Size
    • Set PLA State
    • Set Retired Date
    • Set Target Path
    • Separate Multi Lots
    • Set Site
  • Project Snow Goose Pipeline Schematic Start Component #n OK? Component #n+1 YES NO Fail
  • Project Snow Goose Inspection
    • “ Allow non-technical business users to validate documents at each step of migration”
    • “ Introduce an enrichment step to allow users and/or administrators to perform meta-data enrichment“
    • We re-cast the enrichment step into an inspection step – this allowed users and/or administrators to inspect the migration information before importing it into the target repository.
  • Project Snow Goose Inspection Application Source Object Information Migrated Object Information Reviewer Notes
  • Project Snow Goose Pre-import Validation
    • Before attempting to import the objects, check for errors such as:
    • Invalid users
    • Unexpected file formats
    • Missing target folders
    • Missing ‘effective’ dates
    • Unwanted native content
  • Project Snow Goose Validation
    • “ Allow non-technical business users to validate documents at each step of migration”
    Source Object Information Migrated Object Information List of Migrated Objects
  • Project Snow Goose Overall Process Flow
    • “ Leverage Blue Fish DIXI (Documentum Import/eXport Interface)”
    Start DIXI Export Inspection Pipeline DIXI Import DIXI Validation Validation End
  • Project Snow Goose Scheduler
    • “ Automate the process to allow repeatable test migrations”
    • Allows the Migration Engineers to control the what/when/where
    • Allows the use of multiple machines to reduce overall processing time
    • Simple to use, provides visual status feedback
  • Project Snow Goose Scheduler Completed Tasks Active Tasks Pending Tasks
  • Project Snow Goose Deployment Staged Local Content CORAL Repository
  • Project Snow Goose Data Cleanup Management and Other Tools
    • In addition to the migration system, we also developed other tools and utilities to help with the migration effort.
    • Source Data Cleanup tools
    • Batch Management Spreadsheet
    • Daily monitoring of data hygiene
  • Project Snow Goose Results
    • Migration Dress Rehearsals paid off
    • Focused Team - Teamwork Triumphs
    • Automation reduces error
    • Validation reduces anxiety
    • Data Cleanup a key to success!