Holger Reinhardt

Holger Reinhardt

Holger Reinhardt is a Product Architect & Business Developer at Layer 7. In this role, he explores opportunities related to IoT, M2M and Big Data for Layer 7. Holger has over 16 years of software development experience in Telecom and SOA appliances. Prior to joining Layer 7, he was part of the in-house incubator team at the office of the CTO of IBM WebSphere. He joined IBM through the DataPower acquisition.

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 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.

May 29th, 2014

Toward a Lean API Strategy

Books on Lean Business Strategy“Lean”, “API” and “IoT” are probably the most hyped terms in our industry right now. Normally, I tend to blog about the latter two but – for a change – I would like to balance that out by talking about the former: the concept of Lean and how it relates APIs.

You have probably heard about or even read The Lean Startup by Eric Ries. And you may have noticed that this book sparked a whole cottage industry of Lean publications, like Lean Analytics, Lean UX and the widely-misunderstood concept of “minimal viable product”.

But few of you may have ventured back to explore the texts that laid the foundation for the Lean startup. The Four Steps to the Epiphany by Steve Blank, for example. Blank outlines a business process called “customer development”, which helps startups find “problem solution” and “product market” fit. Even fewer will have ventured right back to the very origins of the Lean concept: the Toyota Lean Production System with its emphasis on pull over push and ever-decreasing batch size towards one-piece-flow manufacturing. And we have not even touched upon the “theory of disruptive innovation” that Clayton Christensen outlines in The Innovator’s Dilemma or Rita McGrath’s concept of “discovery-driven planning” outlined in Discovery Driven Growth.

But the purpose of this post is not to provide a comprehensive reading list for those of you hoping to learn more about Lean and discovery-driven business strategies. My real goal is to explore if and how these concepts can be applied to API design best practices. However, if you are curious and want to know more about the books mentioned, I suggest you head over to a blog post I wrote for launchd.io. And for your next long-haul flight, you might want to consider starting with The Goal, which will provide you with some truly novel-like business reading.

Before I explore how Lean and API design come together, let me first make a confession – I got an MBA a couple of years back. I know that this is not going to win me any brownie points and I still prefer code to spreadsheets – no contest! But it goes some way to explaining why I think business and API are joined at the hip. The business value of an API does not come from the interface’s intrinsic technical features but from its ability to provide access to a business asset or service. APIs provide a technical means to do (more) business.

From this follows the assumption that API design and implementation need to focus on the intended business outcome. Which means that you must have a clear view of your business goals before you can start to implement your strategy. Unfortunately – in my experience – most of us on the technical side are not equipped to talk to the business side of the house (and they are seldom well prepared to talk with us). This is why I went back and got an MBA – so that I could learn to speak with “them” and build better products.

Starting with Toyota’s lean product development process, I began to see approaches and tools that could help bridge the semantic gap between the technical and business sides. I plan to share some of these with you in subsequent posts. I will start by discussing Alexander Osterwalder’s Business Model Canvas. To get a little background on what I’ll be talking about in my next post, I suggest that you read this post on ProgrammableWeb, where Mark Boyd uses the Business Model Canvas to analyze Walgreens’ QuickPrints API. Also, you might want to take a look at my Lean API Strategy presentation from the recent APIdays in Berlin.

April 24th, 2014

SDKs Work Until They Don’t

SDKs and APIsOver the last couple of months, I’ve had many great opportunities to road test my findings on SDKs vs. APIs, with a wide variety of audiences – at our API Academy Summits in New York and London, on tour with the Nordic APIs team in Stockholm and Copenhagen and at my most recent API Workshop in Istanbul. Given the apparent relevance of the topic and the lively discussions I’ve had around it, I’d like to take this opportunity to summarize some of the insights and recommendations that have come up.

If you’ve been following our blog, you will remember that I started this topic with the observation that leveraging an API increasingly seems to involve using an SDK rather than the API itself. I followed up with a post talking about my decidedly mixed experiences of trying to use SDKs. My own experiences inspired the headline of this post: SDKs work until they don’t.

So, what are the main motivations to invest in an SDK, from an API-provider perspective?

  • Simplifying API design by extracting business logic into the client
  • Maximizing scalability by exploiting client-side processing
  • Empowering developers to leverage the API more quickly
  • Presenting an optimized client from a target-platform perspective (e.g. for mobile connectivity or constrained hardware)
  • Providing a strongly-typed presentation of the API in a variety of programming languages

Let’s contrast all this with the main drawbacks of SDKs:

  • Picking which platforms, languages and frameworks to support – some of your target developers are going to end up disappointed
  • Relying on third-party frameworks – any developer who has to integrate with two or more APIs leveraging the same framework at different version levels is bound to experience some headaches, for example
  • Adding carry-on weight of unused functionality to the application
  • Incurring long-term support costs for the SDK

But to me, the biggest risk of a SDK-first approach lies in making API design an afterthought. We have come to this point in the API evolution because pragmatic REST introduces just enough constraints to force us to think about how we can abstract the underlying business asset into a resource-based model restricted to CRUD-style interactions. An SDK-first approach might tempt us to go back to a RPC-style API design mirroring the backend implementation, resulting in all the inherent integration complexities we had with Web services.

So, if and when you decide on a SDK, keep the above in mind. You might still come to the conclusion that you need an SDK in order to quickly onboard developers or provide the best client for your API but at least you will be able to consciously weigh the benefits against the drawbacks.

If you want to dig more deeply into the subject, I can highly recommend the following podcasts, articles and blog posts, which helped greatly in forming my own opinions:

March 27th, 2014

SDK vs API – Round 2

SDK vs APIInspired by a conversation with Kin Lane and Mike Amundsen at last year’s APIdays conference in Paris, I decided to dig deeper into the SDK-vs-API debate.

As I wrote in my last post, I had noticed a pattern of using API SDKs rather than the underlying Web APIs. Let’s quickly define what I mean by SDK. There used to be a time, not so long ago, when “SDK” meant documentation, code samples, build scripts and libraries all bundled together. Today, you find all the former on the Web and usually only the library remains. When I use the term SDK, I mean a programmatic API (e.g. JS, Ruby, PHP, Python) on top of the Web API (usually REST/JSON).

As it happens, my wife gave me a small wearable activity monitor as a Christmas present (I could not possibly think of any reason why I would need that – and the new weight scale in the bathroom must have been pure coincidence). Since the gadget was uploading my stats to a cloud service and this cloud service had an API and my wife gave it to me as a present, I figured I had a perfect excuse to do some coding. My goal was to write a client-side app using JavaScript, pulling my stats from the cloud service via the API (and to keep notes on my experiences).

After registering at the developer portal, I hit my first stumbling block – no client-side JavaScript SDK. The closest I could find was a PHP SDK – which, of course, meant that I had to install PHP (I had not used PHP before) and the framework(s) used by the SDK. I also had to enable a Web server and debug the SDK’s OAuth implementation. That was not quite what I had in mind. Even though I got it running after one day and a half, I ended up being quite frustrated. All that work for a simple Web page displaying the stats for a hardcoded day!

So, I decided to take a different approach and use the SDK provided by Temboo. Again, no client-side Javascript SDK. While I could have used a Node.js SDK instead, I decided to stick with my PHP install and opted for the PHP SDK. From there, the integration was quick and I was up and running within an hour. What I did not like about the SDK was the footprint (it included all possible integrations) and how its abstraction and data presentation leaked into my application code. If I were to build a commercial product using it, I would have to consider the potential stickiness of the SDK. Personally, this did not feel right either. So, I went back to the drawing board and looked at my options.

What had I learned so far? My frame of reference going into the experiment was a client-side app using JavaScript. Yet the only SDKs I had found were written for server-side integration. Since it was the only choice offered to me, I had to invest a significant amount of time finding all the necessary information to get the server-side components and dependencies installed and configured. But even after going through all of this, the experience with either form of SDK left something to be desired.

I had started this exercise thinking that using an SDK was much easier than coding against the Web API – maybe it was time to reassess that assumption.

Looking back at the API documentation, I could not find anything inherently difficult. Looking at the vendor-provided PHP SDK, it dawned on me that the complexity of the client was entirely due to OAuth and the use of XML as payload. This finally gave me the opening I had been looking for. If I could avoid the complexities of OAuth on the client and use JSON as the payload format, I should be able to implement my client-side app with a few lines of JavaScript against the Web API. As a regular guest at Webshell‘s APIdays conference, I was familiar with the company’s OAuth Broker service. It took me a few minutes to get set up, configure the service and download their oauth.js client library. I cut and pasted the sample code into a JavaScript file, consulted the API docs to learn about switching to JSON format and did the API call. I was done in less than five lines of code!

While this experiment is just a single data point, I think it nicely illustrates some of the key lessons in the SDK-vs-API debate. I will attempt to provide a summary from both the API consumer and the API provider perspectives in my next post. I will also be talking about the SDK-vs-API issue in more detail during the upcoming Nordic APIs tour in Stockholm and Copenhagen and at the APIdays conference in Berlin.