Business Use Cases

[resplin]

Obsolete Pages{{Obsolete}}

The official documentation is at: http://docs.alfresco.com

IECM

The area of content management is so vast and comprehensive, that it is difficult to pick just one area to develop patterns that will satisfy all application requirements. However, there are clearly common patterns of system interaction that are common such as library services, check-in / check-out, query and search, hierarchy navigation and content handling.

The IECM (part of AIIM) have identified 6 main areas of content management: Collaboration, Web Content Management, Records Management, Electronic Publishing, Forms Management and Document Management. Any of these is a reasonable target area for a content management application. By content management developers, the developers should be aimed where they are most needed. Our priority is to target the application use cases that are constantly being re-invented and using the most resources.

Table of Contents

• 1 Portal Integrations (A)


• 2 Workflow / Lifecycle Applications (A)


• 3 Collaboration Applications (A)


• 4 Complex and Large Content Applications (A)


• 5 Industry-specific Content Business Objects (A)


• 6 Cross Repository Accessibility Applications (B)


• 7 Desktop Integrations (B)


• 8 Web Content Management (B)


• 9 Non-interactive Aspects for Transactional Content Services (B)


• 10 Industry-specific Records Management Applications (B)


• 11 Content Administration Tools (B)


• 12 Replication and Syndication Applications (C)


• 13 System Registries (C)

Portal Integrations (A)

Portal Integrations: This includes all JSR-168 and WSRP compatible portal frameworks. Portals are increasingly the way that content is captured and that content is delivered throughout and enterprise or beyond. Portals can either be a corporation’s intranet, a customer self-service extranet or a hub for the exchange of information or documents such as specifications, quality certificates and maintenance material. It could also include various application frameworks from other enterprise app vendors. Behaviors should change based upon a user's role, an object's type or a views configuration. Common use cases for portlets and extensions of portlets provided by vendors include:

• Folder / Container navigation with specialized views: Present different views, with different metadata, icons, thumbnails, sorting and layout, all of which should be accessible from the repository.
  
• Check-in and check-out components: provide specialized interfaces to handle behavior on check-in and check-out. Handle content appropriately. Provide proper locking semantics. Allow for specialized handling of metadata and content processing before and after these actions (i.e. aspects of check-in and check-out).
  
• Property sheets: Provided specialized property sheets when inspecting the properties of a content object. These should be specialized based upon the user's role, permissions and capabilities and the content object's type, location and security.
  
• Wizards for the creation of content and site components: Provide a guided user interface with rules for managing definitions, metadata, content, content handling and content processing. Some examples include auto-classification and verification of the results, translations into other languages or initiation of a workflow upon creation.
  

Functionality required beyond baseline:

• Categorization
  
• Portal navigation context
  
• User context: Role, Audience
  
• Capability context
  
• Transparent permissions mechanism
  
• Data dictionary easier, not mixed nodes and properties, proper typing mechanism, support for extended metadata such as categories, proper reusable datatypes, types by role and context
  
• Dispatch context
  

Workflow / Lifecycle Applications (A)

Provide the essential web-services to support content-oriented business processes and their associated applications. The content could be web pages, but is more likely to be documents that may ultimately be rendered as web pages.

• Paper flow: Forms management
  
• Electronic publishing
  
• Categorization applications
  
• Issue Management
  
• Configuration
  
• Change management
  
• Contract mgmt
  
• Compound document composition
  
• Case management
  
• Workflow
  
• Lifecycle
  

Functionality required beyond baseline:

• Simplified, concrete data model that handles documents and folders
  
• Simple, structured children iteration
  
• Explicit MIME type handling
  
• Query interface consistent with structured children iteration
  
• Categories
  
• Data dictionary support for extended type definitions (would these be ordinary JCR types?)
  
• Industry-specific data dictionary references controlled by a central repository
  
• Lifecycle patterns
  
• Workflow context association with content
  
• Simplified versioning mechanism
  
• Clear aspect patterns for new, check-in, check-out, save, lock, unlock, delete
  
• Complex, large content handling
  
• Office 2003 research panes, smart tags and smart document types
  

Collaboration Applications (A)

• Collaborative Context - Must
  
• Discussions
  
• Wikis
  
• Tacit to Explicit: forums
  
• Context: location, membership, autonomy, security, classifications, types, views, query on a context, relationships and discussions
  

Communications: IM, web conferencing, (C)

Complex and Large Content Applications (A)

Some content feeds are very long and very complex. Handling of that content, in and out of a repository, requires different handling protocols. Simply having content as a property of an object is not sufficient for dealing with even moderately large content such as images and PowerPoint presentations. Rich media feeds, such as films and video broadcasts, have complex buffering requirements. Some feeds, such as news feeds and scientific and exploratory data, have no end. Another application would be chunking extended content feeds and the monitoring of these feeds and auto-classification thereof.

Industry-specific Content Business Objects (A)

Encourage a *lot* more developers building business objects. Some examples include: specialist image objects such as medical and police images and special office document handlers such as strategic plans, contracts, and bid proposals.

• Industry-specific images: Medical, police, reconnaissance with special meta-data and classifications mechanisms and naming conventions
  
• Office documents: strategic plans with internal roll-ups of spreadsheet components, request for proposals, contracts with related meta-data and industry classifications
  
• Secret documents with associated security level classifications. Should also support encryption and decryption for eyes-only.
  
• Music: mp3s etc, say no more
  
• Video
  

Functionality required beyond baseline:

• Easier way of defining types
  
• Associating mixins with types and nodes
  
• Type and Mixin method signatures
  
• Categories
  
• Data dictionary support for extended type definitions (would these be ordinary JCR types?)
  
• Industry-specific data dictionary references controlled by a central repository
  
• Aspects / mixins for security
  
• New methods for authentication
  
• Clear aspect patterns for new, check-in, check-out, save, lock, unlock, delete
  
• Lifecycle patterns with clear transitions
  
• Observers for requiring authentication on authorization
  
• Complex content handling for large objects
  

Cross Repository Accessibility Applications (B)

There is a clear desire on the part of large enterprises to provide seamless searching and discovery of information, content and documents in multiple vendors’ repositories. One of the principal drivers of this is discovery of content that is in breach of any compliance policies. They are also interested in the discovery and exchange of knowledge between different divisions. A simple google style of appliance has not been sufficient for most of these organizations since they want to use metadata and process information as part of the search process. A Java-only interface is not really sufficient since it needs to apply to non-Java stores and Microsoft Sharepoint. There also needs to be a way to identify the scope of the search through a consistent naming and discovery mechanism.

The pattern of cross repository searches is to present the search as portlet or web application. The user should either be able to express a simple Google-like query or be provided with a web interface for specifying a more meta-data or classification oriented search. The scope of the query should be more than one “workspace�? and should be able include multiple repositories and sub-repositories. The results should be blocked (i.e. 1-10, 11-20, etc.) and returned instantaneously. Sorting options should be supplied. The language that implements this pattern should be understandable and constructible by a SQL-literate programmer.

Some of the applications of cross repository searching are discovery of knowledge in various departmental repositories, compliance discovery of infractions and identification of knowledgeable individuals based upon the material they have contributed to various repositories. Some of these applications may be automated, but most will probably be interactive. It may be enough to return the results, but it is worth considering adding a follow-up action (a pattern in itself?) that either creates a new object in a central repository or invokes a workflow to perform a follow up action, such as send out a compliance notice.

Functionality required beyond baseline:

• UDDI discovery of available repositories
  
• A universal repository identifier
  
• Repository or workspace reference for a query
  
• Multiple credential handling
  
• Context of search for follow-up action
  

Desktop Integrations (B)

Think of this as WebDAV mark-II enabled through web services. Integrating with a user’s desktop was the key objective of the ODMA consortium, which without the backing of Microsoft failed. Integration should place the content repository cleanly in the user’s environment. This includes the tools that are used for authoring, editing and viewing content. While using the operating system’s browser, the repository should look like one very large virtual drive. Between the two versions of Sharepoint, 2001 and 2003, Microsoft has set the standard of what this user experience should be like by tightly integrated with the application and menus, integrated with file browsing and providing collaboration interfaces. Unfortunately for Microsoft, it is not all available in one release. WinFS and Longhorn will set the standard in the future. Without this type of interface and the standardization of the browsing experience, users are now reverting to using shared drives as a much easier, but less controlled content store.

• Office Tools: ODMA and Microsoft Office 2003 both provide basic library services for searching, browsing, checkin, checkout, locking, and managing properties. Microsoft Office is the most important target providing most office content. Open Office will become increasingly important in non-Western countries. Other tools such as image manipulation tools and web authoring tools such as Dreamweaver should also be supported. ODMA set a good design pattern for this type of interface, but it should also take into account associations and classifications as well.
  
• Explorer Browsing: WebDAV provides a set of HTTP interfaces that most file browsers now support. This allows hierarchical search of information. However, Sharepoint 2001 provided superior integration in the Windows Explorer by providing integrated menu items for check-in, locking, publishing and extended properties.
  
• Outlook integration: messaging clients, Store, task in outlook / form
  
• Capture Properties and Classifications: A lot of metadata is either stored or can be inferred from the content of documents and files. Applications should be built that can take this information and store it along with the content and the dependency on these tools injected at the right points such as Save As or Check In.
  

Web Content Management (B)

Doing a search and count on Google for content management indicates that the market thinks that content management is Web Content Management. The problems are well explored, but there are still many holes in solutions and in the ease of use of most tools on the market. Classification is still not well addressed. In-line editing, virtualization and previewing are still difficult with most tools. However, this is an area that has become much commoditized.

Non-interactive Aspects for Transactional Content Services (B)

This would allow users to change the behavior of standard repository behavior. It would also allow advanced features to be added without breaking the specification since Aspects would always be optional. Upon a save to or retrieval from a content repository, the system can arbitrate the invocation of an aspect on that content. Before doing a save, an aspect could perform an operation through a web service, such as auto-classification, so that the aspect didn't need to be written in the same language, be on the same machine or even in the same enterprise. It could open up new service opportunities such as translation that would be provided by 3rd parties. As such, it would be worth considering not just security mechanisms, but also payment and scheduling mechanisms.

• Auto-classification: On save, analyze the content of an object to extract meta-data and compare to existing content or external classification schemes such as DMOZ. There are many ways to auto-classify and to have an open Aspect mechanism would encourage leading-edge R&D organization to create new ones. It would also create a new classification industry for external web-services enabled classification services.
  
• Transformations and Content publishing: Take an un-rendered document, its components and its template and render it in a specific format. By having this as an independent Aspect, it would encourage the tools manufacturers to build their own renderers. The web-services that Adobe provides for conversion of Office documents to PDF could be converted to this relatively quickly.
  
• Translation: Upon save of a content, provide for automatic translation or routing of content for human translation.
  
• Tertiary or Off-line Storage Handling: Provide for the pre-fetch of content from off-line stores.
  
• Security Applications: Providing new and unique authentication and authorization techniques on fetch of content. Provide protocols for exchange of credentials on access of sensitive information which might include time-synchronized access keys, biometrics. Also provide for encryption and decryption of content in and out on each access. Enforce DRM throughout an entire business process.
  

Industry-specific Records Management Applications (B)

Meet the various industry-specific compliance requirements with applications designed to those standards. Enterprise applications can use the web services to store static records and content such as transactional documents and content. Developers can create complex life-cycles that determine movement of content through multiple repositories and stores. Specialized meta-data and security requirements can be layered on top of normal content services. A web service interface for records management with complete transactional control can guarantee information is verifiable, has not been tampered with, and, if necessary, has been completely destroyed.

• E-mail systems can confidently archive e-mail to web services knowing that the results will be vendor neutral.
  
• Enterprise application vendors, such as ERP and CRM, can store complex records and documents through web services that support customer ECM standards
  
• Vertical-specific Lifecycles: 3rd parties can develop complex metadata and lifecycle transition policies and archival mechanisms knowing that they will not be vendor-locked in niche markets
  
• Retention Policy Management is an A
  
• Retention Policy, Digital shredding, Higher-grained security
  

Content Administration Tools (B)

• Modelling Tools
  
• Aspect development
  
• Services: ECM
  
• Desktop applications
  
• Modern tools with Eclipse
  
• Workflow Tools
  
• Data types
  
• Configuration
  

Replication and Syndication Applications (C)

This is a general class of application that enables the movement of content from one repository to another. There have been some attempts to solve simple syndication in the form of RSS, but the class of replication required by enterprises and B2B are much more complex. Internal replication of content bases is something that only large organizations have been able to accomplish after a great deal of effort. By establishing a set of web services interfaces, it should be possible for 3rd party developers to simplify this process and provide whole solutions for replications. As the industry consolidates to fewer players, this should be an enabler to allow that to occur.

• Geographic replication: Sharing and synchronizing content bases between two or more geographic sites for the purpose of knowledge sharing or re-use of web content for closer proximity or translation.
  
• B2B replication: Create new classes of content services by allowing the external management of records repositories or shared business processes. Industry clusters such as aerospace or pharmaceutical could share and trade information with collaboration partners with the added security of web services security access without opening up firewalls.
  
• B2B syndication: RSS solves a set of problems for syndicating content, but more complex push and pull of information such information related to commercial transactions or process related information such as specifications or quality certificates requires more sophisticated handling of security, classification and lifecycle.
  
• Offline Synchronization - Tools to manage download sets for off-line users that provides both the content and metadata for accessing the content. Synchronize when next connected.
  

System Registries (C)

An enterprise registry is the corporate equivalent to Microsoft Windows registry. With complex applications and systems having no particular place to store configurations, these systems are proliferating XML files and small databases to store configuration details. The information has the same needs as content management: Querying, Categorization, Metadata, Meta-definitions, Versioning, Locking, Transaction Control, Configuration Management, Ownership, etc. Most enterprise applications can use a registry so that there is a well-known location. Information managed can include: app configurations, user preferences, parts specifications. Certainly fits the Information Lifecycle Management message. There is often a fine line between a registry and a directory.