About 19 months ago, I worked with the founder of BinaryPlex and creator of HiveMind, Tim Bull, to put together the 10 architectural principles for an Enterprise 2.0 implementation. Based on our experience since then, we have updated these principles. You'll notice that now we've removed 'architectural' from the title and now formally using the Enterprise 2.0 keyword. You can read the entire story in Tim's blog entry.
So here they are:
Principle 1: User controlled privacy, common security
Social software is by it’s very nature social! While user privacy is important and should be available at their discretion, authentication schemes should remain based on common standards to promote sharing and connectivity. In general, open read access is preferred. Complex, multi-factor Enterprise SSO solutions are generally NOT very compatible with social media goals even when they do integrate (e.g. they often break RSS, prevent mashups etc).
Principle 2: Identity reuse
Options should be provided to allow users to share profiles and identity without re-keying lots of information, externally this could mean Open Auth schemes. In Enterprises, identity should be able to be integrated into directories and other authoritative user sources.
Principle 3: Ubiquitous Online Access
Social Software should be considered an online access solution (ie. limited facility required to access the information in an off-line capability), but access should be facilitated from multiple points including mobile devices, not just a particular browser.
Principle 4: Don't create silos
The value of a trusted network dynamically increases with its sizehttp://en.wikipedia.org/wiki/Metcalfe's_Law. Ensure that your implementation is targetting the greatest number of users.
Principle 5: Modular services with integration based on common Open Standards
Services should be designed to maximise simple re-use and allow users to mashup up modules to meet their specific requirements. Support for protocols like ATOM, RSS and REST architectures is key to enable this.
Principle 6: Configuration not Customisaton
Social Software is evolving quickly, extensively configuring the software, not customising it by modifying core elements allows rapid roll-up to future versions and capabilities as these improve.
Principle 7: Build for Rapid Growth
Social Software is difficult to control and pilot, so system design should allow for a rapid uptake and changing usage patterns. Build with added headroom above what you might normally size for a pilot system. If you're inviting 1000 users, allow for 2000.
Principle 8: By the People, For the People
Be very clear on the aim and purpose of the system and make sure you remove barriers to adoption that prevent and hinder people sharing information with each other. This includes promoting Internationalisation and Ease-Of-Use UI's (no-one ever received training on LinkedIn). The counter to this is that you have an Enterprise Centric Approach where the information and its use is driven and mandated by the "good" of the Enterprise which is quite different in principle. In social media implementations, Enterprises are the benefactors of the outcomes of human interactions; it's the people who are the consumers driving the benefit.
Principle 9: Limit Content Creation Work-Flow
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
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).
