Contributor

3 sets of APIs your SaaS platform needs

opinion
Dec 15, 20153 mins

Well thought-out public APIs differentiate successful SaaS platforms from their competition

Public APIs give customers access to the internals of the SaaS platform
Credit: Thinkstock

Software as a service (SaaS) is a subscription-driven software licensing mechanism. The software vendor owns and hosts the software in a cloud environment.

Both the vendor and the customers take advantage of the economies of scale associated with this model. A SaaS that exposes public API has a significant advantage over competitors that do not. A well thought-out API (application programming interface) makes it easy for SaaS customers to integrate with other applications they use. Citizen developers can roll out useful purpose-specific apps without IT red tape. Third-party vendors can build apps that may expose new uses that the SaaS vendor may not have thought of.

Let’s go over the three sets of API that SaaS vendors must provide to make their platforms successful.

1. Authentication, authorization and user management API

Managing users is one of the core API services that any SaaS must have. This service makes it possible to add and remove users, as well as control access to features and data.

Users should be able to manage and reset their own passwords. Your customer’s help desk employees need be able to act on behalf of the frustrated user.

In my previous post I talked about how a successful API strategy begins with implementation of the OAuth 2.0 protocol. Rather than implementing your own, consider reusing an existing enterprise SaaS platform. For example, if your target users already have access to Office 365, you may rely on Office 365 OAuth 2.0 and Azure Active Directory API. Users get password and account management tools as part of their user experience, leaving the SaaS vendor to focus on the business vertical.

2. Operational data store API

No enterprise application supporting an important business process exists in a vacuum. Operational data store integrates data into a structure that makes sense for your SaaS.

It is important to make it trivial for third-party or citizen developers to integrate with your SaaS platform. You will need to cover the basics:

  • Initial bulk load of data
  • Replication of data
  • Bulk export of data
  • Inbound data update notifications
  • Outbound data update notifications
  • Query and reporting

The integration API should seamlessly fit into the ESB tool chain. Take a popular commercial ESB such as Mule or an open-source one like Apache ServiceMix and make your API workable with it.

3. Usage metrics collection and logging API

Usage metrics is crucial in determining how to support, extend and monetize the application. When frustrated users call you will need to know what led them to the bug. Knowing how they use your application’s user interface can help you make them even more productive. Key application metrics can help predict periods of increased usage.

There is no need to reinvent the wheel. Take advantage of existing tools such as AWS Mobile Analytics, Visual Studio Application Insights and Google Analytics.

Now what?

If you are a customer looking for a SaaS platform for your business vertical, you will need to customize and extend it. The API is what lets you do that. Ask your SaaS vendor for documentation, code examples and best practices. Make sure the API covers your needs and the areas listed above.

If you are a SaaS vendor make sure your API covers the basic needs of your customers. There is no need to overcomplicate it or reinvent the wheel. Relying on existing cloud services and integration practices helps control time to market. Consider what your competitors in the industry have already done and use open standards.

Oleg Dulin is a Big Data software engineer and consultant in the New York City area.

In 1997 Oleg co-founded Clarkson University Linux Users Group. This group was influential in bringing awareness of open-source to Clarkson, and later morphed into what now is a dedicated lab and curriculum called Clarkson Open Source Institute. While at Clarkson, Oleg advocated on behalf of open-source and Linux and community and helped with construction of Clarkson’s first open-source high-performance computing cluster called “The North Country.”

While at IBM T. J. Watson Research Center in 1999-2000 Oleg co-authored a paper on federated information systems that was presented at Engineering of Federated Information Systems (EFIS) conference in 2000. This R&D project involved building a proof-of-concept federated IS that integrated structured (SQL) and unstructured (multi-media) data under a single set of API and user interfaces.

From 2001 to 2003 Oleg worked as a data integration consultant at a major investment bank in NYC on a web portal for private banking. This project involved aggregation of secure financial data from multiple legacy databases and presenting it in a customizable web portal.

In 2004, while working at a startup called ConfigureCode, Oleg contributed to two patent applications involving construction and semantic validation of mixed-schema XML documents. This technology was utilized in a Data Capture and Tracking System for Human Resources data integration.

From 2005 to 2011 Oleg worked at a Wall St. company (see Oleg’s LinkedIn Profile for more details) where he was instrumental in improving data quality, reducing trading errors, implementing analytics and reporting within the context of an equities order management system. The system was a 24/7 high performance computing platform that processed billions of dollars worth of trade executions daily.

From fall of 2011 to end of 2016, Oleg worked at Liquid Analytics as Cloud Platform Architect, where he was a thought leader in the implemention of a cloud-based PaaS for mobile Business Intelligence.

Presently, Oleg works at ADP Innovation Lab as Chief Architect.

The opinions expressed in this blog are those of Oleg Dulin and do not necessarily represent those of IDG Communications, Inc., its parent, subsidiary or affiliated companies.

More from this author