Innovator Spotlight: Innotas »

Innotas is a leading provider of cloud solutions for IT Management. The company helps IT managers align their resources, budgets, and time with strategic business objectives through the Innotas Project Portfolio Management and Application Portfolio Management solutions, both delivered as software-as-a-service (SaaS).  Since it was founded in 2006, Innotas has been committed to helping CIOs and IT management gain visibility across initiatives and sustain existing operations. 

Tim Madewell, Innotas senior vice president of services, spoke with Apigee about the Innotas API and how they use Apigee to gain critical visibility and make better business decisions.

What is Innotas' API strategy?

We offer an API that is different than many APIs today. Instead of using an API to expose our back-end data or Web services, the Innotas API was built to enable our customers to easily integrate the Innotas IT governance solutions with their back-end CRM, HR and billing systems. Providing an API where customers can ‘come and get it’ has worked especially well for our large customers, who often have the resources to take the API and run with it to make the integrations happen. We also now offer a turnkey platform in which we build and maintain the integrations for our customers.

What opportunity were you addressing with this API?

We had a compelling event – a customer needed it. In the early days of our company, our average customer size was 25-30 users. But as we started to grow and the SaaS market became more mature, we started working with larger enterprise customers that required a level of integration with their back-end CRM, HR, and billing systems. 

So we published our API to meet the needs of a large division of a F1000 customer. In hindsight, offering an API for integration was a great decision early on - it gave our customers a lot more flexibility, including writing the process orchestration around our API to meet the specific requirements of their organization. 

How has the Innotas API evolved?

We offered a SOAP API as the first version, but now we’re evolving. In August of 2011, we launched our integration platform where we will build, deploy and manage the integrations for our customers.  Our new platform will be powered by REST APIs.

How do you work with Apigee?

Apigee is our API cockpit, where we can view and manage details about our APIs, and use this information to make informed business decisions. We started working with Apigee Enterprise shortly after we published our API to give us visibility and control over our API usage and provide a consistent level of service to thousands of clients on a single SaaS platform.

Initially, we were primarily using Apigee Gateway as a solution to help us understand who is making API calls, what entity they are hitting, how often, etc. This detailed visibility into our API usage helps us quickly triage and troubleshoot as required. Over time, we extended our use of Apigee to include load balancing and analytics.

How do you Use Apigee Analytics?

Apigee's real-time analytics is my executive dashboard for operations.  I use the analytics all the time see what's happening – it's the first place I go to see integration traffic, even before I look at my real-time monitors. Just yesterday an outage triggered, and with Apigee's analytics, I could identify the root cause in about a minute.

One of our key requirements has always been visibility…you can’t govern what you can’t see. Before we started using Apigee's analytics, all of our customers' activity was intermingled in the system logs with all the other system-generated events. Figuring out who is doing what was almost impossible and it was difficult to track back the events that were related off of just a user ID – which is the wrong key. We needed the visibility to be able to relate calls together and construct what happened with meaningful data.

Once we had this, our second evolution was around maintenance and support. Before, when a customer called and said “it’s not working right” all we could say was “go look at your code.” But with API analytics we can capture the payload – trap the data for the customer – and use our API debugging tools to help them ID the problem message.

We also use API trend reporting at a macro level over time - common calls, common integration. This gets fed into product management, sales, and performance tuning to make the product better.

What benefits have you gained from Apigee?

Apigee is our eyes and ears for our APIs.  The visibility we get into customer usage has definitely enabled us to better manage costs and efficiencies. The daily Apigee data help us understand customer stickiness and retention – which has helped us maintain a consistent 90 percent renewal rate.  And understanding customer usage trends and patterns has absolutely helped us make more informed business decisions.

Big Broad Data: The role of Data APIs »

In previous posts on this topic of Big Broad Data, we looked at some of the reasons for and implications of enterprises shifting their focus from the “bigness” and technology hype of “Big Data” to breadth and diversity, signal extraction, analytics and deep insights.

The future is around the easy consumption, the flow and interaction of data, which drives a revolution in the world of Data APIs. The structure of the Data APIs becomes increasingly important.

Building an Information Halo around APIs

Let’s consider enterprises as one of two types from a data perspective: those for whom data is the core business and those who give data away to attract increased transactions to the core of their business. 

In the latter case, the data (information) itself is not necessarily monetizable, but it attracts people to the business.

For a great discussion about the notion of information halos around your core business, see Sam Ramji’s talk: Amundsen’s Dogs, Information Halos and APIs: The epic story of your API Strategy.

In both scenarios, data is a fundamental and critical part of an API strategy

Enterprises who are monetizing around data are beginning to plant flags in different domains. Weather, finance, real estate, Internet traffic and dozens or hundreds of other domains are forming.

The people building the data in any domain are doing so by collecting from disparate data sources. To build out any one domain, they’ve probably stitched together data from a large number of data sources, cleansed and standardized it before finally exposing it as an API.

What are companies using to collect and stitch the data?

A natural and familiar stitching technique is the linked data model (linkeddata.org). While linked data techniques are excellent at accessing individual data elements, I argue that this is not the model that these data providers need. Instead they need to crawl, bulk load, and access data in large quantities, before cleansing, standardizing, and delivering it.

If linked data is not the most effective method to stitch data together to create the domains (at the bottom of the stack), can linked data become the de-facto standard to express data out of the information halo (at the top of the stack and as the Data API for domains)?

The answer is probably yes – eventually. I think it is an unlikely scenario just yet. Today, the challenge is how to cleanse, standardize, unify and use the data in individual domains. Linked data techniques have the right characteristics to bring together data that have already been cleansed, standardized, and stitched but is not a great model to do the initial stitching. It will most likely become useful and common in the future when the inter-linking of domains becomes more important than it is today.

If linked data is not the approach to expose data as APIs, what is?

The school of thought to which I subscribe is one of schema-based access to data APIs patterned after relational models. Here are a few examples of data APIs, which highlight three common kinds of data access patterns.

* Primary key lookup - to get to a specific data element.
* Imposed hierarchy-based lookup - in which you have classes with hierarchy and in effect traverse the hierarchy to get to the data elements.
* Rectangular lookups - defined by typical relational lookups of rows and columns.

All of these techniques are being built around single data sources as opposed to massively linked data sources.

The structure and “RESTification” of  Data APIs

There are several approaches to Data APIs. In addition to the perspective that is Pragmatic REST for SQL Developers, there’s Microsoft’s OData approach. As I asserted in a recent talk at an OData Meetup event at Microsoft, OData is a step in the right direction but there are certain things OData needs to do to become the de-facto standard.

The “RESTification” of the Data APIs is a fundamental imperative and both the Pragmatic REST for SQL and the OData approaches are good starting points.

Whatever the solution is, it cannot be vendor specific. Data is too important, and the data revolution too fundamental for it to be associated with any one vendor.

OData technologies need to be available in all ecosystems, not just in the Windows Foundation Classes (WFC) library and the .NET Framework. Similarly pragmatic REST and other techniques cannot be available in Apigee or any other single vendor offering only.

Let the call to action be to come together as a community; get the best of the linked data and OData ideas and techniques together and transform the world with Data APIs.

The conversation has already started and we’d love to hear more of your perspectives and arguments over on api-craft.

Innovator Spotlight: Pearson Plug & Play Platform »