Really and seriously, and I mean it this time.
In my work in the last twenty years on IP communications, the holy grail of the industry was to enable solutions that provide true any-to-any communications. That is – in the workplace environment – it would be possible for any user in Company A to talk to any user in Company B. And when they communicate, have a perfect experience without loss of features or functionality (a.k.a. feature transparency).
In other words, users would have the same experience communicating with colleagues inside their company, as communicating with colleagues outside of their company. While we have yet to achieve this Nirvana state, the industry has been working toward this with a set of capabilities that generally go under the term federation.
Cisco Spark provides the next generation of B2B communications using a capability we call universal federation.
It turns out that solving this is way, way harder than it seems. And indeed, if we look at the history of IP communications in the enterprise, it has evolved through two phases over the last two decades.
Phase 1: No Federation
In the beginning, there was nothing. Company A and Company B would buy IP communications systems, but they couldn’t talk together. The only real way to exchange communications between companies was to rely on one of the two worldwide interconnection services: the Public Switched Telephone Network (PSTN) providing basic narrowband voice, or email. It wasn’t possible to connect systems for video, instant messaging, or content sharing (outside of email attachments). Largely this was due to lack of industry maturity and lack of industry standards.
Phase 2: Bilateral & Multilateral Federation
A baseline set of industry standards matured to the point where we could achieve bilateral federation — interoperable communication between companies for voice, video, basic meetings, and instant messaging. The latter was definitely still complex since no single standard won.
Different vendors continued to implement different variations. As a result, if Company A deployed Vendor A’s messaging product and Company B deployed Vendor B’s messaging product, you might be able to get them to work – but it required manual configuration of the connection by both companies. And when it was configured, it was sorely lacking in features, difficult to troubleshoot, and hard to use.
Worse still, because it had to be setup by IT ahead of time, it completely eliminated the ability for end users to opportunistically communicate with each other. It also made it nearly impossible to communicate with consumers because they might not even have a paid collaboration product.
This was augmented by the arrival of federation clearinghouses which could provide multilateral federation – basically a star topology with the clearinghouse in the middle. This fixed some of the problems of bilateral federation – once you got interop working with the clearinghouse it would work with everyone connected to the clearinghouse. However, it still required configuration ahead of time, and did not provide the same set of collaboration features inside the company as outside the company. Today, most of the enterprise industry is stuck in phase 2 – bilateral federation. Business-to-business (B2B) collaboration remains a dark blemish on the success of the technology.
Fortunately, the consumer world began to explore a new model. Consumer tools did one thing really well: They enabled any user to talk to any other user. They did this by making it easy to invite people (through email or SMS), and making it easy to join (through a free app that a user could download, or use on the web). This enabled truly borderless communication. And it is why many of these modern consumer tools, like Facebook Messenger or WhatsApp, are now some of the largest communication fabrics on the planet.
With universal federation, a user of Cisco Spark in one company can communicate with anyone else, anywhere in the world.
Phase 3: Universal Federation
So, we at Cisco asked ourselves this question: Why can’t we take that same goodness and apply it to business communications? After many years of hard work, Cisco Spark provides the next generation of B2B communications using a capability we call universal federation.
Universal federation brings the goodness of consumer any-to-any communications to the workplace while providing the security and policy capabilities needed to make the tool suitable for business use. It improves on the prior generation of bilateral federation by providing three key things that weren’t there before:
- Zero setup or configuration
- Feature transparency
- Ability to communicate with free/consumer users
With universal federation, a user of Cisco Spark in one company can communicate with anyone else, anywhere in the world. If users at different companies happen to be using Cisco Spark, there is nothing to do. The IT admins don’t need to set anything up. There are no bilateral-peering agreements. There is no need for clearinghouses.
Cisco Spark uses work email addresses to form a unique global namespace across all companies. A user in Company A only needs the email address of the other user to message with them in a Cisco Spark space, or to place a call to them — that’s it. They’re communicating in Cisco Spark.
Even better, universal federation gives both users feature transparency. Feature transparency means that there is no loss of functionality communicating outside the company, compared to inside. As an example, while bilateral federation would provide basic instant messaging, file transfer often would not work. Or, the solution inside of one enterprise would have photo sharing, while the solution inside of a different enterprise would not. Connect them together, and there would be no photo sharing.
With universal federation, feature transparency applies to every single feature Cisco Spark provides. That means voice calling, video calling, spaces, content sharing, group read notifications, message deletion, and so on. This is exactly what users experience with consumer products. When Facebook Messenger ships a new feature, everyone using the app gets it and can use it together. Now with Cisco Spark that’s true in the workplace too.
Finally, Cisco Spark’s universal federation enables communications between an employee and anyone else in the world, even if that other person is not a paid user of Cisco Spark. This includes free users who use it just for fun, consultants at small businesses using it for work, or a group of users in a large company trying it out. This is because Cisco Spark provides a free version of the app that anyone can access from mobile, web, or desktop.
A free version that is exactly the same as the paid product – and that anyone can download and use — is essential for any modern global communications service.
Because the same technology is used for free users as paid customers there is once again total feature transparency. Every feature provided by Cisco Spark works for both free users and paid users. A free version that is exactly the same as the paid product, which anyone can download and use, is essential for any modern global communications service.
We’re really proud of Universal Federation, and have already seen huge usage of it. As one example, the majority of Cisco sales teams use Cisco Spark to communicate and collaborate with their customers, showing off the power of this technology for connecting people across boundaries. Sales people have told me that it has strengthened their connection with their customers, making them more responsive and able to share information more easily.
And so, the 20-year journey of the IP telecommunications industry toward any-to-any communication is finally coming to a close. The technology changes enabled by modern cloud software allowed us to imagine a different solution – universal federation – and with it, finally provide end users and IT admins alike the tools they need to do their jobs most effectively.
this seems to be as federated to me as AIM. sure anyone can use it for free, however I don’t see a way of creating my own spark server based on a public protocol, and then having that independent server federate with Cisco’s cloud. For example with XMPP i could configure my own server and it can communicate to other servers running an implementation of the XMPP protocol. A second example would be E-mail anyone could host their own email server and send email to other email servers.
The model you are referring to is what I call ‘bilateral federation’. And really, XMPP is the last tech that worked that way. Modern software has shifted more towards open APIs and free/viral clients, and that has proven to be more effective. It allows much faster innovation (no need for rigorous standardization which is slow) and greater functionality. Will you ever be able to run your own spark server? definitely never. It is way more complex than a single server. Its a large collection of interconnected microservices, operational tools, databases, and so on.
I fail to see how an open API = Federation.. Spark is still a walled garden. as you say no one else is going to run their own deployment/implementation of a published Cisco Spark protocol capable of federating with Cisco’s Spark deployment.
I am a fan of Spark however I find this article to be misleading in what Spark actually is. From your own description its an open API that enables developers the ability create user facing applications that interact with a Cisco deployment. What happens if Cisco decides to shut down this deployment? As you say nobody else is going to be implementing a deployment. The ecosystem dies instantly.. as much as i hate email i have to ask. Why is it that we are STILL using e-mail? The communication is based on many standard protocols that let a multitude of server implementations federate with each other enabling global interchange of communication. The email ecosystem is not dependent on one company maintaining the infrastructure for it to work so it remains. (as much as we may hate the thousands of messages that hit our inbox daily)
I think we are going to simply disagree on your presentation of Spark as ‘federated’.
Respectfully, making guests install your app to enter your walled garden isn’t really any kind of federation.
Users can also use the Web version of Cisco Spark on PC/Mac. No app needed.
It’s not about installing the app, its about the fact that you can be part of a [‘walled’] garden for free, without needing to install any infrastructure yourself and to receive a FULL experience rather than a subset of functionality. You can do this without the requirement for both parties to have spent money in acquiring the solution.
These are all issues with the current walled garden methodology employed by systems like Skype for Business.
I’m not a fan of ‘walled garden’ but this is essentially accurate. I dont think the term applies since traditional walled gardens have no APIs or ability to integrate/customize. That is not true for Cisco Spark.
I welcome the feedback! Of course I understand what you are saying. Gosh, I’ve worked on the ‘classic’ federation architecture for a very long time and understand it deeply, but as a result I also understand where it has not been able to deliver. Whereas, this model does deliver on the real goals – allow any user to communicate with any other user (including for free), have great feature interoperability, work across business and geographic boundaries, see great innovation. And, with APIs (which we have on Cisco Spark), allow others to innovate including customization. Is not that the goal?
Wrote this back in 2015 whilst still at Cisco, good to see an official version with more meat from Jonathan R.
Jonathan, what you describe is the new freeway, to connect multiple vessels of inter-exchanging ideas. The same way the US Highway systems allowed FedEx and UPS to build their business models on those infrastructure… Let’s go out and build the yet not realized on top… !
With universal federation, a user of Cisco Spark in one company can communicate with anyone else, anywhere in the world. If users at different companies happen to be using Cisco Spark, does not equal any-to-any
In what way is “communicating with anyone else, anywhere in the world” NOT any-to-any?
any platform is not accounted for, the goal should be Ubiquitous communications just like a cell phone, I don’t need to tell you what handset vendor to buy to have a conversation with you. I understand the need for it to be universal on Spark first from a commercial perspective.
Excellent synopsis, a point many can’t appreciate until they’ve struggled with other platforms. Very well articulated, thanks!
This is great news and provides lots of flexibility.
Today if we send an email to external customer, the email server ensures the customer still works at the company. In spark if we invite the individual using their email address and afterwards the person leaves the company, how does Cisco Spark ensure that the user can no longer use the login credentials ?
Jonathan, forgive me for being dense but this post seems off the mark to me. Realize I’m saying this as a Spark Ambassador whose nickname is “Sparky” because of my unabashed championing for Spark services. I’ve been using Spark since day one on 11/18/2014 (and love that I still have access to all those conversations on that day.) I’ve converted my family to using Spark, and we now plan family events in Spark spaces. I’ve used whiteboarding within Spark (and on the Spark Board) with my family to plan out floorplans for a remodel of our house.
The key word in that sentence above is “converted”. What you are championing is exactly the same as Skype, WhatsApp, and others in that anyone can SIGN UP for an account and communicate to anyone else INside the service. What you are saying feels like championing that you’ve created a new language that doesn’t require any translation between languages. All someone has to do is learn the new language and communicate in that language, and they’ll never need to bother with a translator again. A Universal Translator isn’t universal because everyone uses it, it is Universal in that it can speak to any other language.
Spark has immense potential and I continue to be a passionate advocator – but saying it offers Universal federation is only going to confuse your user base because of *their* preconceived notion of what that means.
Sorry, but what you are describing has nothing to do with Federation. All this is about, is that anybody can download a free app (or use a web browser) to have the same experience – and still they have to create an account.
Federation is about everybody using his own tools/apps to connect cross platforms and still has the same – his own experience.
Phase 4? Like PSTN I can use any device to call any device. When it will be possible to communicate (call, visio, chat…) between different software vendor? Instead to say “you must use MY solution” the world will be open to all… this is the original idea no?
Another very interesting point is missing: Chabot of course! We are in the digital revolution and nothing about that in your paper.
But Thanks for this beautifully communication tools that i use everyday!
We can dcome people such PSTN access through Telephoney Service Provider or. Through customer IP PBX, but universal federation very cool and this is what business need
Any vendor could claim – if all your users have my app/client then no need to worry about federation.
In your model I will still need apps for each person I want to communicate with that does not use/want Spark.
It sounds more like you want Spark to be universally used, than providing universal federation.
Universal Federation – Does it enables communication with Microsoft, Avaya, ALU …
Comments are closed.