For years I’ve admired the following picture …
… because it’s a terrific metaphor for complex systems – and the challenge of assembling them. Lately I’ve been using this figure as a metaphor for complex end-to-end IoT projects, and the challenge of integrating them. My point is simply that you wouldn’t expect to assemble this car (in case you’re interested, a Volkswagen Golf) using just a crescent wrench, so likewise you shouldn’t expect to integrate end-to-end IoT projects using just RESTful API’s.
Now don’t get me wrong – I have nothing against API’s. They are the defacto choice for interoperability between distributed components in most innovative IT projects lately, particular those involving mobile, cloud and IoT. And I predicted the wide-spread adoption of API’s in B2B, even in traditional B2B contexts (e.g., By 2018, the 10 largest B2B networks will have evolved into API networks – see Predicts 2014: Nexus of Forces Drives Evolution of Integration Strategy).
But the point I am making here is that RESTful APIs – alone – often lack all the capabilities you need to address functional gaps and to scale up end-to-end IoT projects. When you discuss back-end system integration with an IoT solution provider and they say, “We have an API for that”, don’t be seduced by the idea that API’s, alone, will address all your needs. Consider:
- Semantic reconciliation: Either the API publisher, API consumer or an intermediary must address the frequently occurring semantic miss-match between distributed computing endpoints. I recently described this in my recent near-rant about the challenges of semantic reconciliation in B2B. The point is that you often need to translate data and to do this in scale you will often leverage integration middleware (e.g., iPaaS, ESB or integration brokerage).
- Protocol-hopping: The reality is that RESTful isn’t always available, so you often need to protocol-hop between different forms of communications (e.g., RESTful to SOAP / MOM / whatever). At times your IoT platform middleware will support needed non-RESTful protocols, but often you’ll benefit (again) from integration middleware, most which offer a portfolio (sometimes dozens) of supported protocols.
- Adapters: Most SaaS and more recent versions of mainstream enterprise software (e.g., from Infor, Oracle, SAP) support API’s. But often older versions of this software, legacy Apps and data, and applications and databases from many smaller or more verticalized IT providers do not support any form of API (let alone RESTful ones). In this case you may need commercial adapters or ADK’s (adapter development kits) to “API enable” such applications and data.
- Governance: While RESTful API’s address many basic security and QoS needs, more demanding IoT applications may require stronger security, higher performance monitoring and other (e.g., public compliance) forms of governance. API management tools (either integration middleware stand-alone tools or embedded API management capabilities) are often use by IoT project implementers to define and manage API policies, and enforce them at runtime.
What am I missing? Regardless, the take-away here is that indeed – Yes! – go ahead and adopt an “API First” approach to interoperability for your IoT projects and – Yes! – in many cases simpler, smaller-scale IoT projects can be successfully deployed and integrated using just RESTful API’s As-Is. But in the same way that a crescent wrench – alone – likely isn’t enough to assemble a car, so too RESTful APIs – alone – likely won’t address all your IoT integration needs. As IoT projects proliferate, become more complex, and scale up also be prepared to leverage some form of integration middleware to address functionality gaps.
As I wrap up work on my Building IoT Solutions and Best Practices in IoT Integration presentations for Gartner Symposiums in Orlando and Barcelona, and also for our AADI event in Las Vegas this December, I look forward to discussing IoT Integration and many other integration challenges with our attendees — see you soon!
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.