Gartner have predicted the widespread adoption of Web 2.0 tools and techniques in the enterprise, but warned that insufficient focus on the social aspects may hamper its impact on business growth. IBM are also bullish about Web 2.0 in the enterprise, as Richard McManus notes
Gartner and others got it badly wrong in relation to corporate systems during the last boom (their formula seemed to be: By %year+5% the market for %new product% will be worth a squillion dollars.). But this time around, we don’t need Gartner to tell us what is obvious: the adoption of social software / Web 2.0 ideas by large organisations has begun, and it is going to be a game changing development
Demand is growing – companies are ready
Two weeks ago, I ran a long, discursive session at this year’s IPLC conference for information professionals, and was pleasantly surprised how people from a very structured background were able to get their heads around the potential benefits of social tools. It was great to have the chance to talk in depth about the use cases for social tagging in the enterprise and wikis rather than the usual hit and run approach of my conference appearances. What I found most encouraging was that even within the law firm library, a rarified bastion of structure and order, information professionals could clearly see the potential for social filtering, social bookmarking and emergent metadata. There were none of the false dichotomies that might have been raised a year ago between authority based on expertise and community-based authority; they were too smart for that and instinctively understood that both have a role to play
Then, last week, I attended the VNU Blogs and Social Media Forum in London, and presented a case study of our work with Allen and Overy to develop a lightweight social interface to corporate information. Not only was there a great deal of interest in hearing real stories about the deployment of social software inside organisations, but there was also a welcome absence of the more more cynical “it will never work” attitudes that are sometimes in evidence (dare I say it?) in the UK
This was a good conference, so well done to Lorna and Adriana for pulling it together, and the fact that it had three solid case studies of corporate social software adoption (Johnson and Johnson, DrKW and Allen & Overy) was impressive. Meeting JP Rangaswami of DrKW for the first time was definitely a highlight of the day – he is one smart cookie and a great ambassador for enterprise social software (and Socialtext specifically)
Sprinkled in between these conferences have been some very interesting private conversations with large, well-known organisations about how they can leverage the benefits of social software to address immediate business issues, rather than just for the novelty factor. Let me tell you: they are ready, and you might be surprised just how well they ‘get it’. They just need viable models for deployment, roll-out, development and support. We have been working on roll-out and adoption strategies for three years, and first shared some of this learning back in 2004 at Blogtalk in Vienna. More recently, Suw Charman synthesised some of the key factors in adoption on behalf of Socialtext in order to help increase take-up within DrKW. But I can’t help thinking this is not the only challange we face today
How do you deploy software that is constantly changing?
Whilst better adoption techniques for new software are important, I think we also need to consider the whole value proposition, and look at alternative ways of delivering value through social software inside large organisations that can take into account the rapid pace of change in this field. I wonder what enterprise social software will look like five years from now, and how it will differ from what has gone before
CNet recently hit some nails on the head – but also splintered the surrounding timber, it should be said – in Web 2.0 meets the enterprise
Speaking at the Software 2006 conference earlier this month, Ray Lane, former president of Oracle and now a venture capitalist at Kleiner Perkins Caufield & Byers, said that enterprise software companies need to retool their pricing models to compete against the largest providers.
“The entire software industry made one huge mistake in the late 1990s–it focused on buyers and not users,” Lane said during a keynote speech.
1990’s enterprise software was clearly a transitional phase. In both the private and public sectors there was a lot of pump priming going on, and vendors convinced buyers that even the simplest problems required enterprise-scale, expensive solutions. After the crash, the same functionality became available much more cheaply, if not entirely free. These days, we are able to think in terms of lightweight social software ecosystems, where people use what works for them, rather than the clunky dinosaur systems whose heavy footprints still leave their mark on the corporate architecture. As Peter Merholz put it, enterprise software is being eaten away from below
Voluntarism, diversity and demand-driven deployment
The importance of voluntarism is often missed in looking at the differences between old and new ways of connecting up the enterprise. The investment in enterprise systems was often calculated on the basis that everybody would use it, and many projects would fall back on coercion as a means of ensuring uptake, perhaps based on a perceived need to standardise or centralise. With social software, the opposite is the case, in the sense that projects only tend to work where they are demand-driven and people can choose to adopt new systems, rather than feel they are forced to. Ross Mayfield picks up some other aspects of this cultural change in his post about Enterprise 2.0 and the freeform advantage
In contrast to the centralising and specialising tendencies of old-style corporate systems, social software offers a more diverse approach to solving the same kinds of problems. We think of this as a benefit, because it helps create a rich web of links between people than can act as a kind of organisational immune system. I think JP Rangaswami is referring to the same thing when he talks about the anti-carcinogenic properties of social software. There are a range of structural and organisational barriers to realising this vision, as Ross points out, and in more traditional companies the cultural challenge is a big one, as Martin Duggage’s experience attests
Are we really going to solve these problems by simply selling software like vendors of old? Maybe so, if the software is smarter, and if we offer solutions that combine software and supporting services, such as consulting, training, etc. But I have a feeling that the sheer pace of change and speed of innovation in this area will force us to find mo
re imaginative models in the future. The three principal delivery mechanisms we use now have not changed much since the 1990’s
- Software as a product: the traditional business model that sells seats or licenses for packaged products, with regular upgrade cycles and some scope for customisation. There is clearly life in this model yet, especially since the advent of open APIs and data transport standards, which make the integration and interoperability job easier.
- Software as a service: usually remote-hosted systems that users or companies subscribe to, with upgrades and enhancements applied seamlessly in the background and with the provider taking responsibility for security, backups and maintenance. This works well, and has the advantage of making it easier to join up online systems with other internet-delivered services, but companies often have reservations about mission-critical or private data being stored outside their systems.
- Software + supporting services: a tried and tested model, which implies a closer relationship with the vendor or their systems integration partners. This gives the best of both worlds in some respects, making it easier to customise and integrate, but the customer has still bought a fixed package which will gradually become obsolete.
Rapidly iterating small things, loosely joined
How do we make a diverse and fast-changing software ecosystem digestible to large organisations? This is where the recent debate over Enterprise 2.0 vs Service Oriented Architecture (SOA) comes in. Ideally, we need a balance between pre-defined architecture and the emergent structure of social software. Interoperability may simply become too hard to manage if we rely exclusively on emergent structures, especially when there are few widely-adopted standards for APIs. The three traditional models of delivery mentioned above are probably insufficient on their own, and unless a single vendor owns the entire territory (which is both unlikely and undesirable), it is difficult to see how companies can pursue a truly iterative strategy that can benefit from the rapid pace of innovation and invention in this space using only traditional models for procuring software
As consultants not tied to a single product or indeed even our own codebase, useful though that is, we are able to keep tabs on useful new products, tools and connectors and help companies integrate them in the mix; but the problem is continuity. It is hard to manage an adoption strategy if the applications are changing all the time. So, what do we do
First of all, although we are working within the enterprise, not every application need be enterprise-wide. Some may be quite local in scope. There is nothing wrong with a diverse software ecosystem as long as there are some basic standards for interoperability and in particular the sharing of data. If a department or a team want to do their own thing with a specific wiki or blog tool, for example, then as long as they don’t expect full IT support and QoS guarantees then that should be OK
Second, I think enterprise social software consultants and developers need to be able to offer a blended offering that is much more flexible than traditional software integration and support. The main way I can see this happening right now is for consultants to work with a client company to develop and maintain a social software architecture that is a level of abstraction above the nuts and bolts of the purely technical architecture, based on objects such as people, groups, posts, tags, etc. This ‘glue’ should connect up individual product APIs, external service APIs and internal data structures and standards to provide a consistent mediating layer than is capable of supporting a broad range of social software / Web 2.0 applications
At the opposite end of the stack, I think we need to think about consistent interface design to avoid the obvious problem of users (especially the all-important second wave adopters) having to get to grips with too many different interface patterns, metaphors and identities. It will not always be necessary or desirable to create a unified interface for a number of different tools, but I foresee this being a frequent request from both users and buyers. In this scenario, plugging in different applications, services and data sources between a consistent interface and a common data architecture becomes a whole lot easier. We have talked about creating a lightweight social interface onto corporate systems, but perhaps this might also extend to other social software tools and services as well, with feeds and APIs doing the integration leg-work to allow what users think of as ‘the system’ (i.e. the interface) to float gracefully above the water like a swan
The goal here is to offer companies a fluid combination of tools, web services and bespoke systems to allow them to craft evolving solutions, rather than static systems that gradually fade into obsolescence. It is the ‘release early, release often’ principle of Web 2.0 applied to internal corporate systems
So, what combination of competencies and services are required to support this kind of offering? Here is an initial list, but I would be interested to see it challenged and developed further
- Software Architecture: knowing how to join up APIs, data standards, feeds and other sources.
- Information Architecture: IA applied to unstructured and emergent information and meta-data.
- Software Integration: maintain deep knowledge of the best available social software tools, their APIs, strengths and weaknesses.
- Systems Integration: ability to custom code connectors and other plumbing to connect up social software with legacy systems.
- Service integration: knowing how to leverage external (often free) web services to add value to internal enterprise systems will be a key competency and a wonderful source of added-value, initially in search and aggregation, but other areas will follow.
- Systems Development: knowing when and how to build in response to specific needs or a desire for customisation.
- Social Interface design: not just traditional interface design, but also an awareness of how best to surface and support social features through the interface, and all the usability issues this challenge implies.
- Business consulting: the traditional skill of identifying needs, deriving requirements and mapping these to the features of available tools and services.
- Participative design: mobilising users to help design their own solutions
- User engagement: training, awareness raising, support and mentoring
to delivering on the promise of enterprise 2.0 in the next five years at least
Better get back to recruiting 😉