Interoperable Enterprise Content Management iECM

1. Interoperable Enterprise Content ManagementiECM AIIM Kick-off Meeting Paul Fontaine DOT Mike Connor Adobe Cornelia Davis Documentum Co-Chairs iECM

2. AIIM Introduction • Welcome - Betsy Fanning • The Customer View - Paul Fontaine • Overview - Mike Connor • Architecture Considerations - Duane Nickull • Metadata Interoperability - Cornelia Davis • JSR-170 for iECM - David Nuescheler • Discussion - All

3. E-Gov & DOT – Paul Fontaine • My Role • E-Government Lead • Working Relationships • Experience • iECM - Business Problem • iECM – Interest and Support

4. Federal IT Spending $68B U.S. Federal Government spending on IT products and services will increase at a compound annual growth rate of 8.5 percent, from $45.4 billion in fiscal year 2003 to $68.2 billion in FY 2008, ... Homeland-security and e-government initiatives top the list of priorities. Input - Federal IT Market Forecast 2004-2009

5. Why iECM?Stovepipes Cripple Us! Collaboration Records Management Electronic Publishing Web Content Management Forms Management Document Management

6. Forms Forms Forms Forms Grants Grants Grants Grants Travel Travel Travel Travel Training Training Training Training Recruitment Recruitment Recruitment Recruitment Procurement Procurement Procurement Procurement Finance Finance Finance Finance Records Mgt. Records Mgt. Records Mgt. Records Mgt. Rulemaking Rulemaking Rulemaking Rulemaking Vertical Stovepipes

7. DOT PMA E-Government Projects • Grants.gov • Business Gateway • Recruitment-One-Stop • Integrated Procurement • Records Management • International Trade Data System • Web Content Management • Document Management • Correspondence Management (CCMS) • Rulemaking

8. Horizontal Stovepipes Recruitment Finance Grants Procurement Training

9. Use CasePublic Health

10. Allways Airlines Carlo Giles Use Case Criminal Investigation Multiple Agencies, Multiple Departments, Multiple Records Systems – One Job Electronic Case Jacket Written Reports

11. Vision – Global Information Sharing

12. Information in Motion - Requirements Information Package Manage Workflow Transport People

13. Intelligent Information • Information should know how to… • Act on itself • Present itself • Classify itself • Route itself • Protect itself • Leverage new & existing services and standards • Within the context of • who’s using it • what they are doing • and where they are.

14. Front End Processes External Processes ECM Systems Back End / Desktop Applications The iECM Architecture & Services IECM Web Services / SOA Architecture Process Services Search / Find Format Store/ Retrieve Create/ Acquire Organize/ Process Archive/ Destroy Distribute/ Publish Infrastructure / Service Bus Rules / Event Management Secure / Authenticate / Administer Integrate / Orchestrate

15. XMP Capture, share, and leverage metadata XMP Visualization Authoring Transformation Collaboration Meta data Repository Data Model / Services Publication Assembly Staging Security Data Store Rules Engine Data Services OntologyServices XMP Services Policy / Security

16. iECM Architecture Considerations Architecture Kick-off Presentation – May 18 2005 dnickull@adobe.com

17. Goals • Discuss architecture requirements and concepts • Present proposed architecture process and methodology • Examine proposed architecture • Form iECM Architecture working group

18. Architecture Goals • Document Requirements as input; map to a reference architecture. • Define scope and paradigm for technical infrastructure. • Remain agnostic to implementation detail (programming language, O/S etc.). • Define a core set of services. • Constrain protocols and specifications to ensure interoperability within iECM environment.

19. Proposed Architecture Process

20. Specific architecture proposals • Service Oriented Architecture (SOA): • Based on web services standards. • Use OASIS SOA Reference Model as guide. • Facilitates multiple, concurrent implementations. • Not reliant on any proprietary standards or protocols. • Message Oriented, event driven and composable architecture.

21. OASIS SOA RM - draft

22. Architecture scope – phase I

23. IECM Service Oriented Architecture

24. Core iECM Services and Patterns • Federated Search • Content Retrieval • Content Management • Security Services

25. Optional Services and Patterns • Transformation • Validation

26. SOA Layer iECM Process Management • Process Management is outside initial scope. • Rationale: need to define core services first before defining management of services. POA Layer

27. References • OASIS SOA RM TC – http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm • AIIM iECM Announcement - http://www.aiim.org/article-pr.asp?ID=29666 • Architecture Working Group – dnickull#adobe.com (replace # with @)

28. Introduction Introduction Use Cases Summary

29. Introduction: Information/Content Management • Information Management is achieved through a set of services on a body of content that enable or streamline business processes. • Traditionally ECM systems have operated in a centralized information store and services model. • Evolving business needs as well as the requirement to manage ever expanding volumes of data through automated means are calling for an architecture where both content and processes are distributed. • Tried and true data models still apply. Files + metadata. Self-describing content.

30. Self-describing content • Which is the corn? Open the can. • What does it cost? Ask the clerk. • How many calories? Ask Delmonte • How does the store automatically manage inventory? You can’t

31. Standardized labeling allows multiple vendors to consistently represent information to consumers Extended labeling for LOB uses MetaData Standards and Extensions Self-describing Content

32. Introduction Use Cases Use Cases Summary

33. Use Case: Information Lifecycle Management • Management of files on the storage platform with goals of optimizing storage, meeting compliance objectives, etc. • Deduplication • Tiered storage • Retention • Data protection • ILM technology sits between the storage system and applications. • Current state of the art makes deductions based on a very limited set of attributes available for all files; size, create date, modify date, … • A richer, yet standardized, metadata set greatly enhances the ability to appropriately manage an asset. • How do we make sure the metadata exists for all content? • “Centralized” data dictionary, schema management • Distributed data validation • How do we make sure that ILM appliances understand supplied metadata?

34. Metadata in Information Management Legal Marketing Financial Content is categorized via metadata

35. Authoring Application Validation Service Schema Service Search Service Data Dictionary Repository Use Case: Extra-repository ECM Rules Engine Schema centrally managed and accessible from authoring application Data validation and enforcement during creation – supports full information lifecycle management Metadata drive contextual and automatic search of relevant materials Full object definition supports in line external evaluation Easier or automatic entry into repository

36. Each SLO group contains the Service Parameters Metadata in Information Management Compliance Retain =5 yrs Dedup = Not Allowed Protection = offsite Legal Marketing Financial Mission Critical Retain =1 yrs Dedup = Not Allowed RTO / RPO = 99.99% Protection = offsite Content is categorized via metadata Actions performed on information objects (including metadata) Business Critical Retain = use Corp def’n Dedup = Allowed Protection = backup

37. Interoperable Enterprise Content Management Componentized Source: AIIM IECM Proposal (Paul Fontaine, FAA and Mike Connor, Adobe)

38. SOAP <Envelope> </Envelope> SOAP <Envelope> </Envelope> Application Application Web Service Web Service Web Service Interoperability – a start… Decoupled Services

39. Application Application Web Service Web Service Web Service Interoperability – … continued Decoupled Services AND Decoupled DATA SOAP <Envelope> </Envelope> SOAP <Envelope> </Envelope>

40. iECM and Intelligent Authoring • Constructing proof of concept • Included in Interoperable ECM talk: Momentum Barcelona May 23-26 • Expanded at Momentum Las Vegas, October • Press Release • AIIM IECM committee • Adobe’s Extensible Metadata Platform (XMP) • “The eXtensible Metadata Platform is Adobe’s description format for network publishing. This new framework is an electronic labeling system for files and components of files, designed so that computers can read and understand the labels, and populate the information automatically into the right fields in databases, respond to software agents, or interface to intelligent manufacturing lines, just to name a few of the implications.” (XMP whitepaper) • Standardizes an XML format for metadata • Packages metadata with file contents

41. iECM and Intelligent Authoring (cont) • Demo flow: • User creates new InDesign document • User provides base metadata values (departmental affiliation, document type and customer) • Departmental affiliation and document type determine additional schema elements • Data validation • An image is pulled into the document • Comes from public library • Includes embedded metadata including IPR values • Metadata from image is absorbed by containing document • Metadata from containing document is propagated down to the image file • Transparent or one-click ECM check-in • ILM processing (categorization and actions)

42. Introduction Use Cases Summary Summary

43. Enterprise Content Management is Changing • It’s an evolution. • Becoming more distributed • Becoming ILM • The need for cross application data use is driving a fundamental architectural change that is pushing some functionality down into infrastructure. •  in particular, the metadata functions.

44. Introduction to JSR-170 for iECM

45. What is JSR-170? „ The API should be a standard, implementation independent, way to access content bi-directionally on a granular level within a content repository. “ http://www.jcp.org/en/jsr/detail?id=170

46. ApplicationA ApplicationB ApplicationC ApplicationD API A API B API C API D RepositoryA RepositoryB RepositoryC RepositoryD Challenges: State of the EnterpriseIsolated Content, Proprietary Repositories

47. Application A Application B Application C Application D Standard API API A API B API C API D Repository A Repository B Repository C Repository D Challenges: Standard API for Content Repositories(JSR-170) One API removes the Silos

48. Application A Application B Application C Application D Standard API API A API B API C API D Repository A Repository B Repository C Repository D Solution: Content Repository ExtremeThe only production JSR 170 product Consolidation, Single Repository Content Repository Infastructure

49. Industry Standard JSR 170: Content Repository for JavaTM technology API

50. Java Standardization Specification to be finalized by H1/2005 Reached “Proposed Final Draft” 11-feb-2005 Current Status of Process