Architectural Principles for Enterprise Social Software
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.