What’s Past is Prologue
In the early part of the 1870s, cutting edge communication engineers dedicated their efforts to a device called “acoustic telegraphy”. At that time, Western Union had a virtual monopoly on telegraphy, with the obvious result being a very lucrative business for the company, and a very expensive service for their customers. An “acoustic telegraph” would be able to send multiple, separable Morse code conversations over the same wire, thus increasing the capacity of the network and lowering the operational cost of the service. Acoustic telegraphy was to be a layered service on top of telegraphy.
In 1875, a Boston University Professor named Alexander Graham Bell had the same technical interest, but for a different problem- he was working on assistive services for the deaf. He carried the tradition of his father Alexander Melville Bell, who pioneered the science of “visible speech”, a method of capturing the wave forms of speech in readable form. During the process, and purely by chance, Bell realized that instead of capturing voice to be read, it was possible to transmit voice vibrations over the wire, and for those vibrations to be replayed to the other party. Voila! Telephones! Telephony was a layered service on top of telegraph wires.
Businessmen quickly realized that two major developments had occurred. First, the monopoly on real time communications had been broken. There was now a practical alternative to Western Union and the telegraph machine. This alternative gave birth to what would be become a second monopoly: Ma Bell. Secondly, instead of relying on a rare skill of Morse Code, everyday people could be the senders and receivers of real time information. Thus the telephone network was born.
Now that voice could be transmitted over distance, and at scale, new problems needed to be solved. What happens when no one is there to answer the phone? What happens when you have one phone, but 1,000 employees? What happens when I am walking around, and not near the phone? What happens when machines communicate at a distance? In response to all of these new problems, communication engineers have designed voice mail, caller ID, switchboards, conferencing bridges, modems, satellites, computer networks, the Internet and cell phones.
As a communications designer, I see that the challenges of 1870 and 2015 have three important parallels. First, just like the fall of the telegraph monopoly, we are seeing the fall of the telephone carrier monopoly. No longer are they the only purveyors of real time communications, as companies like Skype and Facebook make real time communications possible without their consent or cooperation. In a twist, the primary mechanism isn’t voice, it’s text. When given the choice of voice, video or text, our children invariably prefer thumbs over lips and eyes. Text is simpler to scale, to manage, to translate, to archive, to search, and to connect to machines. Text is clearly not less important than voice or video, and in the end, might be the first and most important of the three.
Secondly, I see that restricting communications to a select “few” is a thing of the past. Back in 1875, only those trained in Morse Code could work a telegraph machine. Today, only those lucky enough to have lips could properly use real time communications networks. What is the solution when anyone with lips (me, for instance) want to communicate in real time with anything that doesn’t (like a business, a program or a process)? What is the standard solution when I need to have a real time conversation with my drug store to ask for a refill? Today the answer is as simple as it is inefficient— I use the phone to talk in real time with somebody else with lips… an employee of the company. The primary benefit is that they can reach the keyboard of drug store when I can’t. Until now, we only had real time communications between people, but now it’s time to support real time communications between people and machines.
This now reveals the pressing business problem. Just like (the artificial) lack of capacity of telegraph wires drove the invention of the telephone, we could now face the glaring inefficiency of communications when things with lips need to talk to things that don’t. Every time a contact center agent answers the phone, the employer pays — and pays much more than any layperson would imagine. Even the most basic live customer contact with a call center agent costs upwards of $5 dollars per conversation, normally much more. When that is multiplied by the millions of US call center agents who answer these calls as fast as they can, with obviously many more agents outside our borders, the size of the business problem is properly understood.
Thirdly, just like our experience in 1875, this uncovers a new set of problems to solve. What happens when you send a message to a machine? How will we broadcast information to large populations, and receive a large population’s worth of responses? The management of person and machine communications requires as many solutions as we have problems, and that’s a very large number. How can we possibly manage that issue? In the past, we developed voice mail and conferencing bridges as packaged solutions to communications problems. We are entering the world of messaging applications that solve specific problems when people and process communicate in real time.
My Personal Role
My goal in college was to be a communications engineer. I loved coding theory and abstract algebra; Digital Signal Processing was nothing short of magic to me. As I left college with a degree in Electrical Engineering, I took a series of positions as a communications designer, at first designing custom RF modems for the military at Signatron, just outside of the MIT Lincoln Lab Campus, founded by Julian Bussgang, and ground zero for the amazing generation of communications engineering from luminaries like Claude Shannon and AJ Viterbi. (That’s as old school, and as hardcore, as geeking gets.) I had the pleasure of designing first generation products in videoconferencing with PictureTel, and designing the first ADSL chipset at Aware. My teams commercialized the first SIP Proxy and SIP soft client when I was a visiting scientist at Columbia University. It was a fantastic time in my career; I feel like I was born to do this job.
Soon thereafter, at a critical juncture for me, my mind was caught by the Web 2.0 wave. As I understood what the young kids were doing, it became clear how fundamentally better the technical approach was than the approach of the traditional communications field. There was no question in my mind where the future lay… and it wasn’t to be delivered with the IP Multimedia Subsystem (IMS). I had a deep sense that, as an industry, we picked our direction very, very wrong.
For the last ten years of my life, I have designed Web as Platform applications called “mashups” that connect real time communications and process, people and programs. I wrote mashups in health care, financial, retail, government and military verticals. I wrote them using voice, video, text — I wrote them using APIs from every corner of the industry. Invariably, the results are beneficial to all concerned: efficiencies are gained, processes are not only sped up, but are of higher quality. And also invariably, every vertical that I examined had dozens of unique examples that show their efficacy, have surprised me in their elegance, but more so delighted the bottom line. In that time, I have noticed the patterns the mashups follow, what patterns I repeat every time I write one.
KISST: Connecting People and Process
Given these realities, the sheer size and scope of the problem, and what I’ve been trained to do since I was 18, I did what communications engineers do. I designed KISST, available now at http://www.justkisst.me.
KISST automates conversations with people over messaging, and then shares the results with any web-based backend, whenever and wherever humans use thumbs to communicate.
For universal communications at scale, and in real time, and for anything that can communicate, person and program alike, nothing beats text. Since text is the common language of both mankind and machines, with a fraction of processing required for voice or video, it scales in both capacity and solution set. Since it archives and is readily searchable, it is perfect for the modern data-driven business model. And since it’s preferred by humans who could choose any method of communications, it’s one of the few times where consumer adoption isn’t required —business adoption is required.
We believe that there is a market opportunity for as many messaging applications as there are electrical appliances, and for the very same economic dynamics. An appliance is a solution to a very particular problem, packaged in a way that can be sold and used by the people who have that problem. Thus we have hair dryers, microwave ovens, televisions, dryers and computers. KISST is not the only messaging application to be designed, not by a long shot. So, what’s the very particular problem that KISST solves?
KISST solves the not-so-simple problem of enabling mass-adoption of attaching people and programs. Essentially, no business, organization or government is text enabled, and one day, all of them will. This project will require massive amounts of upgrades, training, deep thoughts and hard work. Adding KISST to your business landline, or your Twitter, Facebook or Google handles is a simple and efficient way to connect a planet of people to a planet of process, programs and devices. It is designed to be simple enough for anyone to understand, but flexible enough so that it doesn’t paint you into a corner. Controlled enough for an eighth grader to configure, and solid enough for a carrier to adopt. Functional enough to stand alone, and extensible enough to power very complex use cases. Innovative enough to create a remarkable amount of value, and overlays on today’s technical infrastructure — and today’s communication habits. It’s a service that New York City can use with their iPhones, and that Bangladesh can use with flip phones. It’s a very reasonable first step.
Over the coming posts, I’d love to go over each of the design points of KISST, explaining things that we kept into the design (like network independence), things we pared down (a handful of conversations), and things we threw out (like natural language) and why we chose each. If you are involved with TADHack, we’re building our first mashup powered by KISST, showing the fundamental use of the product, and how it can be used to simplify things that used to be very hard. Finally, we have a great set of lighthouse customers, who are using KISST to solve real world problems, one process at a time. The best part of the KISST story are our customer stories.
And here we go…