TMC: What new business opportunities are being driven by to the growth of the so-called API economy? Santiago Troncoso: The API ecosystem provides a vast set of opportunities based on the Internet main concept: interconnection. In this case, instead of connecting only networks, we are now interconnecting features. This is a way of making possible extremely complex features based on collaboration. From my point of view there are three main business opportunities: data gathering and data mining, interconnection or API adaptors and, finally, actors. This could have an influence over different verticals, so it could be a nice ecosystem for specific sector applications or wide agnostic applications to cover several use cases. TMC: Is there a market for APIs you would consider the low-hanging fruit?  Which markets are the next to leverage APIs extensively? ST: I really think that the explosion of the IoT will stop and start to move to different areas. Now all the people know what's possible with interconnection, so it’s time to consolidate it. Security is now the demand and the need. On the other side, as the technology changes, the customer demands for more and more complex features. These two factors force the API actors to integrate with multiple systems in order to achieve those complex features. On this space, secure & scalable interconnectors and API adaptors are the key elements. Adapt, reuse and reconnect existing solutions. TMC:  What are the major challenges API developers face? ST: The eternal developers challenge is always the infinite SoW. It’s not possible to do everything, so the scope must always be planned in detail. The hardest part is to plan the API. From the first day it must be clear the way to take, where to start and the final objective. For this, a smart balance between candies and requests must be selected carefully. Also discussions to select the main structure and technology to implement are needed. But probably you finish your API really far from your initial objectives. A good option is to review your plan continuously, but the methodology and technologies must stay the same to avoid large changes. We are overloaded with different technologies, standards and de-facto standards (not always trustable). The options are vast. There is a huge risk to keep implementing beta versions all the time. It’s important to take the first decisions well and plan everything from the beginning. TMC:  Who, within an organization, should businesses target when marketing their APIs (i.e., business leaders, C-Suite, developers)? ST: Each target may look for a specific message. If we are facing a smart company, everyone should be taken into account. Business leaders will find new opportunities combining APIs and exploring the possible options, C-Suite are more concern about planning so will compare multiple options that offer something  the same, since developers will probably be the best to detect well built and easy to adapt APIs. TMC:  How do you measure ROI of APIs? ST: The ROI could be calculated by endpoint using your API. Each endpoint allows access to a number of features and systems. Every time you receive income from the usage of an endpoint this adds value to that endpoint. At the end, what you need is to get value from your product. The return will come with services sold with the APIs used. As an example: Your Application Server will in theory be more valuable if you can use a standard MSML for conferencing apps, because most of MCUs currently use it. But if your partners only integrate proprietary solutions that use a different protocol, you won’t have return from this API. TMC:  Who is responsible for security?  Is API security more challenging that securing other applications, hardware and networks? ST: All of us are responsible for our own security, and not. It’s not harder than any other environment. The unique problem here is that this was not taken in account due to market demands and profit expectations. Customers pay for something new and come with a preconceived idea that “it must work well and secure,” but this is something that is changing now. You buy a new feature, but not a new feature completely tested, secure and robust. The society is assuming the idea so now the scenario is starting to change. Again: compare, test, analyze and do not make fast decisions. From my point of view, security is a great opportunity nowadays. TMC:  Which is better, SOAP or REST?  Why? ST: They could not be compared. SOAP is a standard, REST a philosophy. Since SOAP is more tied to “one client for one specific server” implementations, REST is more relaxed, open and accurate for changeable specs. So REST is a consequence of the current times: the relaxed fit of SOAP. REST provides an ideal scenario where both parts could evolve independently and could merge multiple implementations and versions without the risk to break things. My favorite approach: REST. But again, it’s not a standard. TMC:  How often are APIs changed or updated?  How is this accomplished while ensuring minimal disruption to users and their customers? ST: An API should change minimal or nothing. That’s the key; a well planned API should not change, only expanded to include new features. That makes the success, to plan well and create your minimal API. After this, it starts to expand without changes, allowing new customers to get attracted by your new features, but keep the current ones without disruptions. Where is the trick and evolution? Changing permanently, and continuously improving the backend behind the API. That makes your product better, keeping your interconnection intact. TMC:  What kinds of standardization are still needed to drive successful mass development and adoption of APIs across verticals? ST: The problem is that maybe we have too many standards. People need simplicity. An easy way to implement these APIs is required. Most of the mestizaje of the APIs we have nowadays is derived from large standards that require tons of hours to implement. Most of the time these standards are not needed for a specific vertical application so, a new API is defined. This will help improve systems getting better features with less specific code. TMC:  How important is building an ecosystem around your API(s)?  Can your API(s) be successful without it? ST: You will need a specific ecosystem only if you are playing your own game. If your APIs expose standardized methods and use interconnection with existing apps, you don’t need to build your entire ecosystem. We have an application server called Sippo WAC, and one official client library: the SippoJS, but we can interconnect with multiple vendors and proprietary infrastructure systems. In fact, our API is based in a standard one called Orca.js. We didn’t build an ecosystem, as it requires big efforts, we adapted our interfaces to be compliant with the existing ones and reach better the community. TMC:  Why should attendees at All About the API make sure to attend your session/booth? ST: In this panel we will review the final architecture and all the lessons learned in a real field deployment in a bank, where application servers, authentication managers, signalling and media engines and media servers are involved to build a new real time communication tool. Customer onboarding (helping new customers to open a bank account remotely) is the new case that is forced to work with a bunch of existing systems of the bank (user enablement, data bases, etc.) with different new elements via APIs. We'll have the opportunity to discuss all the problems and concerns of this deployment and how the different vendor APIs helped to success.