I’m hoping to get to EMC World this year and maybe check out the VIP treatment that being EMC Elect receives   There is also a private EMC Elect community that has been created and is supposed to have exclusive content.  I will let you know if there are some goodies in here that may inspire other folks to work to becoming an EMC Elect.  Newer members will be added every year, so if you did not become accepted this year, you have entire 2013 to work to gain Elect status.

This is similar to something I wrote over two years ago after attending EMC Writer’s Summit in NYC.  Back then we talked about what-if ECM became a commodity.  I felt that if 1) the technology was truly integrated into the platform AND 2) partners could quickly build/configure solutions AND 3) the solutions could be easily hosted, that there would be a large untapped market that EMC could capitalize on – specifically SMB.  I believe 1) is finally here with EMC onDemand, 2) is finally here with xCP 1.6 (and even more so with xCP 2.0 coming out later this year), and 3) is going to be here soon with Syncplicity integration.

A lot of the bloggers talked about the SSO, IRM, synchronization technology that EMC will get from Syncplicity, but what isn’t mentioned as much is the business knowledge that they bring to EMC.  Specifically, the operation costs and pricing model for cloud based solutions.  Syncplicity’s knowledge of freemium model as well as their 4+ years of datacenter operations is key to becoming competitive in the SMB.  EMC could benefit from developing a different licensing model for Documentum (possibly subscription vs perpetual license) to accommodate the minimal upfront costs that SMB typically require.

I’m looking forward to the day that we can offer our solutions to SMB!

After reading the Preface, I was excited to see three things about this book:

1) it covered the latest UI/application for Alfresco
2) it was written for a business user (not a developer)
3) it was second book written by the same group of people who authored “Review – Alfresco 3 Enterprise Content Management Implementation”

I enjoyed their first book and was looking forward to reading their “sequel”.  Before diving into the review, I want to acknowledge that the publisher invited me to review the latest book about Alfresco and provided me a free copy of the book to review.  This new book had a different spin than most of the other Alfresco books that I have reviewed.  The authors built a case study and provided tips on how to implement collaboration strategy for a company.  It was supposed to focus on business requirements and not delve deep in technical syntax.  Unfortunately, I was sort of disappointed on how much of the book followed this goal.

The authors started off good in Chp 1 by describing various collaboration features in Share and by framing the case study around developing a marketing site created for a new product.

Unfortunately, Chp 2-4 diverged from the business user perspective and covered installation, architecture and system administration.  The same information has been presented in other Alfresco books.  It was very similar to reading a sequel that spent the first third of the book rehashing what occurred in the original book.  If this is the first Alfresco book you buy, then the material is relevant.  However, I doubt anyone who investigating Alfresco as an ECM platform will only buy this one book.

Chp 5-7 covered site management, collaboration features in more detail, and the importance of document library.  The authors did a good job setting up the case study from a screen shot perspective, but did not really relate how business requirements dictated what features to use and what settings to configure.  A technical book oriented towards developers typically gloss over the business requirements in lieu of focusing the technical aspects of the product or feature.  I feel that the authors did exactly this and loss sight of their original goal of writing for a business user.

Chp 8 was the best chapter in the book.  It covered how to implement workflow within Share and it presented the content in terms of the use case.  The authors created very good diagrams that defined the marketing business process.  They describe various review states (or subspaces) and how various users of those review groups participated in the workflow.  The diagrams presented were well thought out and conveyed the business requirements in a way that most business users would understand.

Chp 9-10 covered advanced features and deployment of Share.  Again, I feel these chapters may not be as useful to a business user, but I did learn something new about Share – there is integration with Google Docs.

In summary, I really liked the idea of the book; however, I was disappointed on how the book turned out.  Most books about technology contain content provided by software vendor.  You have to; it is part of educating your readers on the software.  My personal perspective is that a good book has a well define audience and presents the material in a manner that he/she can understand (e.g. beginner developer, advanced developer, or non-technical user).  This book contains all the relevant material about Share, but does not live up to the potential of what it could have been.

In parting, I know sequels can be harder to write, so I hope I do not discourage the authors in continuing to write more books.  They know the material well; they just need to tweak the presentation.

1. Single copy – Most emails tend to have multiple recipients (from either to, cc, or bcc).  So, if retention rules are defined for multiple users, you can potentially have duplicate email records.  However, most email archiving products do a good job de-duplicating emails, so you do not have multiple copies of the same record.
2. Categorization/Classification – Retention in records management is typically associated with a fileplan.  Based on content of document, process in which document is derived from or applied to, or the creator of the document, document is classified to appropriate record series in the fileplan.  The challenge with email is that its typically short, so there may not be enough content to truly classify it correctly.  Some emails can be categorized to a process (eg invoice sent), which can then be correctly placed in the appropriate record series and retained for the appropriately amount of time.  Most emails have to categorized based on who the owner is (eg CEO) and retained for generic amount of time.

   Some email archiving products allow you to define rules to better categorize emails; however, this requires “true understanding” of business.  For example, if you define a rule to “delete emails immediately with subject contains party”, this would do a good job filtering birthday party invites; however, if your company is in the business of hosting parties, you would not want to use this rule for categorization.  Other email archiving products use heuristics to analyze sample of your companies email and you teach it what kind of emails should be records and what kinds of emails can be considered non-records.  The challenge of heuristics is that you need a good sampling, which tends to require a large sampling of emails.  Plus, you will need to train the system on how to categorize.  Training heuristic system is easier to do then developing rules for categorization; however, gathering a good sampling is typically harder than using examples in developing rules.

There are a few vendors that apply both strategies of categorization – use heuristics first and then apply rules for categorization.  I believe this is the best approach in solving a classification problem with limited content.

3. Owner of email/record – Whereas a document tends to have a well-defined owner/creator, the owner of an email can be vague.  For example, an email author may send request to a group of people for the latest version of SOP document.  Several people reply with different versions of the desired document (due to lack of version control or use of Content Management System).  Assuming that the email is categorized based on email authors, emails for different email authors may be different based on their roles (eg CEO emails retain for 7 yrs, everyone else 3 yrs).  Therefore, you can have a situation where the same SOP document gets retained for different times because of how email categorized.

This challenge is not as much a technical issue as how the rules of classification are defined.  In the world of records management, a document has a real owner.  The request for a document is not typically treated as a record itself, so you do not run into these kind of issues.  You may encounter that a document may fit into multiple record series, but at the end of the day, the records managers decide where the document fits most appropriately.

4. Versioning/supersession – SOP documents typically have a shelf-life and get replaced on a periodic basis.  When a new version of the document is declared as a record, the new record supersedes the old record.  This is a straight-forward concept.  How does this apply to email?  Emails are normally not versioned; you typically have an email chain going back and forth between various users.  Which one of the emails should be the record and which should be superseded?  The reality is that supersession does not really fit with emails (hence title of the blog post).

Some vendors treat email chains as single chain and applies a single retention based on the earliest or latest date of the email chain.  The idea of superseding email does not really exist in email archiving products.  Again, this is not a technical issue as much as emails are very different than typical document/records.

I strongly believe that companies need to include email as part of their overall records management strategy; however, their current records management system may not be up to par to handle email archiving.  Likewise, email archiving systems should not be use as records management system.  I feel that in most situations, a company needs both types of systems, but they also should have a well thought out unified records strategy that includes both documents and emails.

Johnny Gee

It seems that I have become a regular reviewer of Alfresco books for Packt.  The publisher invited me to review the latest book about Alfresco and provided me a free copy of the book to review.  I was somewhat excited about reading this book because the purpose of the book was to provide “minimum theory…maximum action.”  I assumed that this book would be filled with tons of sample code that I could use on a regular basis.

If you are a first time Alfresco developer and have not read many books on Alfresco, Snig’s cookbook is an excellent reference.  If you have read other Alfresco books, about half the material will be familiar and is what you would typically find in Alfresco tutorial.  If you have already implemented several Alfresco applications, go directly to the workflow chapter; you probably already know the solutions/sample code presented in the rest of the cookbook.

Chp 1-5 covers the various features of Alfresco from both a user and administrator perspective.  Skip these chapters if you are familiar with Alfresco already.

Chp 6-7 talks about simple UI customization and how to configure custom content types, aspects, and search.  Again, there is nothing new if you have played with Alfresco before.

Chp 8 introduces Alfresco JavaScript API.  This is where the cookbook starts to shine.  Snig approach to presenting problems to solve and solutions/sample code to solve involves the following:

1) Getting Ready (intro to the problem)
2) How to do it (instructions/solution overview)
3) How it works (technical explanation of the solution)
4) There’s more (optional supplemental info).

Sample code is great for users who are not interested in learning to build Alfresco solutions.  Snig’s “How it works” section presents the secret sauce on what the sample code does and how it solves the problem.  I strongly believe that explaining how to solve the problem is more valuable than the actual solution itself.  Snig does a good job of explaining the solutions he presents throughout the book.

Chp 9 goes into more detail about FreeMarker templates.  If you haven’t worked with FreeMarker templates, Snig presents plenty  of examples that are useful from a day-to-day perspective.

Chp 10 discusses web scripts provided by Alfresco.  These scripts are built as RESTful APIs and can be customized without java or Eclipse.  Some of the solutions include:
1) Show home details -> good for describing user/project profiles
2) Display details of document (via search) -> good example of how to render in JSON
3) Sending emails using mail templates -> details how to include ticket in calling another web script, so that user doesn’t have to enter his credentials again.

Chp 11 is best chapter in the book; it covers how Alfresco uses jBPM from top to bottom.  Snig presents an excellent example of how to build a workflow using SDLC as sample process.  He then describes how it works in great detail.  For this chapter, I wished he covered how it works before how to do it.

Chp 12-14 covers additional features of Alfresco, like integration with Outlook, email, and file server.  These chapters detail how to configure these features and do not provide samples on how to customize the integrations.

I would recommend this book to someone who was asked to start building a prototype tomorrow.  If you are planning to learn Alfresco as profession, there are other books about Alfresco that cover the theory in more detail.