August 8th, 2014

Notes from the W3C Workshop on the Web of Things

W3C LogoAt the end of June, I had the opportunity to attend the W3C Workshop on the Web of Things, in Berlin. I saw some fascinating presentations and had some equally engaging one-to-one conversations. This was a great opportunity to learn about some new innovations around connected devices and the Internet of Things.

In particular, I was very intrigued by the WAMP Protocol, which I had not heard about before attending the workshop. I subsequently contacted Tobias Eberstein from Tavendo, who is one of the key maintainers of WAMP. We had a very interesting conversation about some of WAMP’s unique concepts, which I will talk about more in a future blog post.

In the meantime, here is a quick summary of my notes from the presentations I attended and the conversations I had at the workshop. If you would like to get more information on any of the emerging technologies outlined below, you can view some of the workshop presentations here and here.

Siemens Smart Grid
Siemens has chosen to use the XMPP messaging protocol as the standard for its smart grid technology. XMPP is being used because IoT, like online messaging, is based on distributed collaboration, in real-time, spanning multiple domains. In this sense, IoT is fundamentally closer to social media than it is to SOA-style Web services.

Siemens Connected Car Authentication
Siemens also presented an IoT authentication method, using the connected car as its real-world example. In this method, security concerns are separated between a Web API server and the car’s backend server. Client apps communicate with the car indirectly, via the API server. Sensitive vehicle data cannot be accessed directly via the API server.

EXI for Long-Lived Connected Things
Waste could be a serious problem in IoT. With billions of connected devices, we can’t afford to have anything becoming obsolete too quickly – ideally any given device should last at least five years. The Efficient XML Interchange (EXI) format addresses this by using XML schema to enable binary coding for extensible message formats.

Echonet Lite for Client-Side Energy Demand Management
The Echnonet Lite protocol allows smart meters to communicate with home appliances, enabling smart home energy management. Echnonet Lite is UDP-based and has more than 80 device models defined. It is already widely used in Japan and is starting to gain significant traction outside the Asia-Pacific region.

Sony Web API Server
Sony is working on a Web API server for the Android platform, using the previously-mentioned WAMP protocol. WAMP, which is essentially a sub-protocol of WebSocket, combines RPC-style and SubPub semantics.

IBM NodeRED
IBM’s NodeRED is an integrated development and runtime environment based on node.js. In the NodeRED environment, it is possible to design integration flows without resorting to code, by graphically snapping together components. NodeRed also allows the use of JavaScript to act on or transform data in flows.

July 17th, 2014

API360 Summit – Washington, DC

API360Since the API Academy was founded two years ago, we have had the pleasure of helping numerous organizations and industry leaders succeed with their API programs. Through this experience, we have learned at least as much as we have taught – and we recognize that continuing this collaboration is vital to furthering the field of API strategy and design. Also in this time, we have observed a growing recognition that a holistic approach to APIs is needed in order to achieve maximum benefit.

With all of this in mind, we are pleased to announce our API360 Summit series. These complimentary one-day summits will bring together industry leaders to examine APIs from every possible perspective: business and innovation; architecture and design; applications and trends. Most importantly, these events will provide attendees with up-to-date, actionable information they can start using as soon as they walk out the door at the end of the day.

Our first API360 Summit will take place on September 12 at the Newseum in Washington, DC. We will be featuring a range of speakers with first-hand experience of how APIs are impacting organizations across the public and private sectors. There will also be panel sessions examining pertinent topics like using APIs in open government and exposing APIs to external developers. And there will be plenty of opportunities for interaction and discussion.

For more information and free registration please visit the API360 site.

July 16th, 2014

The Maker Manifesto

Written by
 

The Maker ManifestoOne of the few perks of having to travel for work is the opportunity to read books (remember those?), from cover to cover, in one go. I recently had the chance to read The Maker Manifesto by Mark Hatch, the CEO of TechShop. It is one of those rare books that make you want to jump up and start “making” something (which isn’t very practical when you happen to be on an airplane, I admit). But I will talk about this more in a minute.

I’ve been struggling lately with the overbearing Internet of Things (IoT) coverage and hype. All the ingenuity and potential seems to becoming increasingly directed towards creating yet another platform for advertising. Most if not all IoT presentations start out by citing the same one or two studies talking about billions of devices and trillions of dollars just beyond the horizon (I call it the x+1 syndrome – it is always one year out). This is usually followed by promises about how this or that gadget/protocol/framework/alliance is going to liberate us from our earthly burdens like switching off lights or turning on the coffee maker.

Of course, everything is open to debate but I personally prefer my simple wall-mounted light switch over having to pull out my smart phone and tap on an app.

In these challenging moments it is refreshing to remind myself what has drawn my interest to IoT in the first place. For me, the Internet of Things is simply a term describing a much deeper and more fundamental shift in society. And this shift – or rather the anticipation of this shift – is being called the “Internet of Things” in IT circles, the “Industrial Internet” by GE and the “Fourth Industrial Revolution” (aka “Industry 4.0”) in Germany. Meanwhile, The Economist and the previously-mentioned maker movement have been throwing around the term “artisan entrepreneur”.

The common theme across all of these manifestations is that technology is democratizing the way things are made. Maker-centric technologies like 3D printing could vastly increase the number of people who have direct access to the manufacturing process – which could be truly revolutionary.

To catch a glimpse of the future, look no further than Etsy, which has made a billion-dollar-plus business from selling individually-made crafts. And for what it’s worth, Etsy’s engineering blog is one of the finest – I love their mantra “Code as Craft”.

This brings me back to The Maker Manifesto. While Mark Hatch is coming at it from a maker perspective, someone could (and maybe should) have written a very similar book from a software perspective. Cloud IT, HTML5, Javascript, Node.js, Raspberry Pi, Arduino, GitHub – these are the tools for the coming “software maker” revolution. Both books would meet where our ability to create, to make is only limited by our imagination – and where individuals will be able to provide viable alternatives to industrial-scale production. It is my conviction that the Internet of Things describes the “place” where both software and hardware makers will meet. Having skills in both areas will become key to unlocking IoT’s potential.

It’s worth noting here that Hatch points to an emerging type of company that is built on software but reliant on a physical delivery platform. This is particularly prominent in the “sharing economy” created by companies like Uber, Airbnb and Getaround. It is a demonstration of how combining software with physical things like spare rooms and idle cars can be hugely disruptive to the way real-world products and services are delivered.

You might wonder where APIs are in all this. Well, just as cloud computing commoditized access to compute and storage resources, APIs are democratizing access to all manner of data and application functionality. Organizations across the private and public sectors are using APIs to open their information assets for use by external developers. In turn, these developers are creating apps that make previously siloed corporate information assets available to a vast number and variety of people.

As new hardware and software technologies combine with IoT and the good-old-fashioned physical world, APIs will be the glue that holds everything together. And – of course – API Management technology will be there to make sure it all happens securely and efficiently.

July 15th, 2014

Beyond the CMS

NPR BuildingOn April 22, 2011, I was in Washington, DC, preparing to start my new job at NPR. At that point in my life, this was pretty much my dream job, so I was very excited and a little nervous. I did a lot of thinking that night and the conclusions I came to eventually became the basis of NPR’s technology strategy. I recently had a chance to share my thoughts from that night as part of a talk at the Integrated Media Association’s iMA 2014 conference. Here are the edited highlights.

The basic premise I started from was that all content management systems are fundamentally broken. This may sound a little harsh but I feel able to say it because I’m part of the problem – I’ve built content management systems for organizations across the public and private sectors, so I’m pretty well placed to tell you that no available CMS platform is architected for what publishers – particularly news outlets – truly need.

Most content management systems were designed years ago, for a much simpler world. We now live in an incredibly fragmented and complex world. Any piece of content tends to be sourced from a variety of places and published across a range of old and new media channels. Throughout this complex process, everything has to work seamlessly. The margin for error during breaking news or major events is pretty much zero.

In this context, what do publishers actually need from a CMS? They need:

  • An easy way to connect with many news sources
  • The ability to push content across a variety of channels
  • Guaranteed availability and scalability

So, how do we build a CMS that actually addresses these needs? To my mind, the solution has three key components. First and foremost, the whole architectural approach must be based on APIs. Second, it must specifically use hypermedia APIs and finally, the APIs must be what I’ve been calling “linked APIs”.

1. APIs First
APIs represent the only universal way to connect anything on the Web to any other online thing. Unfortunately, since we started the Web in a desktop-centric world, APIs were an afterthought. Historically, we used to build a Web site and then maybe also add an API, as a window into our content.

This is the wrong approach. Your Web site is just one of the destinations for your content. Increasingly, it’s not even the most important one, since mobile viewership is clearly on the rise. Don’t treat your Web site as special. All your content and functionality should be put into and delivered through APIs.

 2. Hypermedia
Publishers need things to just work. They don’t care about the technical details; they just can’t have their services go down at any time – so, scalability is paramount. And how do you ensure scalability? As I’ve pointed out before, the most scalable network ever created is the World Wide Web and the secret to the Web’s scalability is hypermedia.

Hypermedia is any type of content that not only carries data but also links to other documents. The hypermedia type that is most fundamental to the Web – and certainly the one we are most familiar with – is HTML. However, HTML was designed for human-centric Web sites, not for exchanging structured content via APIs.

There are, however, other hypermedia types that were designed for this very purpose. As a matter of fact, I was involved in the creation of a very robust one called Collection.Document, which was designed specifically for media organizations.

3. Linked APIs
Leveraging hypermedia as an integral part of interface design allows us to create “linked APIs”. Most current APIs are, at best, creating narrow windows into the solid walls of data silos. Even the most high-profile API will typically only provide access to a single corporate database. Hypermedia allows us to create links between these databases.

This will prove essential to the next generation of content management systems because linked APIs have the potential to give content publishers the freedom they want to seamlessly integrate content from diverse sources and push it across the full spectrum of online channels. As such, they could even come to represent the engine that drives press freedom into the coming decades. So, let’s get that engine cranking!

June 26th, 2014

APIs in the Connected Car: APIdays San Francisco

APIdays SFToday, I’m going to share some rather opinionated thoughts about APIs and the connected car. My opinions on this subject sprang from a combination of real-world experience plus (informed) speculation and came together as I prepared a talk for APIdays San Francisco.

The connected car is widely recognized as a game changer for the automotive industry. Experts all agree that just selling cars is a thing of the past. Mobility, connectivity and in-car user-experience will be leading decision considerations for car sales. Right now, automotive manufacturers, content providers and app developers are all competing to take a leading role in the connected car space. This is a matter of survival. Winners of the competition will be richly rewarded; the losers may sink into oblivion.

Car manufacturers seem understandably determined to dominate the connected car space. But this space is inherently shared with device manufacturers, content providers and app developers. Take away any one participant and you no longer have a sustainable ecosystem. If the automotive sector is not prepared to work with and accommodate the needs of other stakeholders, then no one will win. There are three things the industry can do to make things significantly better right away.

1. Implement a Standard Hypermedia Type for Automotive APIs
Right now, every car manufacturer wants to do its own thing and sees originality as a key to differentiation. This is a fallacy. There are way too many car manufacturers for content providers and app developers to keep up with the variety. Some have suggested that all manufacturers should just deploy Android as the base OS. I personally doubt they will all be able to agree on something as fundamental as the core OS. We should shoot for something much more realistic.

This is where hypermedia comes in. The most distributed system ever built — the World Wide Web — uses a hypermedia type (HTML) as its engine. There is a great opportunity to create a hypermedia format for car APIs that will energize the space just like HTML did for the Web. I believe this format could be based on an existing, generic type such as: Uber, HAL or Siren. This would be similar to the way the Collection.Document type was created for the news media industry, based on Collection.json.

2. Adopt a Standard API Security & Identity System
The prospect of connected cars getting hacked creates enormous anxiety. But connected car security can be addressed quite simply by adopting a security framework based around compartmentalization and standards-based access control.

In this context, “compartmentalization” means that core functions of the vehicle should be highly guarded. Specifically, no third-party app should have access to core driving functions like handling and braking. Meanwhile, a standards-based access control framework like OAuth will provide secure, granular access to specific system features. This would be similar to the way mobile apps currently ask for access to other parts of the device (GPs, contacts etc.)

3. Enable App Developers
Currently, only the lucky few are able to develop apps for connected cars. Generally, these are app vendors that have formal partnerships with car manufacturers. In most cases, developers can’t even get access to API documentation without a group of lawyers signing stacks of papers. The connected car space will not develop if it remains a tightly-held, closed system. On the contrary, manufacturers must build developer communities by providing the things that developers require: documentation; self-service portals; sandboxes; SDKs etc.

But That’s Not All
These are three immediate steps that can be taken to improve the connected car space significantly but as the space develops, we will have to focus not only on immediate requirements but also on the big picture. The connected car is a special case of the Internet of Things (IoT). The context of IoT is different enough that it requires a fundamentally different approach to system design and architecture. Hopefully, I will be able to delve into this context more in future.

Another aspect of the big picture is a good deal simpler: fun. If this space is going to develop as it should, manufacturers will have to make it fun for developers to experiment with the potential of automotive connectivity.

So, have fun out there!