On Wednesday the 11th of November 2015 we hosted a super interesting event at the API Athens Meetup about  APIs, IoT and a bit of Business.

http://www.meetup.com/API-Athens/events/226304434/

The keynote speaker is a friend and mentor of mine, Sotiris Bantas. Sotiris is a technologist and entrepreneur with diverse background in semiconductors, microelectronics systems and all aspects of software. Excellent problem solver and conduit among business stakeholders and technology teams in a broad spectrum of disciplines, ranging from wireless systems design, to chip design, to cloud applications. Former co-founder and CTO of Helic, now a proud founder of Centaur Technologies. This is a company that develops and markets end-to-end solutions for the Internet of Things, focused on the Industrial and Enterprise sectors.

The meetup was a success, as the room was full of people! We even had people standing, just waiting to listen Sotiris discussing about Internet of Things applications, business models and relevant API technologies.

Below you can browser his presentation and you can always interacting with him on twitter. He is super friendly, always online and ALWAYS ready to engage interesting Tech conversations.

In Sotiri’s Words

Centaur Technologies designs for the Industrial IoT. Our sensors typically go inside cargo containers and connect to the cloud wirelessly, often through an API.  We aim to go “where no sensor has gone before”, and quite often an API is providing the breadcrumbs for this journey…

Why did we have to develop an API? There is usually a pragmatic aspect to this. An API forces a certain modularity to the design, so that multiple apps may access the same database in an orderly fashion. This becomes important in the context of databases for the IoT where data streams may flow in from numerous Things, while data consumers (human or machine) should be allowed access through some formal authentication mechanism (e.g. we use JWT for now). Moreover, an API provides ideal test fixtures for making the code testable (e.g. we use SuperAgent for that).

But there is often a strategic aspect to an API. It paves the way for onboarding others (especially 3rd party developers) to your service. In an ideal scenario, your customers may use the API to develop their own toolsets and apps over your product (or its underlying database and engines).

But is everyone open to this sort of APIxploitation (to coin a term…)? Not always. Some services will only implement the ‘R’ in CRUD, that is provide read access to the underlying database but not necessarily allow one to add to it in any meaningful way (outside their own UI). That’s not the only bottleneck with APIs; sparse documentation and lack of standardization, especially for the IoT, are some of the typical shortfalls. By the way, we like what iotdb.org is aiming to accomplish by offering some standard semantics in the way IoT APIs could be built one day.

So is the API part of the product? Is it monetizable? Some people go as far as advocating that the API is the product. This is especially true in the case of tiered or freemium services such as Mailchimp and Google Maps, where most commercial usage may originate via the supplied API. Transactional APIs such as PayPal’s or Stripe’s will implement charges per each transaction (digital payments in their case). Affiliate business models such as AdSense and the bulk of the business network comprising today’s travel industry will also rely exclusively on APIs to channel commissions between agents, platforms and providers. 

Will these business models pan out well in the IoT? Maybe so.

Most IoT products today, especially those in the consumer space, come with an API. Think of a wearable fitness device allowing third parties to develop apps for its users. Access to such an API may typically be free (to promote sales of the appliance) but tiered pay models are also possible – especially when advanced analytics are added to the offering. Regarding IoT infrastructure, platforms and middleware offerings are invariably offered to IoT developers in the form of a tiered API or via a freemium access model.

Interestingly, transactional APIs may also be envisioned especially if Things are to start transacting business with each other. A micro-payments model could be considered where Things may initiate monetary transactions and clear them using some form of blockchain-based currency. Think of your car paying the proximal parking meter using pre-stored Bitcoin.

Finally, affiliate business models should appear at some point. In the context of Smart Cities, one of the ways to enable service aggregation in what is currently a very fragmented ecosystem, could be over the development of API-driven affiliate networks. Municipalities, utility companies, telecom operators and specialized solutions developers could participate in a common marketplace, each one of them enabling partners to offer commercial services over its proprietary database and fleet of Things. In this fashion, a filling station could advertise an off-peak-hour offer for cheap electricity, by pushing it to the autonomous vehicles roaming in its vicinity. Anything could flow, as long as the proper plumbing (= API) is in place…

Final Thoughts

Some interesting discussion that were raised during the Meetup where mostly focused about the semantics of APIs and how some of those good practices can be transferred to the world of IoT and Smart Cities.

A lot of discussion about  IOTDB: The Internet of Things Database took place engaging more and more people to express their feeling about common shared practices. I am a great fun and follower of the Schema.Org paradigm, but everyone seems as comfortable by following guidelines from Google, Yahoo and Microsoft.

In order to summarise this post, it is important to notice that Greece has an active community of developers that investigate the latest technology trends and want to be part of the changes to come.

Greece could benefit from the current crisis by opening more business opportunities and enabling the creation of a european silicon valley in the way that Barcelona tries to create one.