goTransverse was formed in 2008 and offers Billing-as-a-Service via the cloud. This cloud based solution offers lower costs of entry, accelerated deployments and real-time data insights into revenue streams. From this innovative idea, TRACT was created. TRACT is the cloud based, internet-scale billing and revenue automation platform.
Paul Tindall, CTO and vice president of engineering at goTransverse, will be speaking at the All About The API event being held at Caesars Palace in Las Vegas from July 19-21. Paul holds MBA and Bachelor of Electrical Engineering degrees and has a patent for a manufacturing-related algorithm. He has built his career around finding cost-effective and pragmatic ways to deliver complex software solutions. At the event, he will be speaking at the Moving with the Market: Enhancing the Value of Your Product with API session. TMC had the chance to talk with him about APIs and their relation to businesses. The full interview can be seen below.
TMC: What new business opportunities are being driven by to the growth of the so-called API economy?
Paul Tindall: APIs have been around for years. What we are seeing is a transition from legacy approaches based on SOAP and XML to more widely adopted approaches such as REST and JSON. New standards are emerging to describe these APIs such as OpenAPI and RAML, and tooling is coming online for code generation and API gateway management around these standards. This infrastructure sets the foundation for companies to offer higher value API driven services to the market, either as smaller, dedicated micro services or larger fuller featured applications.
TMC: Is there a market for APIs you would consider the low-hanging fruit? Which markets are the next to leverage APIs extensively?
PT: If you look at a company like Uber, it is basically a mashup of several APIs that include mapping, notifications and payment management. The cost to build Uber was greatly reduced because it could leverage these services. It also means Uber has to maintain its competitive advantage in other ways since it in theory could be easy to make a copy cat service. Any API that can expose a service that is of high value and could be used to make new and interesting applications via a mashup approach would be a great place to start thinking about opportunities. A company does not always have to provide a complete application to provide something of value that can be exposed out via an API. A great example is Twilio that provides capability to send SMS notifications via a very simple to use API. All of Twilio’s value is via that API.
TMC: What are the major challenges API developers face?
PT: API usability I think is one of the major challenges. Just like UI / UX, what “feels” like a good API structure to one developer may seem strange to another. Granularity is also an issue where the API architect / developer needs to determine how “low-level” vs. “high-level” the functionality needs to be that is exposed by the API. While a low-level approach is the most flexible, it often means that the developer has to make multiple calls to accomplish something and often has to understand some of the lower level details of how your service or application works. A high-level API can get around this, but you then have to try and find the sweet spot of what most developers are going to want to do with your API. Sometimes, the best way to get around this is through API stacking where higher level APIs can be exposed that make calls to the underlying low-level APIs.
TMC: Who, within an organization, should businesses target when marketing their APIs (i.e., business leaders, C-Suite, developers)?
PT: There are probably multiple levels. The marketing or strategy or product management teams may be interested in the “ecosystem” or “standards-based” messages that come along with APIs, but the engineering or IT teams are going to be the ones living with them at the end of the day. The bigger message is not the API itself, however, but the service being delivered by the API. For example, if you have an address verification service that a company would otherwise build and maintain, your API enables you to offer them that service in an easier and hopefully cheaper way. Your value to the company is not the API, but the offloading of the development, maintenance and support of an address verification service.
TMC: How do you measure ROI of APIs?
PT: I think you need to look at what the API is going to do for your service or application. Is it going to allow you to sell into new markets? If so, the ROI can be calculated based on a sales growth metric. If it allows you to potentially improve your own internal operations by allowing the move to a micro services approach or the ability to control where core functionality resides versus customer specific functionality, then it becomes more of an expense savings based ROI calculation.
TMC: Who is responsible for security? Is API security more challenging that securing other applications, hardware and networks?
PT: The API needs to enforce the level of security that is appropriate for the underlying service. Every effort should be made to protect the API user from having to be overly responsible for security.
TMC: Which is better, SOAP or REST? Why?
PT: SOAP grew up in the enterprise space, primarily around Java and .NET. As such, it is still very well understood in those areas. Many enterprise cloud applications only support SOAP based APIs. Some companies, goTransverse included, support both SOAP and REST interfaces because there is still demand for both. However, many companies have or are dropping their support for SOAP (Amazon is an example) in favor of the REST approach. SOAP used to be more popular since a developer could auto generate code to interact with the API. However, SOAP payloads and responses are incredibly verbose and complex and difficult to debug. With RAML and OpenAPI on the REST side, the same level of code generation is available and JSON is simpler to read and understand. If I were starting a new API project, I would strongly consider REST and go with a “definition first” model using OpenAPI or RAML.
TMC: How often are APIs changed or updated? How is this accomplished while ensuring minimal disruption to users and their customers?
PT: API version management is one of the most challenging aspects of an API. Things are easy to change early in the development cycle, but once released into the wild they become more locked down. Maintaining backwards compatibility of an API can be very challenging in a SOAP environment since many of the code generators get very angry when you add new models or attributes or methods. You can’t expect your customer to have to go back and update their application every time you want to change your API. REST can be implemented in a much more forgiving manner. Some companies release new API versions that are tied to their underlying product release versions. Others release only when there is a “breaking change.” Many companies will maintain multiple versions of their API with a deprecation schedule for older APIs.
TMC: What kinds of standardization are still needed to drive successful mass development and adoption of APIs across verticals?
PT: The trend towards newer REST / JSON based APIs defined with OpenAPI or RAML has been a great first step, but it is only the beginning. Any vertical could benefit greatly by starting to define what the standard conversations look like. For example, in payments processing, there are some standards defined at the lower levels such as ACH bank transfers and merchant account level transactions. However, most applications go through a payment gateway that is much less standardized across vendors. While this does allow for vendors to try being more innovative and differentiated in how you interact with them, it also means more effort to implement each and every gateway. ERPs and CRMs are similar in this regard. Many verticals will try to create standard setting bodies in an attempt to move forward with this concept, but many times they are slow moving or dominated by a few major players who will drive the standards to their benefits. Vertical standardization is often difficult for these reasons. Oftentimes, standards start to emerge from the ground up in more of an open source approach with a key few contributors kicking things off and adding collaborators over time. OpenAPI was developed more with this model.
TMC: How important is building an ecosystem around your API(s)? Can your API(s) be successful without it?
PT: An ecosystem is very important for the success of your API. You need your API to provide a valuable service to another party, whether that is a mobile application, a mashup or other enterprise solutions. At a bare minimum, this means tooling, code generation, documentation, open source projects and examples that use your API, recipes, best practices, etc. Pre-built connection points to other major applications within your ecosystem can also be quite valuable. For example, if you are providing an application within a vertical, it can be beneficial to have not only the base APIs and SDKs for general purpose integration, but pre-built components on top of these for other major providers in your vertical to interact with your system natively.
TMC: What differentiates one ecosystem from another?
PT: I think what vertical you are participating in, what your go to market strategy is and who your target customer base is will dictate the right ecosystem for you. Ecosystems can take the form of Cloud Marketplaces (e.g. AWS vs. Azure vs. Bluemix), open source communities, standards bodies or partnerships with other providers. Often, it might make sense to participate in several of these ecosystems.
Why should attendees at All About the API make sure to attend your session/booth?
I love to nerd out about technology in general, but the topic of APIs and why they are important is one of my favorites.
A rapidly increasing need for APIs and similar measures is expected to drive big gains in this market through 2021.
Doug Waller of Flowroute will be taking part in a panel at the All About The API event, collocated with ITEXPO, to discuss common mistakes that occur …
Google has teamed up with H&M's digital fashion house Ivyrevel to use its Awareness API in a unique way. The duo wants to digitally design customized …
Open source has become an integral piece of every developer's arsenal. The power of the community, the wisdom of many, and the ability to hook into va…
Google's in an interesting place with Hangouts and chat with both the enterprise and the consumer. One thing is clear - what it's doing with Hangouts …