The thing about technology, data, software and machines, is they need to be able to play well together. They have to function alongside and with one another and you have to be able to extract needed data to succeed.
About 42 years ago, a group of engineers got together and did just that. What they first created was a solid-state relay and started a company that would manufacture controllers, I/O, solid state relays and software products that could be used to link mechanical and electronic devices to networks and computers.
Fast forward 40 years and it’s still delivering its customers with the ability to monitor, control and get the data it needs from machines and devices.
What’s also interesting is the company started out with engineers and was run in a non-corporate, flat environment – no middle management - and after 40 years it’s still privately held, lean, and run by engineers.
A lot has changed with technology over those years but the need to connect machines and computers is growing. So too is the need to make communications between platforms easier. This is where APIs come in. In the developer world, its All about the API.
This topic will be the main event at an upcoming conference in Las Vegas from July 19-21.
To hear more, DevsWorld caught up with Matt Newton, Director of Technical Marketing at Opto 22.
Matt will be speaking during a session at the event titled, “Bridging Open IoT with Legacy Systems Through API’s” to help both experienced and new developers understand how to address the challenges related to integrating legacy systems into the IoT.
Our exchange follows.
What new business opportunities are being driven by the growth of the so-called API economy?
The overall business opportunity being driven by the API economy is the new, unparalleled access to information and resources that APIs provide. APIs are a conduit to previously untapped information and assets, and the business opportunities are nearly infinite. Today, even hardware - such as industrial control systems have APIs. Opto 22, an automation company, now offers an API to its industrial-quality controllers that monitor and control a wide variety of sensors, machines and systems. On the manufacturing floor, this API offers new opportunities for cutting waste, improving quality and safety, and maintaining equipment proactively, leading to reduced downtime and longer life for industrial equipment.
Is there a market for APIs you would consider the low-hanging fruit? Which markets are the next to leverage APIs extensively?
The market with the lowest hanging fruit for APIs right now is definitely the industrial automation, manufacturing and process control industries. That market has been building and shipping billions of devices for decades, none of which were designed for easy interoperability and communication. All of this existing industrial infrastructure currently has no way to interface to the Internet of Things, because it was designed long before the Internet and the digital world as we know it today. As APIs to industrial control systems become available, businesses will be able to tap into that existing infrastructure and the information it holds. This brownfield opportunity of connecting legacy assets to the Internet of Things represents the largest business opportunity I think we’ve seen since the Internet first started rolling out in businesses.
What are the major challenges API developers face?
Some of the major challenges API developers face today includes security, interoperability and cross-platform support. Businesses are finding good reasons to connect many different types of systems in the enterprise. For example, a manufacturer may want to take data from the plant floor, such as production lead times, and make it accessible through a web-based portal to customers’ mobile devices. Ensuring that the data is sent securely between different assets is a major challenge; ensuring that it can be consumed by any device the end user has is another.
Who, within an organization, should businesses target when marketing their APIs (i.e., business leaders, C-Suite, developers)?
I think there are three levels of sales and marketing targets for API developers. First there’s the C-Suite. The sale at this level needs to speak to how the API solves a business problem. In other words, sell the solution the API provides instead of the technical speeds and feeds of the API. The next level target is the IT and operations management teams of the business. At this level the sales discussion should focus on how data will be moved, user experience will be improved, etc. And finally there’s the developer or engineer who will implement the API. At this level the sales discussion should focus on the developer and support community around the API—because there absolutely has to be one in place to ensure successful rollout and adoption of the API.
How do you measure ROI of APIs?
Measuring ROI of an API can be challenging.
From the standpoint of the API developer, one of the easiest ways to get visibility of API ROI is to measure the number of API calls to the server hosting the API. API calls are essentially the new website visits metric. Another way to measure ROI of APIs is to first consider what the API is used for and who’s using it. From there KPIs can be developed to specifically measure how successful the API is at obtaining ROI.
From the standpoint of the customer using the API, it’s much easier to calculate the cost of the developers time to implement the code to do the API calls and turn the data into money. When the API is based on web standards like REST and JSON, developers can “fail fast”; they can get the data into a test or production application quickly due to the open nature of the API. A well-documented API with code samples will reduce the ROI costs and time.
Who is responsible for security? Is API security more challenging than securing other applications, hardware and networks?
Security is everyone’s responsibility, from the API developer to the user or asset interfacing with the API. Security is a constant balancing act between securing the asset and providing useful access to its resources. Authentication and authorization levels should always be built into the API from the ground up rather than as an afterthought, and utilization of standard encryption technologies should be mandatory, particularly on public, untrusted networks.
Which is better, SOAP or REST? Why?
REST is better than SOAP for web communications because it travels over the standard HTTP protocol, rather than requiring its own protocol as SOAP does. Also, SOAP only permits XML for its data payload, whereas REST permits many different data formats, with JSON being the most common. JSON parses much faster than XML and provides better support for browser clients.
How often are APIs changed or updated? How is this accomplished while ensuring minimal disruption to users and their customers?
Updating an API is tricky because you already have customers using it and you don’t want to blow up their applications. But you also want to add new features or fix problems. One way to mitigate the negative effect of changes is to limit updates to exactly that: adding new features and fixing problems. But for any change, communication is a must. You can help keep users happy by warning them in advance of any changes to come, being clear as to when a change takes effect, and explaining exactly what the result will be for anyone using the API. Technical support should also be available to help users when changes happen.
What kinds of standardization are still needed to drive successful mass development and adoption of APIs across verticals?
A great place to start with the discussion of standardization for APIs across verticals is the OpenAPI specification. Originally known as the Swagger Specification, this spec defines how to structure interface files for clear interactions with RESTful web services. The specification makes it possible for developers using the API to understand it quickly and use a variety of tools to generate code, documentation and test cases. The idea is that both humans and computers will find the API easy to understand and use. The key here is that OpenAPI is language agnostic. An API that only allows data to be accessed and stored within the same system is not going to invite adoption. For the API and the data it exposes to be valuable, data silos need to be broken down.
How important is building an ecosystem around your API(s)? Can your API(s) be successful without it?
Building an ecosystem around an API is crucial. The very value of the API comes from the ability to easily and securely interface with other APIs in the ecosystem, whether yours or someone else’s. Combining APIs is the modern framework for application development. It allows your product to become a platform for a wide variety of uses you may not even have imagined.
What differentiates one ecosystem from another?
By publishing your API, you open up your business to be leveraged by customers and partners. This leverage creates increased demand for your products and new value for both your business and your customers’ and partners’ businesses. A well-defined API adds value because it allows other developers to access your data and create applications that you never dreamed of.
A poorly documented or partial API, on the other hand, stifles innovation and thus shuts down the ecosystem. It may provide some value but does not allow for the organic growth of the ecosystem, which can spur much wider use of your products.
Why should attendees at All About the API make sure to attend your session/booth?
By far the largest opportunity the Internet of Things offers is the promise of connecting billions of legacy industrial systems that are already installed and functioning to the Internet—and accessing the data these systems contain. Until now there hasn’t been a simple, straightforward way to do this. Opto 22 has developed an API to real-world assets that allows for rapid IoT application development. At the Opto 22 session attendees will learn technical details for implementing an IoT strategy, enabling legacy sensor and I/O systems, moving data securely from point to point, and visualizing legacy systems, all through open IoT technologies such as RESTful APIs and JSON.
Edited by
Alicia Young
