In my last post, I have been asked what I would prefer for our internal social media solutions: An all-in-one approach, or a best-of-breed approach. This is essentially a question on centralization or decentralization of internal IT applications, and one I have a strong opinion on.

When it comes to social media, a decentralized approach beats a centralized approach: A collection of seperate tools capable of talking to each other is better than a monolithic all-in-one portal. Why? Let me count the reasons:

1. Cost

A centralized system – be it off-the-shelf or custom built – will always be a commercial one with a price tag. On the other hand, many decentralized tools are free of charge, because they are open source.

2. Dependency and Flexibility

A centralized system requires significant buy-in into one supplier’s solution and makes you dependent upon its approach, feedback systems, and update schedules (oh, and pricing too). Once you have settled for a solution, it will be difficult to switch to another. A decentralized approach gives you much more flexibility.

3. Quality

Improvements to decentralized open source solutions are community-driven. This means that the most pressing features and bugfixes are solved first. While centralized commercial solutions may use customer feedback systems like GetSatisfaction, the gap between users and programmers is bigger, requires prioritization, and the decision to implement features will pay regards to commercial aspects.

If a collection of decentralized tools is able to talk to each (more on that later), improvements will also be made on several fronts at once, raising the quality level within and between the systems.

4. People are used to decentralized tools

Think about it: If you use the internet, do you have a one-stop-shop solution for all the work you do? You don’t, as you simultaneously shop at Amazon, post pictures to Flickr, check your e-mail at gMail, chat on ICQ, sell a trinket on eBay, read your news on websites or on aggregators, post something on Facebook or Twitter, etc. Of course, similar applications can be condensed into one tool steering several ones (think: FriendFeed, Trillian, Yahoo Pipes), but we don’t have, nor expect, a Star Trek command central on our browsers.

5. History repeating

I challenge you to name me one succesful portal project at a major company – a useful one with integration of news and business applications, with customization and personalization. I’ve seen a lot of failed portal projects in the last 8 years: Why should the next be different and useful?

These are my 5 reasons. I’m sure there are some good arguments for a centralized approach, but I doubt they will beat the ones above.

What we should standardize

Choosing a decentralized approach does not mean letting everyone do what they want. The systems should have common underlying principles, follow branding (while not sacrificing usability), and be able to talk to each other. That’s why we have to standardize two aspects:

• formats: design guidelines in terms of look, feel, and programming (such as validated XHTML/CSS)
• interfaces: guidelines how to interconnect decentralized systems – every app should have an API, and allow RSS feeds.

That’s what we need to standardize – the roads, not the landscape.

It’s decentralization that made the internet, and Web2.0, succesful. Let’s apply the same principles for our intranet.

This work, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 2.5 Switzerland License.