Use cases for Alfresco.

This is a description of the general use cases for Alfresco as I see them. The audience for this document consists of IT/technical experts in a group focused on Java development. This is relevant to Alfresco version 3.

This is how I think about Alfresco: web client vs share interface vs web project vs external project.

Thank you to Jeff Potts - author of the Alfresco Developer Guide for reviewing this description and adding detail.

1. Alfresco Web Client is a highly customizable administration front end for Alfresco. The focus of this interface is document management (Alfresco objects are documents with added meta-data) and administration (of users/groups/directories/rules/workflows etc).
2. Alfresco Share interface is a much more customizable and user friendly Portal-like interface composed of Pages and Dashboards: we can create custom Dashlets (similar to portlets) that show up on the Dashboards. The user can add or remove dashlets. Site owners can add or remove pages. The focus of the Share interface is primarily team collaboration using tools such as a Document Library, Blogs, Wiki, Bookmarks, and a Team Calendar. With Share, users can provision their own team - or project - focused sites without the need for IT involvement.
3. Alfresco Web Projects are specialized folders with the Alfresco Web Client used to implement Web Content Management (WCM) functionality. Web Projects can contain any type of web assets. For example, we could create a Java web app of our own using any Java framework we want (Spring, Seam, Surf etc) and manage it via Alfresco WCM. The focus of this mechanism is developer created front ends (web sites) that are managed by Alfresco: we write web apps that do whatever we want and look however we want them to look and are versioned with and deployed by Alfresco tools. The web apps can optionally manipulate Alfresco objects in the back end.
4. An external project is any other sort of web application that makes use of the same remote APIs that the first 3 do, but is not managed by Alfresco. The focus of this mechanism is to allow any sort of front end (including Joomla) to use Alfresco as a back-end repository. Think of Alfresco as a database for rich or semi-structured content.

The real power of Alfresco is two fold: it allows it's own interfaces (point 1 and 2) to be customised using XML and Java and; it provides a number of remote APIs (such as Web Services, both SOAP and RESTful) so that any sort of project can be a client to Alfresco (point 3 and 4). Additionally, Alfresco provides functionality specific to managing rich content, such as:

• Full-text and metadata search (powered by Lucene).
• Extensible content model.
• Check-in/check-out.
• Workflow (powered by JBoss jBPM).
• Numerous options for getting content into the repository (CIFS, WebDAV, FTP, SMTP, IMAP).

Recommended use of Alfresco for an IT development company with Java developers skilled in Alfresco: keep it Java, but be aware that other technologies can be an Alfresco client too. Use the Web Client (point 1) and Share (point 2) interfaces for inward facing administration and collaboration respectively and a Web Project (point 3) for any web site that could benefit from WCM-specific functionality such as Sandboxes, Deployment, or (light) Structured XML Authoring. Use 4) when we come across a client crawling across the desert in search of a document management tool and literally cannot move off away from the rest of their stack or when the amount of customization necessary to the out-of-the-box Alfresco clients is such that building a custom UI on top of Alfresco would be faster, easier to maintain, or a better fit.