• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
iECM Standards Session 18 May 2005
 

iECM Standards Session 18 May 2005

on

  • 342 views

 

Statistics

Views

Total Views
342
Views on SlideShare
342
Embed Views
0

Actions

Likes
0
Downloads
1
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

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

    iECM Standards Session 18 May 2005 iECM Standards Session 18 May 2005 Document Transcript

    • iECM Standards Session 18 May 2005 Attendees: Owen Ambur John Breeden – VA Department of Transportation Mike Conner - Adobe Cornelia Davis - Documentum Charles Dollar – Dollar Consulting Chuck Fay – FileNet Paul Fontaine - FAA/DOT Carl Frappaolo – Delphi Group Lynn Fraas - Doculabs Baron Gemmer - ICS Gary Gershon – Imerge Consulting Harold Heard – Citigroup AJ Hyland - Hyland Babu Ittoop – Apptis Yasuo Kakizaki – JIIMA Gopal Kandasamy – VA Department of Alcoholic Beverages Control Jason Kinner - HP John Klavanian - EDS Alison Macmillan - Oracle Brian McBride – HP Bill McDaniel – Adobe Systems Roy Massie – SunGard Workflow Solutions Lars Meyer – Emory University Libraries Tomas Montgomery – Digitalfora Roberto Nagel – Document Dialog Bill Neale – FileNet Frank Nemeth - EDS Duane Nickull – Adobe Systems David Nuescheler - JSR-170 Bob Manners - Apptis David Pitfield – Oracle Gil Quihuiz - Kofax Tim Roddy – Stellent, Inc. Chris Ryan – Stellent, Inc. Art Schlessel – Booz Allen Hamilton, Inc. Dan Schneider Tim Sprehe – Sprehe Information Management Associates Scott Srehlak Shumpei Tamaki - Ricoh Artur Vassylyev – ABBYY USA Nick Wainwright – HP Miguel Zubizarreta - Hyland
    • Attachments: Kickoff Meeting Slides iECM-Architecture-UseCasePatternsTemplate Overview: The Interoperable Enterprise Content Management (iECM) Standards effort is a critical activity but is potentially enormous. We need to identify the larger requirements set, but focus near-term activity to achieve a functional, demonstrable success in the 1st 18 months to establish value and justify continuation. A consortium under AIIM management is being considered as an appropriate format for a standards project of this importance, complexity, and potential value. The AIIM Executive Board has already endorsed the need identifying iECM as a primary AIIM focus and is considering support for this effort. This kickoff meeting discussed the existing customer, industry, and Government support and need for iECM standards (significant), Scope (very large requiring realistic constraints and long-term phasing), requirements, and the business approach. AIIM with committee support will develop a business plan to formalize the project, and the committee will develop a set of use cases to initiate iECM requirements definition. 1st pass requirements will focus on supporting current functionality and follow-on requirements enhancement will expand on new functionality related to a truly interoperable iECM. Telecons and a collaborative working environment will be used to draft a business plan and use cases and continue development of requirements. The next committee meeting will occur on Sept 9th 2005 in a location identified by AIIM management. Meeting Minutes Content: iECM Scope/Requirements Scope Discussion Scope/Requirements from the Meeting Discussions iECM Requirements (From the Notes of D. Nickull) Stakeholder Requirements Use Cases
    • Design Goals White Board Lists Logistics Discussion Topics Breakout Sessions DMA/+ Lessons Learned Related to the iECM Consortium/Coalition Business Case Session Presentation Notes: John Mancini - AIIM Introduction Betsy Fanning – AIIM Management Paul Fontaine – DoT / e-Government Mike Connor – iECM Architecture and Services Duane Nickull – Architectural Goals and Approaches Cornelia Davis – Information/Content Management; Metadata David Neuscheler – JSR-170 Lead Paul Fontaine - Organization iECM Scope/Requirements: Scope Discussion: Does the objective include both ECM systems interoperating, and application interoperating with multiple ECM systems? Both Dissent – ECM to ECM system interoperability can’t be done due to N to the mth testing requirement • One as a client of the other Specification defining inherently extensible web services or the meta definitions of how to specify web services?? (Some other expression of a Service Oriented Architecture?) Define a set of services to facilitate the interoperability of content and harmonized processes in alignment with a set of documented requirements. Scope / Requirements from the Meeting Discussion: 1) One of Top 10 Initiatives for Financial Company (ECM) 2) Grow as we go – we can’t big bang this 3) Can’t restrict to one system – hence interoperability 4) Growth implies need for streamlining (vested interest in making ECM real) 5) Synergizing disparate existing systems (leveraging existing investments) 6) Ability to use multiple vendors and products, dynamically, flexibly, modular. 7) Core requirements compliance and regulatory. 8) Centralization, and distributed data sharing. 9) Technical or business problem – blend.
    • 10) Open aspects of interoperability – can be a large number of integrations 11) How to deal with multiple taxonomies – interoperability has to address 12) How can XML be leveraged to facilitate interoperability? Owen Amber 13) Search Interoperability (Elliott Christian (sp?) 14) Security 15) User Friendly (insert properties or metatags) (Search engines need to be able to use them) (Specify core set of metadata – examine who uses them – best/worst case reporting) 16) Account for disparate repositories with different interfaces – the metadata must be rich enough to describe all these interfaces 17) Federated Search across multiple repositories 18) Must not constrain the existence of non-specified functionality 19) Must support versioning (open, complex) 20) Multi-lingual support 21) Audit trail of decisions in rule making process 22) Transaction Recording and analysis 23) Digital Signatures 24) Certified copies of legal records 25) HL-7 Health Care Standard ?? 26) iECM Requirements (From the Notes of Duane Nickull) Editor: Duane Nickull, dnickull@adobe.com 1. Stakeholder Requirements [NICKULL] iECM must account for integration of multiple, disparate implementations of ECM products. [NICKULL] iECM specifications must be capable of specifying both mandatory and optional behaviors. [NICKULL] iECM must account for the requirement of multi – lingual support and full Unicode (UTF-* and UTF16) character sets. [NICKULL] Federated Search capabilities must be facilitated by the architecture. [NICKULL] Identity of all actors within the iECM environment. 2. Use Cases Guidelines for use cases: 1. Must be real use cases (a person must be associated with each use case who may be contacted to elaborate the use case).
    • 2. A template must be used for all 3. First draft of use cases due by June 18, 2005 4. Review cycle (how to review use cases) To develop Project Documentation Templates: Requirements Use Cases Design Goals No Hypothetical use cases. Use Cases must be solvable (Architectural patterns (D Nickull) Maps business case to technical requirements & design goals (1st four elements = use case) Editor at AIIM to collect and edit and put into a document. [need two or three to be contributed] 3. Design Goals [NICKULL] Must not preclude or place constraints upon vendors to add additional services or features other than the core mandatory services defined by iECM [NICKULL] Must not place unnecessary constraints upon the internal architecture of specific ECM vendors applications. iECM Architecture design goals: [NICKULL] iECM Architecture must be capable of facilitating multiple concurrent implementations of different ECM products. [NICKULL] Some of the key feature capabilities of the iECM architecture, independent of specific business requirements, are: • Platform independence. • Event driven and Service Oriented Architecture. (this is potentially contentious at this time) • Component based architecture allowing iECM components to be added, deleted or modified. • Allows proprietary protocol support, including custom extensions for industry standards. • Custom workflow, information and syntax definitions are allowed in support of unique business rules and requirements, as may be defined by users. • Incremental phased implementation must be possible (example – bringing on one service at a time).
    • Must not mandate the use of any specific programming model behind services. White Board Lists: Logistics • Next Meeting o Location: AIIM Selection List of candidates to the committee members. o Date: Previous Conference call(s) (e.g., to build business plan) , F2F Early September o Agenda • Membership ? • Team Conference call 29 June Draft 11:00am EST (we will have Requirements Document, Draft Schedule, Draft Process Document). Discussion Topics: • Metadata • Services • Process • Info Objects • API-170 ext. • ESB-EAI Community • Hard Problems • Quick Wins Breakout Sessions • Architecture/Requirements • Lessons Learned (DMA Few Minutes this PM) • Outreach • Business Plan – Business Case • Scope / Goal Setting (* Team Discussion – See Scope/Requirements) • Value Proposal • Steering Committee o Outreach DMA/+ Lessons Learned related to the iECM: 1) Carefully define the scope and hold to it (make changes carefully) 2) Based on Market Requirements and involve the Vendors (Doable? How?) (yes, right person, need requirements, customer demand, complex iterative process) 3) Stimulate user interest 4) Scope must be achievable near term (1 ½ years) (Consider barrier to entry) 5) Still has to be usable *Balance 4 and 5) 6) Watch out for falling below critical mass (leading vendors actively involved).
    • 7) Balance between new functionality and existing legacy product architectures. (Partial compliance/incremental support) (Not just API on top of …) 8) Changes must be justified by value. 9) Core first, then phased role out based on evolving tech and value-based opportunities. 10) Invalidating pieces of architectures – very devisive 11) Changes are going to have to happen 12) Multiple levels of compliance (Full iECM compliance …) 13) Small Group set down and write out “What you are going to do”. Consortium/Coalition: 1) Formal Charter 2) Dedicated Staffing (Their job) 3) Bigger Investment 4) Property Considerations 5) Additional accomplishments beyond a standard 6) AIIM indicates they can run a consortium (preferred) Business Case: 1) Need to know what achievements means to your organization. 2) Need to know what we are trying to achieve (re: JSR-170)? 3) Time frame: 1st three months mission/structure/support levels/resources/objectives/scope/phasing concepts) Notes: AIIM Introduction – John Mancini President of AIIM Large important scalable issue How to implement in the next 18 months Make sure AIIM Board understands Very Interested Changed agenda – moved and seconded / approved without objection Sign-up sheet and introductions Large hard problem that has been worked unsuccessfully – need to identify what can be done – may have to put hard problems off to the future. Betsy Fanning – AIIM Management Owes the AIIM Board a Business Plan – sees no problem in managing this standards development. We can invite vendors in as required. Related Slides: The following Notes are committee discussions that may be related to the PowerPoint slides provided in the attached Kick-OffMeeting file.
    • Paul Fontaine – DoT / e-Government e-Government lead for DoT Customer – orientation $68B to IT by FY2008 (Homeland Security + e-Government Primary growth) Lac k of authority to Standardize on products (Vertical Stovepipes) OMB forced standardization (Horizontal Stovepipes) Integration issues – faced by Government $ to programs – no drive for enterprise solutions Virtual Case file Requirements changed during development (new level of interoperability) e-travel (1 of 24 e-Gov) successful Business Gateway – Unsuccessful (incompatible sources throughout the Govt. (need for Interoperability needing – 1st pilot case) ? How strong is the Government interest? – CIO Council , Architecture and infrastructure committee – responsible for Govt infrastructure – FEA framework – needs Data Layer – (sharing data) all organizations talked to “on-board” Federal courts, Dept of Interior, Records Management 50-15, EPA – e-Rule Making initiative, NARA, ?How about Industry? Very Little Companies buying other companies have the same problem, consolidation – merging divisions. Example of Company with identical problem keying on semantic web) (ECM Manager) Multinational considerations. Architectural patterns – OASIS SOA Committee, Enterprise content to be shared outside of the organization – patterns in iECM applicable Mike Connor – iECM Architecture and Services ?How about International? EU Cabinet, Italy, France, Switzerland, Netherlands, Germany – all very interested – they all have this problem – offered to sign up / w resources Vision – Globally share information. Need to bind information to processes APIing our way into a death spiral – not a sustainable model :: iECM Need for Metadata to enable rules Loss of Communications in tactical situations Looking for Simple-High Value things iECM can do for customers Slide – Infrastructure / Service Bus XMP with metadata package travels with information (Adobe – Documentum) D. Nickull Architectural Goals, Approaches Architectural Goals Map Requirements to a reference architecture Define scope and paradigm for technical infrastructure Remain agnostic to implementation (interoperable infrastructure) Define a core set of services ADL – Architectural Description Language SOA RM – SOA Reference Model (use OASIS SOA RM as a guide)(web services standards) Multiple concurrent implementations Open Non-intrusive to existing products/vendors
    • Phase 1 architecture iECM Service Oriented Architecture Document requirements and use cases Slide - iECM Services and Patterns: • Federated Search • Content Retrieval • Content Management • Security Services ?capture, document production, process? CD – Definitely Yes! Slide - SOA layer first Process Oriented Architecture (POA) layer afterwards ?? Risk?? We need to identify everything this can do and then prioritize into phased solutions (PF) What falls within the iECM and what falls into the User’s applications ?? May need to expose processes for interoperability. Process visibility constrained to user - ?? Break: Offline discussion – breakout session for process – we need more customer participation and they cannot all be Government. Cornelia Davis - Information/Content Management; Metadata Focus on Data Model(s) above and Beyond Services (Metadata) Boundary between the IECM and the Users – historically control was implemented by what the user put into the ECM. ILM – Integrated Life Cycle Management Have to make IT management easier / cheaper Processes need to be distributed Unlabeled Cans example of Metadata Standards for Metadata have to be extensible (Labels on the Cans) Self Describing Content ?Metadata Mapping? Crucial – Slightly different set of term need mechanism for additions / synonyms, etc. ? Tons of Metadata standards going on now – AIIM metadata efforts on-going, ISOT 171 Cross Walk – studied different metadata standards. Tool to allow a co to receive metadata standards and map it to their own metadata schema – AIIM webpage Metadata Cross Talk, (Need to coordinate) (iECM related to existing Standards – some standards are mandated, e.g., Government, Other Governments, ?? Massive undertaking) We need an infrastructure to enable other standards to be plugged in. Slide – Use Case ILM – ILM technology sits between the storage system and applications. Deduplication, tiered storage, retention, data protection – automating these functions. How do we make sure that the ILM appliances understand supplied metadata? Metadata typically not stored with the content. (Issue) Want to avoid the need to be aware of the interfacing applications. Capture metadata during content creation!! Schema centrally managed and accessible
    • Data validation during creation Enhancing authoring environment – opportunity for corruption ?? Correction?? Standard on packaging metadata with data (Decoupled data / Decoupled Services) ?Standardize on a Document Model?? At what layer are we going to want to normalize?? JSR-170 layer? Lower? Higher? PF- Federal Data Model?? Slide - XMP Extensible Metadata Platform Have a standard way to represent metadata (RDF compliant?) that is embedded into the data files. Access metadata independently from the file – AIIM standard committee – XML wrapper (contain info). (More zip-like with additional pieces) InDesign Demo. Ask user to generate metadata when generating content. Metadata can include constraints – e.g, data license , fee for image use, etc. Work environment as a source of metadata (iECM allows input of schemas from applications) We have to be aware of the interface with applications. ?? Mass input of formatted input without authors – no opportunity to create metadata?? How to create the related metadata and manage through time? ??Capture metadata through business processes and rules?? We may envelope data ?? or iECM will support these processes?? iECM has to be agnostic to the storage medias. ??How about legacy systems lacking the metadata – any vision for inclusion? Services to provide metadata. Metadata must be provided with content. ?? metadata changes?? Symbolic link to metadata?? Affect on validation?? Synchronization?? ECM is changing, evolving. David Neuscheler – JSR-170 Lead One of many standards – has some useful things ?Did you look at JSR-170 and identified things that are missing?? Yes Some things are outside of the scope of JSR-170 – narrow scope. Describes a Java API {insert Paul Fontaine’s Notes} Paul Fontaine: Organization: PF initially hypothesized 3 Subcommittees: 1. AIIM Standards Subcommittee 2. Architecture Subcommittee 3. Business Case Subcommittee Metadata Committee Service Committee Process Committee (Need larger array of Use Cases in additional Domains e.g., Pharmaceutical, Automotive) Hard Problem Definition / Prioritization & Phasing Industry Contacts Vision Definition & Implementation Preparation Business Case Definition & Opportunity Definition
    • iECM iECM Architecture Process POA Financial Business Planning e.g., XML interoperability – no customer demand Evolutionary Management Lessons Learned (e.g., DMA and trap requirements & concepts). DMA – obsolete failure due to massive scope & lack of Technology (objection to technology as an excuse) We need to take the lessons learned from DMA and start again with new minds. They were trying to integrate multiple repositories – perhaps wrappers or ?? iECM scope is much broader Many organizations don’t have an enterprise approach within their own organization – follow-on is that they will not support this as an integration requirement. – If they meet a standard. We need to identify scope, to have a clear business case and rationale for investment – we are not yet ready to seek resources. Need experience in building a standard – a standard is good only if it is implemented. Is AUTO-CAD going to use this? SEP? Web-DAV?, They drive the market. Is this the right group to build this standard? What are the areas that require standards? CD Consortium?? Need for resources – staffing, prototypes, laboratories, test benches, etc. You (e.g., Oracle) need to tell me what you need for your business case including what creation of iECM functionality means to your organization/company. PF Suggest we talk to Dave Neuscheler about JSR-170 Lessons Learned. Let’s try to get a scope – need to focus to be successful. See existing AIIM Project Plan. Need to clarify existing scope. Need to enhance for consortium considerations, but first/also focus on standards level. Coordinate AIIM Standards with ISO standard requirements so that it can be implemented as an ISO standard with minimum difficulties AIIM follows ANSI intellectual property policy. AI Betsy to inform team of list of participants, activities, etc. PF AI develop use cases (12?) in 30 days to AIIM (Betsy Fanning) Present to this committee (X days) to determine if they are already solved, or are open to new standardization. Document contacts with use cases – with permission and validate with the sources.
    • AI_ Tomas + Cornelia + Process for Collaborative environment – Documentum e-room offer not implying ? Security ? Access List? Publish a schedule for document production. Only members can post but anyone can read. No – Need a private collaboration environment for creation. We also need to define committee processes beyond the collaborative environment – e.g how do we get from 3 temporary chairmen to a permanent chairman. Need to have a formal organizational meeting. Need team feedback on ideas for the function of this Project.