We are considering implementing some Social Software so have drafted a series of Architectural Principles to help govern the planning for this. I tweeted on this and was followed up by @IdoNotes
asking if I was willing to share these, so here they are. I’d really welcome any feedback, good bad or in-different, particularly if you have implemented something similar internally.
I’ve removed a lot of the background information here and just shared the key points that are generally relevant (there are a couple of principles I’ve skipped which are just too specific to our circumstances). There are also other more general architectural principles that we would under-pin these with, for example “Buy Not Build” but these are not included here.
Similar to these, there are some related business principles we’ve proposed for consideration that are not technical in focus, I’ll share these separately.
Principle 1: Limit Social Software Data to Basic Security (Username/Password) Only
Rationale: Social software is by it’s very nature social! While user security is important, information requiring complex, 2-Factor security solutions is generally not considered appropriate for how social software will be used. In general, open read access is preferable.
Principle 2: Social Software should use Authoritative Sources for relevant Information.
Rationale: Internally we store a lot of information about users, including their phone numbers, contact details etc., we shouldn’t require them to re-key this and it should be updated automatically.
Principle 3: Simple Ubiquitous Online Access
Rationale: Social Software should be considered an online access solution (ie. limited facility to access the information in an off-line capability), but access should be facilitated from multiple points, not just a browser.
Principle 4: Global Sharing (largest number of users)
Rationale: The value of a trusted network dynamically increases with its size http://en.wikipedia.org/wiki/Metcalfe’s_law
Principle 5: Modular, Highly Integrated Services
Rationale: Services should be designed to maximise simple re-use and allow users to mashup up modules to meet their specific requirements. Common standards support is key to enable this.
Principle 6: Configuration not Customisaton
Rationale: Social Software is rapidly evolving, we should only configure the software, not customise it t allow rapid roll-up to future versions and capabilities as these improve.
Principle 7: Build for Rapid Growth
Rationale: Social Software is difficult to control and pilot, we should be prepared for a rapid uptake and changing usage patterns. Effectively this means build with added headroom above what you might normally size for a production system.
Tags: planning, principles, social software, web2.0
June 11th, 2008 at 8:13 am
Great post! You’ve hit the nail right on the head — mutliple times!!! Principle 3 is key… how easy is it to use Facebook and Twitter from a BlackBerry? Ubiquitous access *drives* social software adoption. That’s why I think Lotus Connections is great.. it ships with plug-ins out of the box for BlackBerry, Microsoft Office, Outlook, Windows Explorer, Lotus Notes, Sametime, and WebSphere Portal!!
Principle 6 it’s also right on! In fact, I’m blogging about this as we speak (stay tuned to my blog). As a developer, one of the reasons why I like Lotus Connections is because there’s so much you can do simply by configuration and NOT customization.
Here are a couple of principles I would add:
* Principle 8: Simple, easy to use UI (Google, Twitter have no documentation)
* Principle 9: No workflow to create content — requiring workflow, I argue, is a barrier to social software adoption
* Principle 10: Internationalization — Facebook has faced increased growth after they translated their UI into multiple languages
What do you think ?
June 14th, 2008 at 1:03 am
[...] first draft of the Architectural Principles for Enterprise Social Software was posted here. I invited feedback and was fortunate to get some comments from Luis Benitez, an IBM architect who [...]