Compliance and Enterprise 2.0 - For the right reasons
Burton Group analyst Mike Gotta writes Compliance Doesn't Sell E2.0 … But It Should in his personal Collaborative Thinking blog. Mike summarizes a June 2009 E2.0 conference interview with Alexander Howard, quoted in Compliance concerns dog Enterprise 2.0 collaboration platforms. Howard asks:
Can an enterprise leverage collaborative software like blogs, wikis and microblogging platforms and retain compliance? It can, if collaboration platforms are built in-house from selected technologies, as opposed to an all-in-one suite from an Enterprise 2.0 (E20) vendor. Enterprise 2.0 compliance, in other words, is something best baked in from day one?
"The enterprise is tougher than consumer environments because of so many contrived regulations. There should be higher expectations of the enterprise 2.0 vendors to prioritize the features that will help enterprises manage compliance."
When asked if E2.0 Vendors "get" compliance, Sameer Patel said:
"Nope, not yet. It may be overkill, but spending 10 minutes with enterprise content management vendors or the IBM collaboration group exposed how little E20 has attended to this."
I certainly agree that Enterprise 2.0 compliance is something that needs to be "baked in" rather than tacked on. In my opinion, failure to address compliance and security can block use of Enterprise 2.0 technology in contexts where the greatest value, greatest potential for innovation - and most sensitive information - lives.
And I'll claim that Traction Software really "gets" compliance for reasons that accept, but go beyond regulatory requirements.
An ad-hoc wiki used solely within an IT department may not need much more than the basics. But to use Enterprise 2.0 technology widely within or crossing firewalls, authentication and security (including permission models around activity streams) are absolute requirements - particularly for highly regulated industries such as health care, pharma and finance.
Boundaries that make sense, WebDAV file versioning, Page / content moderation, audit trails and other compliance related capabilities are also crucial when working with external clients (including supplier and resellers as well as customers) or in contexts such as R&D or project management where the payoff for Enterprise 2.0 innovation is greatest, and the distinction between work-in-progress collaboration and an internal or externally binding agreement (or consensus) is important.
It's great to have wiki pages open for general editing wherever possible. It's also great to support the most open possible work-in-progress draft collaboration while creating a plan, budget, or other agreement that will be become binding on all parties when agreement is reached.
But it's also important to be able to distinguish pages that represent an agreement at a specific time - the approved budget, product specification, reseller agreement in a way that can't be confused with casual work-in-progress (or prankish) change.
People who want to be able to use wiki pages for reliable reference to the current approved budget, specification etc need to be able to distinguish the "last stable / approved version" and any work-in-progress drafts. Otherwise how would you know if a change that cuts the budget of a new project by 25% and schedule by 2 months is real, a proposed change, or just a prankish edit? If you're serious about using Enterprise 2.0 technology across the board, you need to address these issues to get work done, as well as satisfy the letter of the law.
Traction TeamPage has permissioned activity streams - for tag clouds, search results, email digests, RSS/Atom feeds and web navigation as well as microblogs. Features like WebDAV file versioning, Page / content moderation and detailed audit trails have been "baked in" to support use of Enterprise 2.0 technology in the context intentional as well as emergent practices.
"Baking in" support for these capabilities makes it possible to support wide open draft collaboration as well as "latest stable version" publication in the same collaboration space, as well as permission boundaries that disappear when you have permission to cross them but act as secure and reliable barriers when privacy counts. For example: clients of the same law firm can have separate spaces which become reliable barriers between clients but which slide down automatically for when members of the law firm with rights crossing all client spaces search, navigate, comment, link and tag anything they see.
Try to do this by slapping separate Social Software and ECM products together and you'll likely end up with something that works like JFK's description of Washington DC: "A city that honors the traditions of Southern efficiency and Northern hospitality."
We didn't go to all this work just to satisfy checklist requirements - I honestly believe it's what's necessary for widespread use and adoption of Enterprise 2.0 technology.
For more on related TeamPage features, see:
Boundaries that make sense - Patterns of collaboration.
Permissioned activity feeds - Including tag clouds, search results, email digests as well as rss / atom / microblog feeds
Moderation and work-in-progress collaboration - Enabling collaboration on content where consensus - or binding agreement - counts.
Audit Trail - Edits, tags, names, email and more.
And where this comes from Traction Roots - Doug Engelbart