Alfresco published its Team product a couple of days ago. Having some loose relationship with Alfresco, being a certified trainer, it caught me by suprise as we just had a Training Partner Symposium Update a couple of days before and Team wasn’t mentioned there.
Excitedly I opened the Alfresco Team site. iOS App, cool I thought, grabbing my Apple gadget, just to figure out no App in the AppStore yet. Digging into it I found it in the press release, will just be published beginning of July. So I wondered, why didn’t Alfresco wait until then to release Team as most of us most likely will jump on the iOS App at first glance?
After investigating the Team site a little further I liked the feature of being able to configure things from the UI. Being a developer I do not mind tweaking files but for most beginners it will speed up and simplify things.
Next I reviewed the license options and that was when I first started frowning.
- License different user levels: Perfectly fine.
- Based on the number of documents (content items): OK, but on what base do one decide if these levels are fine?
- Terminates on license expiration: Seems to be a pitfall. With the Community or Enterprise editions you get perpetual licenses, so you can work on your data infinitely, but with Team it will stop to work if your license expires. Read-Only mode might not be what you want, as for example removing and adding users will not work in this scenario.
As upgrading to the Enterprise edition is always an option the license issues above might not be too limiting for you.
A day or so later I stumbled over a Tweet regarding the customization regulations of Team. I just briefly reviewed the Team site and missed the direct link again. (Is it there?) Anyway I think here is where the limitations are going much too far!
These are the things you are allowed to do:
- Installation using the out-of-the-box Team installer, on the built-in stack components (no variation, no add-ons)
- Application set-up: helping customers set-up folders, sites, simple workflows and folder rules (from the Share UI)
- Custom Theme installation: CSS only, in the appropriate CSS folder
- Upgrade from Community to Team
- Upgrade from Team to Enterprise
There are already limitations pointed out in the text above, just look at all the things in parentheses.
I will go through the Non-Permissible Team service / customizations point by point:
Custom content models
This limits you to the build in models and Metadata respectively. And this is one of my biggest concerns. What distinguishes a DMS from a file server the most? Metadata! And you will just get Name, Title, Description and a few others provided by the Alfresco default set of Aspects, but nothing content or domain specific. Document classification by content types respectively document types you will not get. Everything is just Content. With 500 or so documents this might be fine, but actually I would rather not recommend taking this approach. This is no difference from using an out of the box Alfresco installation – no matter if Communinty or Enterprise edition. Retrieving information will be based solely on fulltext index, file names, title and description. You know the problems to google the wanted information, with many files there will be no difference.
Once you decide to upgrade to the Enterprise edition to gain full flexibility, who is going to update all the metadata for the existing documents? Answer for yourself.
- Custom form configuration to expose custom content models
Same as above.
- Custom business process definitions or workflows
Automation is a key for successful ECM acceptance. As advanced workflows require custom models, you cannot implement them anyway. Maybe Simple Workflows will do for you, but there are limitations and some of the following points will limit even Simple Workflows. (If you are interested about Simple Workflows and Advanced Workflows, you might be interested in my Learning Pathway presentation in September)
- Custom configuration or form configuration required to expose custom business process definitions
Same as above.
- Custom actions
- Custom configuration/form configuration required to expose custom actions to the rule configuration user interface
Custom Actions are an easy way to extend Alfresco. An example is for example zipping assets in the repository. As some functions are still missing in Alfresco including Team you do not have any means of extending Alfresco in this regard. As Share does not expose all public Alfresco actions, as the Explorer UI does, this limits your access to existing and future actions. As Alfresco is working on Share one can expect the missing action framework (UI capabilities) to show up in share as well at some point in the future, but currently you will not have any options to do provide the required extensions by yourself.
And as Share / Team lack some extension points yet, I can perfectly understand why Alfresco is limiting this currently. You cannot simply add new actions to the UI without tweeking the original files. Support intensive I assume, but you should consider this limiting factor.
- Configuration necessary to add custom data to the activity service
I do not see this as critical point, but you might have a certain requirement here.
- Any use of Team for WCM or public users (named users only)
Why no WCM? The limitation on the number of assets will limit the size of your site anyway, but I could live with this. But what if it comes to integrating your Team server into your web site by means of CMIS? Will this be prohibited as well? Named users! So most likely.
- Any use of Team for RM, beyond what is in the Team application
RM is an additional product anyway so I can understand this from a license perspective.
- Any use of the Explorer UI or document repository
Why this one? Sharing information between sites will be impossible. Why not using the Explorer? I cannot see a valid reason for this. Besides, certain actions are not being exposed to Share yet (only in rules). Therefore the Explorer UI would be an option for advanced users to access them.
As the Data Dictionary space is not accessible without access to the repository root, customers can not provide additional templates, e.g. for emails.
- Customizations or extensions to core repository tier services (Example: Changes to how the NodeService works)
- Custom installation of individual components/dependencies (application server, WAR, database, etc.)
- Customizations of the Team user interface beyond what is listed in the “permissible” section above
- Customizations that require extending some or all of an out-of-the-box web script on either the repository tier or the Share tier
- Multiple node configurations (multiple application servers, application servers running on a machine separate from the database server)
These points can be understood from a support perspective. In my opinion they do not imply additional limitations to the above mentioned points. The only thing that might be an issue is the database system. Why not allow using your enterprise database already in use. Some customers might not want to deal with databases at all, Team should be fine for them, but others might have sufficient database expertise in a certain system, but not necessarily in PostgreSQL. Besides of this, hot backup, continuous backup etc. might be supported by other systems in a better way as it does PostgreSQL. (I do not want to start a flame war here and I personally like PostgreSQL, but if you already have Oracle or SQL Server among others, you might have the tools and knowledge in house already)
Another point related to the database is upgradability. You can upgrade Team to Enterprise edition, but migrating your Team PostgreSQL database to your enterprise database system might not be as easy and imposes some additional work, tests and of course human resources.
- Clustered configurations
Shouldn’t be required for the user / document count you license with Team, from a performance perspective. From an availability perspective it is so. If your usage of Team is mission critical then you should consider Enterprise in favor of it.
- Exposing the Repository page through Share
Same as in Explorer UI above.
- Use of Team as a “starting point” for a custom content-centric application
This is just a logical result of all the limiting points above.
- Customizations that remove or work around any of the limits imposed by the Team license
No one want’s pirated software. Go with Community or Enterprise edition if you cannot live with the limits of Team edition.
- Any add-ons or customizations not listed under Permissible customizations
One thing I could think of here is using Team as a repository backend for a third party application by means of CMIS, WebService or WebScript integration.
Alfresco Team is a relatively cheap way to get a supported Alfresco system. The limitations though should be considered thoroughly. Especially when it comes to custom, domain specific metadata, automation and future migrations to the Enterprise edition, might using a different database system.
For partners and solution implementers I do not see a business case here but later migrations to a full ECM solution. But customers should be aware of that a later migration to the Enterprise edition might come more expensive as if directly using a system fullfilling their specific requirements. If it is just about getting a team or projects up to speed by providing a collaboration and content management platform Alfresco Team might be a viable option.
Team also introduces some new features, which look promising and I am curious what else to expect from the upcoming Swift release.