The folllowing principles have evolved from experience and a series of conversations with others in the Enterprise Social Media space, with special mention to Luis Benitez. Feel free to apply them to your own social media projects. I welcome feedback and comments on how they go and am happy to update as needed. I’d love to see these grow into a robust defacto list of principles that are applicable to most enterprise level social media projects.

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 as this promotes mash-ups and re-usability.

Principle 2: Social Software should use Authoritative Sources for relevant information.

Rationale: Successful Enterprise implementations should be able to re-use lots of information about users, including their phone numbers, contact details etc. Users shouldn’t be required to re-key this and the system should allow for users to update this directly according to business rules.

Principle 3: Simple, Ubiquitous and Adaptable Access

Rationale: Access to Social Software should be facilitated from multiple points, not necessarily just a browser, for example from within Mail, Instant Messaging, Mobile Devices etc. Software should adapt to how and where the user wants to use it, not the other way around.

Principle 4: Global Sharing (largest number of users)

Rationale: Metcalfe’s Law states the value of a trusted network dynamically increases with its size. This is a critical point for Enterprise solutions which can typically make the error of under-sizing pilots and therefore failing to demonstrate the real value. A strict application of Metcalfe’s law implies single global deployments of social software in preference to country based instances for large multi-nationals.

Principle 5: Modular, Highly Integrated, Open Services

Rationale: Services should be designed to maximise simple re-use and allow users to mash-up modules to meet their specific requirements. Common standards support is key to enable this.

Principle 6: Configuration not Customisaton

Rationale: Social Software, especially within the Enterprise is rapidly evolving, we should only configure the software, not customise it to 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 pilot.

Principle 8: Designed for the people

Rationale: Social software is designed to be used by people, not necessarily systems. Any Social Software service should remove barriers to adoption that prevent and hinder people sharing information with each other. This includes promoting Internationalisation, easy to use UI’s
(no-one ever received training on LinkedIn) and supporting open industry standards.

Principle 9: Authority should be devolved to the lowest common denominator

Rationale: Enterprise requirements for strong content-creation work-flow and other ways of limiting the exchange of ideas and information flow suggests 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 documents may be part of a conversation or are created as a result of one).