Documentum:Where Do We Go  From Here?Frank Jacquette, Jacquette        Consulting
A Brief History of         Documentum• Company founded in 1990 by ex-Ingres  engineers• Funded by Xerox• First version of ...
1995• WorkSpace replaces the fairly useless  DocuWorks  – Server 2.0  – WorkSpace 2.0
1996• Accelera – first web product, read only• UnaLink – Lotus Notes interface• Server 3.0 – ACLs, other  enhancements• Wo...
1997• Server renamed as “DocPage Server”• RightSite I (aka “the fiasco”)  – ViewSpace (read-only web browsing)  – SiteSpac...
1998• Server 3.2, renamed as “EDMS 98”• RightSite II  – Complete rebuild, shares nothing but the    name and parts of the ...
1999• Desktop Client  – Windows only  – Provides file explorer interface to    Documentum  – Breaks all previous WorkSpace...
2000• New name for version 4, Documentum  4i• Documentum Foundation Classes  – Java wrappers around server APIs  – Documen...
2001• Server 4.1 (still under the 4i name)• Web Development Kit (WDK)  – Tools for building Java components on top    of t...
2002• Documentum 5 scheduled for 3Q02• Includes WDK 5, DFC 5• New features focused on digital asset  management, some usab...
2003• WDK 5.1, 5.2 announced, roadmap to  WDK 6• Server 5.2.5 ships, Webtop becomes  preferred client (built on WDK)• Prod...
Today – What should we use?• Documentum says: use the WDK to build  J2EE components (starting from Webtop)• Great idea, bu...
Discussion• Talk about the problems/solutions you  have or foresee
Options• Keep older technologies• Port customizations to new clients• Build your own client application  – Using the API  ...
API• Fastest option           • Lowest level option• API is the most          • Platform-dependent  stable of all client  ...
DFC• Platform                • Slower than API calls  independent             • Long initialization of• Provides full acce...
WDK• Clearly Documentum’s       • Performance: full round  direction                    trip for almost all• All the benef...
Recommendations(?)• Consider WebTop and WDK for new efforts  where:  –   Performance is not key  –   Client platform is un...
Recommendations(?)• Use C or Visual Basic against the API (or  against a DFC-API wrapper) if the WDK  conditions aren’t tr...
Upcoming SlideShare
Loading in...5
×

Documentum: where do we go from here

364

Published on

A history of Documentum from beginning to 2005.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
364
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Documentum: where do we go from here

  1. 1. Documentum:Where Do We Go From Here?Frank Jacquette, Jacquette Consulting
  2. 2. A Brief History of Documentum• Company founded in 1990 by ex-Ingres engineers• Funded by Xerox• First version of software shipped in 1993 – Documentum Server 1.0 – DocuWorks 1.0
  3. 3. 1995• WorkSpace replaces the fairly useless DocuWorks – Server 2.0 – WorkSpace 2.0
  4. 4. 1996• Accelera – first web product, read only• UnaLink – Lotus Notes interface• Server 3.0 – ACLs, other enhancements• WorkSpace 3.0 – GUI improvements
  5. 5. 1997• Server renamed as “DocPage Server”• RightSite I (aka “the fiasco”) – ViewSpace (read-only web browsing) – SiteSpace (anonymous web browsing) – SmartSpace (read/write web client)• SmartSpace Client/Server (aka “WorkSpace Light)
  6. 6. 1998• Server 3.2, renamed as “EDMS 98”• RightSite II – Complete rebuild, shares nothing but the name and parts of the WebQL engine with RightSite I• See ya later, Macintosh users
  7. 7. 1999• Desktop Client – Windows only – Provides file explorer interface to Documentum – Breaks all previous WorkSpace customizations
  8. 8. 2000• New name for version 4, Documentum 4i• Documentum Foundation Classes – Java wrappers around server APIs – Documentum pushes developers to use DFC rather than straight API calls
  9. 9. 2001• Server 4.1 (still under the 4i name)• Web Development Kit (WDK) – Tools for building Java components on top of the DFC• Documentum quietly plans to kill WorkSpace and RightSite
  10. 10. 2002• Documentum 5 scheduled for 3Q02• Includes WDK 5, DFC 5• New features focused on digital asset management, some usability enhancement• Pledging RightSite support…for now• No upgrade path from RightSite to WDK – start over!
  11. 11. 2003• WDK 5.1, 5.2 announced, roadmap to WDK 6• Server 5.2.5 ships, Webtop becomes preferred client (built on WDK)• Products all get renamed (again)
  12. 12. Today – What should we use?• Documentum says: use the WDK to build J2EE components (starting from Webtop)• Great idea, but… – Need a separate application server (WebLogic, WebSphere, etc.) to serve the J2EE components – All WorkSpace and RightSite customizations are lost – WDK, DFC, Desktop Client still being thrashed out – Performance and usability weaknesses
  13. 13. Discussion• Talk about the problems/solutions you have or foresee
  14. 14. Options• Keep older technologies• Port customizations to new clients• Build your own client application – Using the API – Using the DFC – Using the WDK
  15. 15. API• Fastest option • Lowest level option• API is the most • Platform-dependent stable of all client implementation (but targets API calls are• Full access to all common across all server functions platforms)
  16. 16. DFC• Platform • Slower than API calls independent • Long initialization of• Provides full access client side JVM required to API • Future of Java support• In theory, can on Windows is improve uncertain performance by • Just starting to virtue of abstraction stabilize/get useful
  17. 17. WDK• Clearly Documentum’s • Performance: full round direction trip for almost all• All the benefits of Java component events and relevant standards • No migration path• Good • JVM compatibility business/presentation issues logic separation • WebTop has huge usability issues
  18. 18. Recommendations(?)• Consider WebTop and WDK for new efforts where: – Performance is not key – Client platform is under tight control – Expected product life cycle is not very long – In-house Java expertise is solid• Similar considerations for DFC, but DFC may work better when you want no Java on the client side
  19. 19. Recommendations(?)• Use C or Visual Basic against the API (or against a DFC-API wrapper) if the WDK conditions aren’t true• For older systems, keep them if they aren’t changing until Documentum forces an underlying server upgrade• For critical, still-evolving systems, start planning a migration to WDK, DFC, or API

×