A few weeks ago I learned about Open Atrium and its possibilities. I was immediately excited and also joined the Open Atrium translation and documentation sprint organised by the Dutch Drupal community. It’s truly amazing what Development Seed has created. It feels just right if you know what’s under its hood. And it’s only recently in beta!
So the last week of my summer job at Krimson involved with revising the documentation we pulled together at the sprint. This allowed me to look into Open Atrium a bit deeper. I went through most of its functionality and spent some time in the issue queue. I can only say that my excitement has grown even more. After hearing Lullabot‘s podcast about Drupal Distributions and Features — which I strongly recommend listening — and thinking about it, I would like to leave you with some reflections about Open Atrium.
On Open Atrium’s architecture
Open Atrium is marketed as Part intranet, part do-it-yourself project with a kick of open source hotness. First of all, it doesn’t really stroke with what an intranet is according to Wikipedia. It would be more of an extranet, since Open Atrium allows you to have public and private groups for your employees.
In fact, the above statement is nonsense if you consider Open Atrium a platform. A platform that can be used for many purposes.
For example, pingVision uses it to communicate with its clients. They share information about an ongoing project: hour reports, use cases, notes from daily scrum calls etcetera.
Because I deem it a platform, I also think Open Atrium has a solid, flexible architecture. There is enough level of abstraction and as I already argued before, Open Atrium is far more than just another intranet tool. It’s a platform, designed for change and re-purposing. It’s also pretty generic, and that’s why I believe it will maybe have a fundamental impact on Drupal’s future, in contrary to other distributions like Tattler that are destined towards more specific use. As always, it will be clear that the choice of using a certain architecture involves making trade-offs.
On Groups and team collaboration
Through the intelligent use of groups, different teams can have conversations by using different features (a blog, a wiki, a calendar, a to do list, a shoutbox and a dashboard are bundled by default). And of course, you can write your own features that can be turned on and off in any group.
The first thing you do when installing Open Atrium is creating groups. But what are groups exactly? Teams? Work spaces? Clients? People? One thing that really struck me after the documentation sprint was the fact that we entered departments to denote a group for our Paper Company. We were actually introducing organisation structure here. Our groups were the following: Human resources, marketing and infrastructure. And this was certainly not the best choice.
Seen from an enterprise environment or corporate point of view, what you want to do in your organisation is speed up decision making. When you have departments as groups and you want to have conversations across different departments this tool wouldn’t allow you. Communication would be very limited: department silo’s would reign and workers would stay in their cubicles. The Case Tracker feature would only be used for projects within one department and therefore Open Atrium would be useless if you had parallel working and cross functional integration in mind. In manufacturing they call this an over-the-wall approach; we design it, you build it. Nonetheless, working with multifunctional teams is simply an inherent bureaucracy problem.
An easy solution to the previous problem would be if you also created workspaces. Workspaces can be defined as a mix of people from different departments that collaborate, with regard to a certain project or product development. Teams, right? But what if I do want to have organisation structure in the form of groups, but also workspaces? For the time being, this process is not very straight-forward in Open Atrium. It would be simply inappropriate and even full-blown chaos to see these different types of groups next to each other. Indeed, the one group type involves functional departments, the other one involves inter-functional teams.
In order to really benefit from Open Atrium’s groups, I believe we need something like an Organic Group Construction Kit which allows you to build group types and group containers. You would also need to be able to set a group hierarchy. As far as I know, this hasn’t been tackled yet in the Drupal community apart from the Subgroup project. The previous, I consider a shortcoming. The end point is: you don’t want groups to be tilted towards certain uses. I believe the team terminology might be too specific and I strongly support the idea of group levels.
Open Atrium has tremendous opportunities for customisation and (re)configuration thanks to features. By default Open Atrium ships with a blog, a wiki, a calendar, a to do list, a shoutbox and a dashboard. Soon there will be Features servers where you can download contributed features. Currently I’m considering to host one as well.
Anyway, I’ve been thinking a lot about what kind of features that could be developed. To me features are functional. They implement one use case. Some features will be more generic than others, meaning that they will be enabled in more than one group. If you have groups that represent functional departments (e.g. marketing, human resources, operations) for instance, you could build specific features for specific uses cases. Human Resources could have selection and skills features, but also reward features. For accounting you could have a payroll, accounts receivable and accounts payable features. The thing is that these features are all specific functionality. They would probably only be useful in one certain group.
Also, you could build all kind of features destined at music artists or record labels for example: a discography, a tour dates feature and a ticket ordering feature. There could be all sorts of of Drupal flavours, right? However, features, in the context of Open Atrium and groups, are more likely to be generic. Think about a work planning systems, think about Victor Kane’s interesting Project Flow Tracker. And so on.
This brings me to my thesis. Features are different from modules. As already said, features are use cases and functional. In the context of Open Atrium they may be generic considering the context of groups. Today d.o. has an astonishing list of modules. Some are quite low-level, like Views, Panels and CCK. Others are more specific and high-level use cases, like the Calendar, Lightbox and Event modules. But maybe modules should be deemed building blocks and functional modules should be re-engineered as features in the future.
We’ll see how this emerges. It will definitely be interesting to see what will happen over the coming months.”,”A few weeks ago I learned about Open Atrium and its possibilities. I was immediately excited and also joined the Open Atrium translation and documentation sprint organised by the Dutch Drupal community. It’s truly amazing what Development Seed has created. It feels just right if you know what’s under its hood. And it’s only recently in beta!