A Conversation about Technology, Web Evolution, and API Ecosystem
Both excited and honoured, we are presenting a new piece in our series of interviews with big names in the world of APIs.
In 15 years, Irakli Nadareishvili has become a role model and a world-class technologist people are happy to work with. He is a CTO and co-founder of ReferWell, a well-known expert in large-scale software architecture and distributed computing, and an active open-source contributor and advocate.
Irakli, how about we start by you telling us a bit about your background in technology and API economy?
I started coding in the early ‘90s on HP Vectra. Back in those days, I would code in any programming language that I could get my hands on, but I particularly enjoyed writing in Assembly and Turbo C, because they felt like “grown-up” languages to the teenage me. Several years later, I got access to the web and became completely fascinated by it. Eventually, I ended-up exclusively writing code for the web. I’ve been developing web systems professionally for more than 15 years now. My first, large, purely-API-centric project was architecting version 2 of the World Bank’s Open API, released in April 2009. Version one had some usability issues and I was brought in to redesign+reimplement it using a RESTful API style.
Another significant involvement with APIs, for me, was during 2011-2014. At the time I was director of engineering at NPR (a leading public broadcaster in the United States), where a big part of my team’s responsibility was enabling rich content delivery to a diverse set of digital platforms – NPR website, mobile apps, connected devices, partner systems etc., using a set of sophisticated APIs. It was during this time that I started strongly believing in the benefits of API-first software engineering. Candidly, it was a mental shift for me, given that before NPR I had spent multiple years contributing to the popular open-source CMS: Drupal, and was very used to Drupal’s highly-integrated, MVC-ish model. Drupal didn’t have API-first architecture and was meant for publishing content to the web first and foremost, with the possibility of optionally “bolting-on” an API as an afterthought. Same was largely true for how the team at NPR developed systems, prior to 2011: the “heart” of the architecture was a custom-built CMS and the existing API was just providing a “window” into the content that the CMS owned. In subsequent years we made significant strides in moving that CMS-centric design towards more of an API-centric one. Towards the end of my tenure with NPR, we built Public Media Platform (PMP) - a massive API initiative and a distributed content hub that allows major public media organizations to effectively exchange content, despite the fact that every publisher has their own way of representing the content. PMP was my first professional foray into the Hypermedia API style, which I have become a fan and a strong advocate of, since then.
After leaving NPR I joined CA’s API Academy, where I had the privilege to work with such renown API thinkers as: Mike Amundsen, Matt McLarty, Ronnie Mitra and Holger Reinhardt. API Academy works with some of the most exciting companies, worldwide helping them solve real-life problems in a variety of industries, with the use of APIs, providing strategy, design and implementation guidance. Right before leaving the API Academy, Mike, Matt, Ronnie and I wrote a book about Microservice APIs for O’Reilly: Microservice Architecture. Aligning Principles, Practices, and Culture
Since January, 2016 I am CTO of a New York-based health tech startup: ReferWell, which I co-founded a couple of years ago. ReferWell streamlines medical referrals by bringing 21st-century technology to the medical processes that are still, often managed using fax machines and phones. Technology allows Referwell to help physicians increase patient satisfaction and compliance.
How did you see the future of the web at the beginning of your career? Did any of your expectations come true? Are there any you don’t mind sharing with our readers today?
I think I am not alone in admitting that, in the early days - most of us pretty much had no idea what the future looked like for the web. And that was kind of the point – every new day was full of new, unexpected, exciting discoveries. This is probably what we loved about the web: the sense of serendipity and near-endless possibilities.
The big expectation that everybody had for the web, which largely came true, was that the increases in speed of transmission would follow Moore’s Law and hence we would be able to create the kind of experiences in the future that we couldn’t even dream of in, say, late 90’s or early 2000’s. Another wish that we had belief in was that: web would remain an independent, free platform not owned by any government or entity. Thankfully, this has also proven to be mostly true, however - the threats coming from various groups trying to take control of the web are very real and we have to be careful in preserving the enormous benefits of the free and independent world wide web.
What most of us couldn’t foresee was that “web” would mean much more than just websites. I think the revolution that we now know as the “app economy”, the one that got kick-started by the initial introduction of iPhone, took most people by a huge surprise. This statement does imply that I consider smartphone/tablet/IoT apps to be just a facet of the web, not too different from the websites. The role that web APIs play in the ecosystem is closely related to our new, mobile lifestyle and the ensuing Connected Devices tide will further magnify this role.
Over the years, you have taken part in various projects, including a healthcare IT startup. Today, you are a co-founder of your own innovative, award-winning health tech company. How did you find yourself one? Could you tell us a bit about ReferWell?
With ReferWell, we are trying to bring physician referrals from 20th century, into 21st one, using modern technology. Let me elaborate. Most of us have had an experience of our primary doctor telling us to see a specialist. For instance, they may tell us that we need to see a cardiologist, neurologist, orthopedic surgeon or something like that and then it is mostly up to the patients to find such specialist, to make sure that the specialist accepts our insurance, that their available times work for our schedules, location works… This process is so frustrating, stressful and complicated that about 26 million people a year, just in the United States, are referred to a specialist, need medical care – but never make it. That is really bad. And even when a patient makes to a specialist’s office, most doctors will typically have to start a “game” of fax- or phone-tag trying to get information from each other, leading to lost data and subpar care. We built a modern, secure, web system that removes a lot of the complexity from the process, streamlining the flow and making all participants much more productive + satisfied, while facilitating better care.
ReferWell was founded by a successful interventional cardiologist in New York: Jeffrey Bander. I joined him, as a co-founder, as he was bootstrapping the company, in February 2014. We got introduced by founders of another health tech startup in the city that I had been a tech advisor to and remained friends with.
Among other things, you are widely recognized for building shipping software products. Based on your experience, what advice would you give to developers working on such projects?
The benefits of releasing often, or even “continuously”, have been widely recognized, at this point. However, this is much easier said than done. Rapid iteration requires operational and cultural setup without which it can turn into a mega-disaster. The art of frequent deployments is not to simply achieve maximum speed, but to increase speed while maintaining acceptable levels of system quality. Operationally, teams require infrastructure and tooling that facilitates rapid iterations. Culturally, members of the team must be “sold” on rapid iteration and be capable of working in this mode. And I don’t mean just technical team members but equally importantly: product managers, subject matter experts, designers, stakeholders etc. If a company comes from a more traditional, slower-moving culture – even the one with two-week agile Scrums – the very first thing that will need to be addressed is: cultural transformation of the teams involved and the stakeholders. What makes any cultural transformation hard is that it cannot be “solved” by just buying several software packages, it really is a different way of thinking about building software systems. We believe cultural aspect is so important that in our book Microservice Architecture, my coauthors and I dedicated significant space to addressing it.
Just like any other eCommerce B2B software, solutions you are building cannot do without integrations. How would you define the importance of those with shopping carts? How do they use them? Where do APIs fit there?
In my experience, shopping carts are indeed an important part of both B2C and B2B e-commerce solutions and in most cases it is pragmatic to outsource (“buy”) the implementation. In general, I agree with the approach that a company should constantly evaluate the features its products consist of, analyze them vis-à-vis the complexity and competitive advantage of the features. The features that you want to build in-house are the ones that are less complex for you to build and give you a large competitive advantage. Shopping carts, typically, are the opposite of this category: generally very complex and for most companies do not provide a significant competitive advantage as most shopping carts operate the same way. As such, some edge cases notwithstanding, most companies would probably benefit from a good off-the-shelf solution in this category, while concentrating their unique engineering skills and time on something more specific to their own line of business.
The best way to integrate an “off-the-shelf” shopping cart is via APIs. In this case, the original product can have full control of the user experience and the context, since good APIs deliver features and capabilities without dictating UI approach or platform choice. Case in point: an API-driven shopping cart will be equally easy to integrate into a mobile app, as well as a web app.
After the API provider is chosen, the integration process begins. What would you recommend the API consumer (client software) to do, in order to get the most out of their integration with shopping carts?
The basic way of evaluating any API integration is to view it as the introduction of a critical dependency. When you start tying your product with a third-party API, the third-party API can become the weakest link in the chain – if that API goes down, it can bring your app down, if that API malfunctions, your users will attribute the problem to your application, not to the API you are using. Trust starts at evaluating the SLAs your API provider is willing to give you, but doesn’t stop there. I view the usage of an API the way I view business partnerships - it’s a serious dependency. Another aspect to pay attention is - documentation, which can make or break the user-experience of a developer coding the integration. A good documentation says a lot about the API vendor and makes lives of the developers easier. API vendors’ commitment to backwards- and forward- compatibility is another important factor for my decision-making.
And finally, how do you think APIs and their role for businesses will change in the future?
I think the definition of what we call “web” will keep expanding. It started as just “web pages” and now mobile apps, APIs etc. are all part of what we consider to be “the web”. Further expansion may shift the balance and promote non-HTTP protocols. A vast majority of web APIs, today are created on top of HTTP. I love HTTP, but it isn’t necessarily a panacea. There’s a lot of space for good real-time and low-latency or low-overhead protocols. Most of these categories already have interesting implementations, but their adoption is nowhere near that of HTTP’s, which I think may change.
I also think that evolving, long-lasting API design styles, such as Hypermedia Style, will gain more widespread adoption because the benefits of such styles are very useful for allowing rapid iteration safely i.e. without degrading the system quality.
We want to thank Irakli Nadareishvili for his time and willingness to share his expertise, insights, and views with our readers.
