It’s been more than a quarter of a century since SIP promised an Internet-inspired open, creative, and interoperable world of high-value multimedia communications that would spell the death of the PSTN. In the last few years, WebRTC vowed to lower the barriers of specialist skills and complex development required to build rich communication services into any Web-based service. I don’t need to tell you that none of those things panned out exactly as predicted, and the mainstream UC world went about its business as usual.
But now there’s a third wave of change: the unstoppable digitization of workflows and the opportunities that creates for collaboration. Co-creation, co-editing, co-curation, co-piloting – these will finally break the mold. Traditional vendors’ myopic and walled-off strategies for how people ought to collaborate have been overtaken by collaboration in practice.
While the big vendors ponder how to react to this latest threat to their status quo, their users are improvising new ways of collaborating. They’re not waiting for permission. They’re not strategizing. They’re productionizing, iterating, and evolving.
As with all waves, there will come a crest and then a settling period of calm – a breathing space to allow some harmonization and reconciliation. By the end of that period, the world of collaboration will have changed – forever and for the better.
Changes for Users
Users will retain their power to innovate on collaboration experiences that remove friction and improve the outcomes of their workflows. They’ll be able to choose from a broader and more colorful palette of solutions from vendors both new and old – now richly interoperable with each other. And those users will once more embrace the IT professionals in their ecosystems, relying on them to streamline the process of creating, scaling, and quality-assuring their solutions.
For us to reach those calm waters, the old guard will need to shift their philosophy and open up their systems to meaningful integrations through APIs. While there’s nothing new about APIs in general, RESTful APIs specifically have transformed the adoption, synthesis, and proliferation of Web-based services. They made possible the blossoming of platforms that we now all take for granted, including Apple’s App Store, and Google Play. If you already know about RESTful APIs, skip the next paragraph – otherwise, here’s the essential context you need:
Imagine you create a new Web app – you intend it to be the ultimate competitor to Instagram. It’s critical that you make it simple for developers to create apps and integrations with the app so that they embrace it, without the need to learn new coding precepts and languages. And, when they generate code for browser A, then it should also work with browsers B, C, and so on. It’s the same story with smartphone operating systems. Using simple constructs like resources and resource locators (e.g., URLs) and familiar calls (”get”), RESTful APIs make it simple for an app to interact with a Web server. For example, to request information on a resource (”user”), find out its state (“new post”) and modify that resource, too (“like”).
How Might Integrations and APIs Change Things?
Challengers in the UC space – where interoperability means prosperity – have always offered APIs. New entrants have built their reputations by a) doing one thing well, and b) offering integrations with everyone else through RESTful APIs. Both approaches have fueled choice and creativity for user teams powering ahead with workflow innovations.
Traditional vendors have been more guarded and less generous. But I’m increasingly confident that, as this new wave breaks over them, they too will be faced with creating and publishing RESTful APIs for their full feature sets in order to remain credible and competitive. That’s a vast and positive shift.
Scenario Planning
So, what should you do, right now, to get ahead of that wave? This exercise is mostly about scenario planning. But it might be that you can already make significant improvements by leveraging the RESTful APIs that exist today.
1. Start with a workflow: Choose one that’s central to the productivity of a team or group in your organization. Definitely flowchart it. Check your understanding with the people it matters to most. Test your assumptions – or better still, make none to begin with.
2. Investigate systems:
- How many individual electronic systems does it require to complete the workflow?
- Which is the ”keystone” system, the one that hosts the focus of the workflow – the asset, the process?
- How many times does an individual need to take their attention off that system and shift focus to another in order to complete the next step in the flow? One example would be to look up from Google Docs, with real-time co-creation in full flow, to message a colleague about their last contribution. According to research, even brief mental blocks created by shifting between tasks can reduce a worker’s productivity by as much as 40%.
3. Investigate shortcuts:
- Where can you introduce simplicity? Look for the snafus. A simple example would be having to print off a digital form to sign it.
- Where can you introduce streamlining? Example: You have a diverse team of people in your marketing function. Online ideation regularly requires ad hoc group conferences. Some members reflexively use app A, because it’s brilliant on the tablet they’re never without. Some resort to app B, out of habit. There are almost as many options as people. But integrate a ”start conference” function in the keystone app and they’ll all choose the path of least resistance, thus simplifying their lives – and yours too.
4. Investigate available integrations and RESTful APIs:
- If you’re working with a challenger vendor, they’ll have a library of ready-made integrations that are continually expanding. Look here first.
- Next, look to your current vendors’ APIs. You won’t need coding experience to qualify whether the kind of integration you have in mind is supported.
- Get an opinion from a developer. There’s no specialist knowledge required at this stage. For example, any Web developer in your organization or ecosystem will be able to double-check your conclusions and offer further insights into the scope of possible integrations.
5. Plan, test and learn:
- It’s simple to test a ready-built integration with a subset of users. You’ll learn if it can achieve what you hoped, or whether you need a custom development. And you’ll be able to compare the costs of each against a realistic assessment of productivity gains.
- If you’re planning a development using an API, know that many of them come with a library of scripts for various calls and queries. Your developers can cut and paste those into their code.
- If your current vendor(s) don’t publish the necessary APIs, request one. And be prepared to introduce a new vendor if they can solve a worthwhile problem faster than your current vendor.
In summary, a wave of change is sweeping over our industry. We can’t resist it. We should embrace it. Challengers are already surfing. Closed, siloed solutions from traditional vendors will either swim or sink. RESTful APIs are the buoyancy aids that everyone should grab.
