The 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 deals with Lotus Connections who also then commented and expanded on these further in his own blog with a post 10 architectural principles for social software. I’m going to carry the conversation one step further and refine them again now.
First, a little bit more background. When we (myself and the team I work with) define architectural principles, one of the good pieces of guidance we use in drafting them, is that each principle must be able to be expressed as a counter argument. Why? Because this is something that guidance is therefore required on, and will generate a conversation with the business and help get to the root requirement. If no conversation is required, then it’s probably not a principle (it’s more likely to be a fact). The proviso I’d put around this is that one organisations “fact” will be another organisations “principle”, so you need to consider your requirements and if these principles here apply. For example, the Principle “Configuration not Customisation” does have a counter in our business where they would consider highly customising an off-the-shelf solution and have typically done so in the past, whereas in your business, it may not ever happen.
Applying this rule, I think that we can further refine two of Luis’ principles into one, because at the moment, while they are sound, they are also (at least for our organisation) “fact”; i.e if Internationalisation was available, no-one would say “don’t do it”, and equally with the UI, no-one would say “lets design a complex UI that requires lots of training”. So with that background, here are my 9 core principles from my original (7) and then Luis post (3 combined down to 2) plus a draft of a new one to bring the total to 10!
All this needs now is a review of a few eyes and I think a re-order perhaps to reflect importance a bit better.
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.
Principle 8: By the People, For the People
Rationale: Social software is designed to be used by the people and for the people, we must be very clear on the aim and purpose of the system and remove barriers to adoption that prevent and hinder people sharing information with each other. This includes promoting Internationalisation and Ease-Of-Use UI’s which facilitate easy use (no-one ever received training on LinkedIn). The counter to this is that we have an Enterprise Centric Approach where the information and it’s use is driven and mandated by the Enterprise which is quite different in principle. This is not saying Enterprise Information has no place, it does (see Principle 2), it just means that the Enterprise is not the end consumer of the information (it may be the benefactor), people are.
Principle 9: No User Content Creation Work-Flow
Rationale: Social software solutions promote the sharing of information and activities, deriving value from the flow of this information through the eco-system. Approval processes hinder the value of this conversation, reducing the incentive to participate in the system. Strong requirements for content-creation work-flow potentially suggest that either social software is the wrong solution for the business, or that the business is not yet culturally aligned with social software.
Principle 10: People not Documents
Rationale: Social Software is about people connecting to people and discovering and carrying on a conversation. It’s not a document centric publishing and storage platform (although it may potentially extend to that if documents aid the conversation).
