If I could wave my magic wand and make one major change to accelerate our work in the social business design field, it would be to Improve the often fraught relationship between ‘the business’ and IT departments. IT departments have to be one of the least fit-for-purpose areas of many large companies, often acting as unaccountable cost centre, technology police and service preventers, rather than business enablers. It is not all their fault, of course. In many cases, the business does not understand how hard it is to maintain networks, five nines uptime and centralised service provision across large networks of people who sometimes do not want to understand how to help themselves. It is a relationship ripe for change in the interests of both sides.
Over the long-term, I believe IT departments will split into separate functions with different approaches to service delivery, value and risk, rather than continue to be lumped together with the same risk-averse attitude that rightly surrounds critical systems being applied equally to personal devices and non-critical applications as well. I expect (and hope) that a proportion of the current IT department will move into the business and be given a brief to work as business enablers and innovators, rather than continue with a default setting of ‘no’ regardless of the cost to the business. Projects where internal IT and IT procurement add 500% overhead to technology delivery, and yet still manage to make the delivery worse in many respects, simply should not be happening in 2010.
In the short-term, we have to work with what we have got, and that means constructive engagement with IT departments, understanding their issues and helping to implement social technology in a responsible and business-like manner.
At the recent E2.0 conference in Boston, I presented some of our thinking about how to make this happen, which centres around the idea of technology layering and the use of APIs and data sharing to create consistency without uniformity:
Why is this important? Well, first of all, we must strive for a quality of user experience in the enterprise that is comparable to what we are used to with consumer applications. This is key to pushing forward self-service and it is necessary if we are to achieve the network effects that have proven so powerful outside the firm; but it is also about reducing training and support costs, and striving for simpler, cheaper, more flexible software rather than large all-in-one systems that are too expensive to throw away if they don’t meet changing needs. We are also spending too much time and money re-inventing the basics, because of an outdated obsession with standardisation and single platform plays, or just a mis-placed desire among low-level IT staff to build everything themselves. Instead of struggling to re-create basic social features, we should be deploying platforms and then treating them as a starting point for the development of smart, situated software that hone in on specific business needs.
As social business consultants, we want to be able to paint applications on a platform canvas, where all the basics are a given, rather than have to struggle to work inside an inflexible platform that supports little more than basic customisation. We can already see the need for much more advanced network navigation and awareness, discovery and personal productivity applications, but in most companies there is just not enough joined up social technology to make them viable. If we are to support employees in making sense of the emerging firehose of social data and signals, and turn them into action, then we will need these new applications soon, but IT blockers and the slow pace of implementation are holding this process back.
In the bad old days, our mobile phone applications came with the phone, differed wildly across platforms, and we couldn’t change them. These days, with Android and the iPhone, we expect to use a platform or OS, upon which we can load any number of applications that do very specific jobs, and perhaps look and feel the same across different platforms. We can treat the apps as throwaway, whilst the platform evolves more slowly through updates and point releases, but without needing to change the phone itself more than once every few years if we choose to.
The social layering idea is no different. At the base of the enterprise IT stack, we have expensive, slow-moving technology such as document management systems, ERP systems, databases and so on, which we might change every 3-5 years, if at all. They are good at the heavy lifting and underlying processes that many businesses need, but often very poor at user experience. Assuming these systems expose APIs and data sharing, which most these days do, we ca layer on a slightly lighter, slightly faster moving layer of social sharing capabilities such as social networking, collaboration, micro-blogging, wiki engines, etc., perhaps by using a dedicated enterprise social platform such as Jive, Socialtext or even Sharepoint if that is all that is available. But to really make the most of their features, it is often necessary to go beyond generic social tools and create much more business-relevant and locally-contextualised applications. For example, it is possible to use a wiki for co-ordinating new bids for a sales team, and if you give them one and a little guidance, they might make it work. But it is a lot more likely to succeed if you give them the Acme Bid Management System, which leverages the functionality of the wiki within an Acme-specific interface and workflow. If the wiki platform has an API, then you can do this and continue to iterate your application without having to mess with the wiki engine itself.
Leading social platform vendors Jive and Socialtext are both moving quickly in this direction with their respective announcements of a Jive app store and the Socialtext layering initiative to add to its existing strengths in API-driven applications. This is good, and it creates whole new opportunity for consultants and integrators to add value for their clients above and beyond the products themselves. Out of necessity, we began creating a meta-API above several of the most common social platforms to allow us to do precisely this, and I am very excited at the progress we are seeing when implementing this technique. In the future, I expect we will see a lot more focus on analytics, MIS/measurement, and individual productivity tools built on top of this kind of stack.
By coincidence, around the same time I was talking about this in Boston, my more IT-knowledgeable colleague Lee Provoost was sketching similar ideas at an SAP event in London, looking at the issue from the point of view of pace layering – in other words, coping with tools and platforms that have very different velocities of change:But, to return to the original reason for this article, the main prize is not just better apps for enterprise users, but rather a constructive, value-enhancing relationship between business and the IT department. If IT departments can continue to own and manage underlying enterprise IT platforms, but expose APIs and data, then business users can define, provision and run their own social applications at the top of the stack without having to defer to IT for every decision they make, or work at a slower pace and in a more constrained way than they need. Based on our experience of the difficulties of implementing social business tools within existing IT department frameworks and culture, this would be a huge win for all concerned, and where we are using this approach, we find it solves a lot of issues and concerns on both sides.