When you work for a while in the software you get numbed to “technologies have come and gone…” occasionally though some become commodities and others trend setters. We have seen that with many products like Apache, Tomcat, Lucene, Drupal …etc that have stabilized and matured over the past years with the help of increased development from the open source realm. Wait! Did I mention the word “Open Source” and going to talk about the enterprise content management?

So without any more ado, we have Alfresco- catering to a rapidly increasing demand of the enterprise content management solutions which is built over the open source technologies such as Spring, Hibernate, and Lucene platforms. Having done years of Documentum development and several Alfresco projects of late, I think there are some interesting overlaps and differences of approach that I feel would make the developers get adapted quicker.

With the wiki site overwhelmed with Introduction, API’s, Development, Deployment and the Forums to answer all the questions regarding the issues faced during the project phase, I am here to talk purely from the developers perspective on what’s the key areas that I happen to witness the difference from the Documentum space.

The road map for my next series of blog is going to cover each of the areas mentioned below in more detailed, code abundant and developer centric approach which will answer the questions:

• Does this feature exist in Documentum or Alfresco or both?
• If yes, how different is the approach?

So with that preamble, and in no particular order, I give you my list of the key areas I got hands on and learnt how different Alfresco is:

• Aspects

Custom data model is the core for any enterprise content management solution. The use of “Aspects” as its core is the fundamental concept for content modeling in Alfresco. Although in the form D6, aspects was introduced, how different is the use and approach in Alfresco is something I will take a deep dive in my next blog.

• Web Scripts

Alfresco Web Scripts brings together the world of content repository and the web. Being a Documentum developer earlier ways of interaction with the repository have been either using DFC API’s or DQL. In Alfresco, Web Scripts provide RESTful access to content within the repository and we can build our own interface using java script. A custom move operation is implemented using the Web Scripts and the comparison of the implementation with the Documentum would be a something to be noted.

• Integration

On my last project, we had requirements for the customers to be able to permanently redact Personally Identifiable Information (PII) from existing documents stored in the repository and version the original document upon save. For various reasons, we decided to integrate the 3^rd party tool Daeja ViewOne module to provide this capability. I will discuss the topic as part of this blog series.

I started this series based on my experience implementing Alfresco projects and I invite you to share any of your experiences with any part of the road map wherein you run into interesting twists and turns? Did you drive off the road to get some help? I welcome your feedback as the blog takes its shape. See you all soon in Take 2.

• 62% percent of projects fail to meet their schedules
• 49% are over budget
• 47% have higher than expected maintenance costs
• And get this—25% are canceled before they are ever deployed!

If you’ve been in the software industry long enough, you’ve probably seen all of these things happen. The funny thing is, it doesn’t really come down schedule, cost, or requirements—it comes from bad design. When software companies think design, they’re thinking about contractual obligations and meeting commitments with their stakeholders. Here is a typical scenario:

Company wins contract. Client provides requirements. Company builds a solution, meeting the requirements. Testers validate requirements and application is deployed to a set of users. The users hate it and the client makes new requirements, company builds to those requirements, and the users hate the next iteration…and so on.

This can be resolved by utilizing user-centered design principles in your system development life-cycle. Software is not about code, it’s about people. Instead of our clients telling us what they want, we should be telling them what they need. As engineers, we can do a much better job building solutions then they can—that’s what they hire us for. To be successful, we need to incorporate user research, information architecture, interaction design, and usability testing into our process.

“Iteration 0” – 10 Tasks to Guarantee a Slammin’ User Experience

Let’s start with “Iteration 0”. This sprint is completely devoted to user experience. The point is to get out of habit of thinking of Java Beans and database schemas and start thinking about people. Here are tasks that need to be accomplished:

1. Gather assumptions and requirements. Take some time to get acquainted with the requirements and begin to make assumptions based on your experience with the technology.
2. Analyze competition. Familiarize yourself with the way your competition handles things. This is not necessarily the solution you should be striving for, but is excellent to have in your back pocket to show how your solution is better or to compare solutions to initiate change.
3. Understand goals & tasks. Comprehensive user research, interviews, card sorting exercises, and contextual inquiries help identify user needs
4. Develop personas and scenarios. Evangelize these with everyone on your team. They can be in the form of user stories, posters, work-flow diagrams, and profiles.
5. Build a content strategy. Find out what content you have, what needs to be developed, what needs to be expanded, and what can be cut. Also create a schedule for delivering those missing gaps.
6. Information architecture. It’s more than figuring out what content goes where. It’s also what information is most important to your users. Identify those needs and incorporate them into your design.
7. Prioritize features. One of the greatest advantages of user centered design is that you often find some requirements barely impact your users. Those requirements can be re-prioritized so you can focus on what’s really important.
8. Build wireframes and interaction designs. Setting expectations on functionality, how it should look, and how it should behave reduces future UI defects.  
9. Design a prototype. Build something you can take with you to road shows that incorporates both visual and functional design. Update the prototype during future iterations so you always have an accurate portrayal of what the product will look like at launch.
10. Validate usability. There are hundreds of techniques, including a usability inspection, paper prototyping, and eye tracking, but put something in front of your users frequently.

Points 8, 9, and 10 should be repeated throughout all future iterations until the project’s completion. When user experience drives design, you build products people love to use.

Solution-wise, this is actually good news for clients…in the longterm: richer functionality, better ease of use, tight focus on WCM, proven winner. Ultimately, WCM to EMC Documentum was the Super G to Tomba la Bomba: good, but not quite Aamodt-esque (apologies in advance for the indulgence in Winter Olympics rhetoric; seemed appropriate though given the wall to wall TV coverage and the three feet of snow we’re in here in DC). However, this direction does pose some intriguing questions:

• How tightly would Fatwire’s product work with EMC Documentum? Whose repository rules when it comes to WCM? Can the repositories truly co-exist merrily (possibly through CMIS)? Emmm…what happened to the whole one repository thing?
• What happens to clients’ existing Web Publisher (WP) based solution? Stick with it? Live without it? Migrate to Fatwire? Throw another 3^rd party tool in the mix? Start from scratch? Chuck the whole thing and Salesforce.com it?
• Operationally, who takes the lead, EMC Support or Fatwire? What about overlaps? How about licensing for existing solutions? Functionality vs. Risk?
• Technically, what’s the impact? What would the security model look like? How do you migrate?
• If the sunsetting of WDK and WP are both inevitable, what’s the recipe to upgrade? What tools and support will EMC provide to ease the process?

Of course, this is not an exhaustive list of questions and sharper minds than mine will surely have scripted-answers for them and more. History, though, tells me to tread with caution. Inevitably, enterprise class solutions are burdened with enterprise class complexity (and likely not just because of the technology). Time, budget, people, skills, political battlegrounds, management knowhow and many other factors may well play a part and tint the lens with which you view the questions.

So, where else might destiny’s child poke its nose? Of course, I don’t know for a fact, nor would want to speculate. However, looking at the gaps in the kitbag of some of the larger ECM vendors, I can’t help but wonder whether the next case management, records management, ediscovery, collaboration (read: Sharepoint) or content migration “partnership” announcement is just around the corner.

It’s simple.  The new Content I/O Suite.  Armedia’s Content I/O Suite allows users to collect information from all of those billions of sources, migrate it to the centralized repository in the company, and then, if needed, deliver that information to the different web portals that may need to view the information later.  In fact, it can even send the information to multiple repositories all from the same interface.  So what if Human Resources uses Documentum, and Accounting uses Laserfiche, and some departments have their own collaborative eRoom set up, but you just merged with another company who uses SharePoint and FileNet.  What if one user could capture the information coming in from the website, or through email, or through regular snail mail, and deliver it into the appropriate system, without that one user ever having to be trained in each of those systems?  Sounds too good to be true, doesn’t it?  Check it out at http://armedia.com/products/suite/.

-Kristin Evans