Analyst(s):Paolo Malinverno, Mark O'Neill
It is impossible to provide the platform for any digital strategy, and run an effective API program to benefit from the API economy, without full life cycle API management. Our analysis of 19 vendors in this market helps application leaders find the best platform to fit their strategy and planning.
This document was revised on 30 November 2016. The document you are viewing is the corrected version. For more information, see the Corrections page on gartner.com.
Full life cycle API management is about the planning, design, implementation, publication, operation, consumption, maintenance and retirement of APIs. It includes a developer's portal to target, assist and govern the communities of developers who embed the APIs, as well as the runtime management and analytics. Gartner used to refer to full life cycle API management as "application services governance," and offered a corresponding Magic Quadrant. This Magic Quadrant therefore replaces the 2015 Magic Quadrant for application services governance.
Focus has shifted toward API programs and their fundamental role in the execution of digital strategies, which includes getting value out of the API economy. Projects have become smaller (focusing on very few APIs at any one time) and more business oriented, and require very quick execution. Buying centers, meanwhile, are shifting rapidly from IT departments to business units. Digital strategies, application rationalization, the API economy, bimodal IT, the evolving notion of applications/apps and changing API consumers (both human and smart objects, as in the Internet of Things) will significantly drive the application portfolio of the future — and APIs are right in the middle of it all.
Full life cycle API management is the functionality organizations need in order to provide the technology platform for digital business (see "Building a Digital Business Technology Platform" ), run successful API programs and thrive in the API economy. The API economy is a set of business models and channels — based on secure access of functionality and the exchange of data to an ecosystem of developers and the users of the app constructs they build — through an API, either within a company or via the internet, with business partners and customers.
APIs have always been everywhere, but were rarely used by anyone other than the development group that designed them. The basic principle of the API economy is that APIs can be new products that a company offers in order to open up new business channels, or to sell more of its traditional products.
However, understanding which APIs to offer to which developers' constituencies, as well as securing corporate data and functions, can be challenging. Despite which, hundreds more APIs get published every month and thousands of them are tried and tested by all sorts of developers every day. When we use a smartphone app or book a ticket for our favorite concert, we use APIs; we already live in an API economy.
Certainly the API economy is only just beginning to emerge, and the hype around it is still growing as digital strategies and the pervasive use of the Internet of Things (IoT) unfold. An organization's API strategy underpins its digital strategy — and is a sizable portion of it — so engaging with the API economy is an integral part of any digital strategy.
Several business models are associated with publishing APIs. Companies gain different types of value from publishing APIs or running hackathons, value that goes beyond just enhancing the company image by appearing innovative. In some cases, especially when the product can be delivered electronically (for example, TV access to yesterday's final of a sporting event), companies can charge directly for the use of APIs. However, the most common model in the API economy today is indirect — a company provides free access to the APIs they publish in return for the leaner/quicker/more efficient execution of a business process (such as ordering goods in a supply chain), or for increased sales of a traditional product (for instance, travel companies get more bookings if they publish APIs into their reservation systems to enable developer access).
One of the taglines of Gartner Symposium keynotes is: "Every company is a technology company." APIs make this work. Starting in media and high tech, APIs have now moved into financial services, government, healthcare and retail. During the past two years, a critical mass of companies and government institutions has been publishing APIs in their developers' portals to fuel B2C innovation, enable the use of mobile apps and take advantage of more direct B2B interactions with their business partners. Publishing APIs will continue to fuel the API economy and the best is still to come.
APIs are increasingly crucial to application strategies and effective modern application governance. However, most future API use will come from digital business applications and smart objects (as in the IoT), and APIs will be firmly tied to business scenarios.
Source: Gartner (October 2016)
Akana, founded in 2001, made the move to API management from its initial focus on service-oriented architecture (SOA) governance (and changed its name from SOA Software in the process). Akana's strengths in life cycle governance and repositories, forged during its focus on SOA, continue to underpin its API management offerings. These offerings include features such as dependency analysis of the impacts of API versioning, and a well-defined policy model that decouples APIs from policies.
The Akana Platform is Akana's API management offering. It is available on-premises and in the cloud, with momentum moving increasingly to the cloud. The solution includes API Gateway, API Portal, Lifecycle Manager, and API Envision, which provides analytics. Akana has been integrating the platform by unifying the user experience across the various products.
Akana sells mainly in North America, but has customers worldwide.
Akana's strong service governance background brings solidity to its management of the full API life cycle.
Akana supports a wide range of API security standards and features. This means that its solution can be used for identity-related use cases that leverage Security Assertion Markup Language (SAML), OAuth and OpenID Connect.
Vertical markets are important to Akana. It has developed solutions for HL7's Fast Healthcare Interoperability Resources (FHIR) in healthcare, and has focused on a solution to facilitate compliance with the EU's revised Directive on Payment Services (PSD2) in financial services.
Akana faces the financial challenge of moving the license-based revenue of an on-premises offering to the deferred revenue recognition typical of cloud pricing models, while consolidating its refocus from SOA governance to API management, and unifying its solution. The rise of open-source API management solutions — modern technology built on established tools such as Nginx and Node.js — compounds the challenge for Akana. Also, a new CEO was appointed at the beginning of 2016, to establish a more focused strategy and lead its execution; early signals are positive.
International reference customers report difficulty in obtaining deployment support in terms of both geographical availability and expertise.
Akana's API developer portal provides fewer customization capabilities than those of its competitors.
Apiary, a new entrant in this year's Magic Quadrant, is a U.S. company founded in the Czech Republic in 2011. Apiary markets a platform for the API design life cycle and is the sponsor of API Blueprint, an open-source markdown language for describing APIs.
Apiary's offerings include Apiary Free, Apiary Standard, and Apiary (the full offering that helps organizations build uniform APIs across different development teams). Apiary's offerings mainly apply at the design and implementation stages, but also include comprehensive versioning functionality. For the remaining life cycle stages, Apiary partners with other API management providers. It does not directly offer an API gateway or a developers' portal.
Apiary's offerings are U.S. public cloud only, and sold mainly in the U.S. and the EU.
The Apiary platform encourages and guides API providers through an iterative API design life cycle. It supports a deliberate product-based approach whereby business stakeholders can prototype APIs, expose them to the eventual API consumers, and get their feedback by inviting them to participate in the design process.
Apiary has a simple but powerful design-centric vision for its business, based on rapid prototyping and maintaining up-to-date documentation in an API-centric approach. Its reference customer scores for overall satisfaction with the platform are high.
Apiary partners with Oracle and 3scale to provide an API gateway and a developers' portal. However, due to 3scale having been recently acquired by Red Hat (see the Red Hat [3scale] section below), Apiary's partnering strategy might be revised.
If your APIs are designed already — because, for example, they come from an existing SaaS/integrated platform as a service (iPaaS) platform — Apiary's offering is not relevant to you.
Apiary is not very visible in the market due to its small size, exclusive focus on the API design stage, lack of track record and limited marketing activities.
Apiary's innovation mainly comes from internal R&D, customer feedback and requirements provided by sales contracts; it must broaden its outlook and vision to effectively compete in the fast-moving market of API management.
Apigee continues to advance its vision for API management, having been a key driver of the market since the shift from SOA to APIs, as well as being a loud advocate of APIs in general. On 8 September 2016, Google entered into a definitive agreement to acquire Apigee — this acquisition was not closed at the time of publication of this Magic Quadrant, so the evaluation of Apigee in this research is based solely on its capabilities as a stand-alone company.
The core Apigee API management platform, Apigee Edge, is available both on-premises and in the cloud. Apigee also provides Apigee Insights (analytics), Apigee API Exchange (telecom-specific functionality) and an IoT server. A recent addition to its capabilities is Apigee Sense, which provides cloud-based bot detection and protection. If an API on the platform is found to be under automated attack, other APIs can be proactively defended.
Apigee has recognized the trend toward smaller-footprint API gateways, particularly those based on Node.js, and has launched the Apigee Edge Microgateway (which leverages Node.js). This new offering is available on-premises and in the cloud, and helps to simplify deployment of the Apigee solution.
Most of Apigee's clients are in the U.S. or Europe.
Apigee's vocal marketing makes it well-known among API management prospects, and provides a platform from which its customers can target their own APIs to the appropriate constituencies of developers and spread their success stories.
Apigee's customers can leverage a community of peers — including API architects and business stakeholders — in conferences and as part of the Apigee Academy, which offers free online courses.
A recent partnership with Pivotal brings Apigee's API management to bear on applications built on Pivotal Cloud Foundry, which leverages platform as a service (PaaS) capabilities such as horizontal scaling and event processing.
The proposed acquisition of Apigee by Google is likely to have positive impacts on Apigee's current customers. However, it is too soon to understand the planned acquisition's far-ranging implications on the API management market and Apigee's product line.
As an independent company, Apigee has faced ever stronger competition from vendors with broader capabilities than just API management, such as iPaaS/hybrid integration platform (HIP) vendors and megavendors. If the announced Google acquisition goes ahead, this caution will have to be recast or removed as no longer valid, depending on how Google positions Apigee.
Open-source solutions present a challenge to Apigee (with or without Google), especially for simple use cases where simple API throttling and monitoring are all that is required, at least initially.
Axway has a long history in integration, B2B and managed file transfer. Axway acquired Vordel in November 2012, in order to mix integration, governance and cloud functions in a B2B infrastructure offering with API management capabilities. Axway acquired Appcelerator in January 2016, to expand its suite of digital business enablement solutions by easing API design and management, especially for mobile apps.
Axway's wide-ranging offering is API Management Plus. This comprises API Gateway (which includes a policy design tool, Policy Studio, and API Gateway Analytics), API Manager (which contains the API Catalog and the Registry of API consumers), the API developers Portal and the newly acquired Appcelerator Arrow.
Axway's main markets are in Europe and North America.
Axway traditionally leverages acquisitions well on the commercial side, and cross-sells effectively. The Appcelerator acquisition builds on the Vordel acquisition to effectively expand the reach of its offering, targeting companies using an API-first approach to execute their digital strategies.
Axway understands this market well — its product is functionally rich and it sees clearly the role of APIs as a platform on which to build digital strategies.
Axway is a diversified vendor, with an extensive product line and effective sales strategies in several geographies.
Axway has integrated the Appcelerator and API Management product lines. As frequently happens with acquisitions that add functionality to an existing offering, rationalizing these capabilities might cause some disruption to the installed base of both from a product strategy perspective.
Axway appointed a new CEO in June 2015. In a fiercely competitive market where marketing execution is of paramount importance in driving sales results, Axway has a mostly new group of marketing executives. These top-level changes have begun to show encouraging financial results, but will have to keep proving their effectiveness in the medium term.
Axway's offering is powerful, but to harness this power its customers need to go through a long learning curve: they might struggle to keep pace with the velocity required by the execution of digital strategies. Axway's slow innovation pace compounds this issue.
CA Technologies' product line comes from the acquisition of Layer 7 in 2013, which was initially positioned as part of CA's broad security and identity management offering. In late 2014, the product line was placed in a business unit of its own: to ensure that a larger set of digital business, integration, developer and mobile use cases were supported, in addition to all CA product lines taking advantage of it. In the past 18 months, CA has added CA Live API Creator to its API Management portfolio, which allows users to quickly build APIs for creating application back-ends for internal applications, mobile development projects, data-as-a-service exposure, IoT enablement and partner application integrations.
CA API Management is the overall brand and flagship offering, which includes Live API Creator, the API Gateway, the Mobile API Gateway, Mobile App Services and the API Developers Portal. The product line is now offered in cloud-only (called CA API Management SaaS under CA's nomenclature), fully on-premises and hybrid deployment options.
CA sells primarily in North America and Europe, but has been increasing both its sales and partner networks in Asia/Pacific and South America.
CA has a comprehensive and powerful offering, with solid security features and good coverage of API design, API management, mobile support, and the remaining full life cycle API management basic and advanced functionality.
CA has a strong product strategy and a geographically distributed sales force, with a track record of reliable execution across several regions.
CA's offering is highly visible and generally well known, thanks to years of effective and carefully targeted marketing efforts (especially since the last Magic Quadrant), a vocal API Academy and a range of public events through which it can demonstrate thought leadership.
CA will have to improve its ability to innovate and react quickly to new market trends: its API management is sometimes slow to address upcoming, fast-moving requirements, particularly in the execution of open API strategies for startups, or the setup of an HIP.
Some reference customers raised a caution about a lack of functionality in the developer portal and limited capabilities at the end of the API life cycle (versioning and especially retirement).
CA-wide marketing messages around the application economy sometimes overlap, reducing the effectiveness of the overall message about how CA API Management really addresses the API economy.
Cloud Elements, based in Denver in the U.S., is a relatively young company (founded in 2012) that focuses on solving the problem of organizing existing APIs for easy consumption. In particular, Cloud Elements allows APIs to be grouped into categories called API Hubs, which aggregate multiple APIs into a single interface. For API providers, API Hubs are used to present a unified API to their partners. For API consumers, they are used to create composite APIs that connect in turn to multiple cloud services within the same category (such as CRM or HR) or unifying APIs across disparate categories.
Cloud Elements' solution for API management, the Cloud Elements API Integration Platform, is available both on-premises and in the cloud. It provides API management capabilities in support of overall API integration use cases. Advanced security, analytics and monetization are provided by partners such as API gateway vendors.
For the IoT, Cloud Elements supports the Message Queuing Telemetry Transport (MQTT) protocol. This has enabled it to apply its API Hubs approach to use cases such as hubs for 3D printers, to connect to multiple cloud storage services; and for fitness apps, to connect to a variety of different wearable devices; in addition to common application integration use cases using its extensive catalog of prebuilt connectors.
Although most Cloud Elements customers are in the U.S., the solution is available worldwide.
As a small and nimble company, Cloud Elements has been fast to add support for technologies such as Webhooks and MQTT.
Pricing for the Cloud Elements platform is based on the number of API consumers, not the number of API calls. This means that enterprise customers can take advantage of unlimited API calls.
Cloud Elements has a catalog of more than 115 prebuilt, API-based connectors to cloud and on-premises applications and services. This means that Cloud Elements offers an advantage over general-purpose competitors that provide only the "building blocks" for customers to construct their own integrations.
Cloud Elements has low visibility in the API management market due to its limited marketing and events presence.
Cloud Elements also markets its solutions as iPaaS. API management in the Cloud Elements platform supports the vendor's overall integration focus; however, it lacks the advanced API management features, such as sophisticated security policies, which can be found in a purpose-built API management solution.
Cloud Elements has a very focused go-to-market strategy, almost exclusively leveraging an OEM go-to-market model through SaaS and digital application providers, thereby missing out generalized API providers and API consumers.
Dell Boomi is a business unit within Dell that provides API management as well as enterprise iPaaS and cloud master data management (MDM), all in a single platform called Dell Boomi AtomSphere. Two deployment models are supported for API management as a stand-alone offering: a cloud model for when all endpoints are cloud-based, and an on-premises model for when any of the endpoints are within a corporate network. To date, most API management customers have deployed on-premises.
In 2016, Dell spun out much of its software portfolio in Dell Software, but retained Dell Boomi. Dell's family of businesses — Dell, Dell EMC, Pivotal, RSA, Dell Boomi, SecureWorks, Virtustream and VMware — is aimed at providing infrastructure for organizations to build their digital future, transform IT and protect their data. Dell Boomi also has an active partner channel, including well-known SaaS vendors such as SAP SuccessFactors and Concur (also an SAP company), which license Dell Boomi under an OEM agreement as part of their service offerings. An MQTT connector has been added for IoT use cases.
Dell Boomi's offering is sold worldwide and has expanded well into Europe and Australia.
By combining API management, MDM and iPaaS in one offering, Dell Boomi allows customers to take advantage of a unified solution. The solution supports hybrid API deployment (cloud and on-premises) with centralized, unified management.
Dell Boomi's inclusion in the newly formed Dell Technologies — along-side well-established divisions such as VMware, Pivotal and RSA — shows Dell's commitment to, and belief in, the future of Boomi.
Dell Boomi continues to expand an already strong partner network, with more than 2,000 Boomi-certified professionals at more than 200 global and regional partners. A total of 29 independent software vendors act as OEMs for Dell Boomi as part of their service offering, including well-known SaaS vendors.
Since API management, its primary use case, is offered as part of an overall integration solution, Dell Boomi has only standard capabilities to offer for pure API management. In particular, the solution is lacking an external developer portal — something highlighted by a number of organizations that chose alternative vendors.
Dell Boomi lacks support for helping organizations plan their overall API strategy, including identifying business outcomes and opportunities for API monetization.
Dell Boomi has low visibility in the market as the provider of a pure-play API management solution; its offering is generally seen as primarily an integration solution.
Founded in 2000 and with a deep background in the SOA world (where lessons learned have been applied to REST), digitalML brings a model-driven approach to API design; it is new to the Magic Quadrant this year. Its ignite Service Design Platform offers a methodology to help customers import and view existing assets, including Web Services Description Language (WSDL) and data model files, identify coverage gaps in their API portfolio, and plan what needs to be built. The ignite platform, available both on-premises and in the cloud, supports API product owners in planning, designing and building API changes via integration with tools such as Atlassian's Jira.
In addition to API design, digitalML supports business enablement through features that allow planners to align the API portfolio to business capabilities and business glossaries. Overall, this is intended to aid customers in creating a business-led portfolio of APIs.
Key initiatives to support customers include hosting an annual Service Design Forum — aimed at practitioners, data architects, business analysts and other stakeholders — to share experiences on API planning and design. Due to the level of mindset change required for this approach, professional services is a more important part of it than with most other vendors.
digitalML's typical customers are very large organizations (with more than $10 billion in revenue) that need help creating APIs and defining an associated business strategy. The majority of digitalML's staff is U.K.-based, but its customer base is predominantly U.S.-based — in the retail, insurance, healthcare, telco and financial services verticals.
digitalML's model-driven approach to API planning, design and building appeals particularly to enterprise architects and business leaders, especially those with a background in SOA. This makes it a good choice for organizations wanting to ensure a portfolio of APIs that is fully governed, reusable and consistent, and adheres to policies (such as security).
There is an active community of architects at digitalML who can discuss service design and have wide international experience of complex projects, generally in large organizations.
digitalML offers broad legacy support, such as SOAP services and messaging, and the integration of enterprisewide SOA endeavors. This provides a strong data lineage capability.
digitalML's "inside-out" approach — designing APIs based on pre-existing data architecture — is at odds with the current move toward an "outside-in" approach to API design.
The ignite platform integrates with the API gateways of IBM, Amazon, Apigee and WSO2; however, because digitalML does not provide an API gateway or API developer portal directly, customers must source these products separately if they do not already have them.
API management competitors of digitalML are adding similar API design and planning capabilities to their full life cycle API management offerings, which might displace digitalML's focus on the planning, design and build life cycle stages.
IBM's API management offering is IBM API Connect (previously known as IBM API Management). It is available both on-premises and as cloud SaaS. IBM API Connect is available at three levels: Essentials, which is free for developers; Professional, which is for small or midsize businesses and is priced according to API call volume; and Enterprise, which is for higher call volumes and has the flexibility to shift from on-premises to cloud deployment.
IBM API Connect includes two API gateway options: a Micro Gateway based on Node.js (through IBM's 2015 acquisition of StrongLoop), and an Enterprise API Gateway (the virtual software edition of the established SOA-era DataPower Gateway). Both gateways are available with the Professional and Enterprise offerings. StrongLoop's LoopBack framework supports the creation of APIs. The developer portal is based on the open-source Drupal content management system. API testing is provided on IBM's Bluemix PaaS. Analytics is provided using the ELK Stack (Elasticsearch, Logstash and Kibana).
API Connect (including DataPower) is also bundled within IBM MobileFirst Foundation to support features such as mobile notifications and the creation of mobile-friendly RESTful APIs.
IBM's offerings are sold worldwide.
IBM has an established and powerful market position and a solid customer base in several vertical industries. It has worldwide support capabilities and diversified geographical strategies.
The functional capabilities of IBM's offering for full life cycle API management have improved consistently during the past year: the acquisition of StrongLoop and the integration with IBM Bluemix Cloud have added to that.
IBM has increased innovation and scalability through API Connect's Micro Gateway. This gateway is in close proximity to the microservice or back-end system, which is exposing the API and then scaling this across multiple APIs and microgateways.
The linkage with many other IBM offerings, with some integrations still a work in progress, can lead to increased cost and complexity.
The IBM DataPower Gateway, although now available in a virtual edition, is a very mature offering and shows its age (for example, XML is the basis of most functionality, rather than REST).
While IBM has been a leading proponent of digital transformation, API Connect does not yet provide embedded API billing and rating features for clients seeking to charge for API usage; it relies instead on partnerships with billing solution providers.
Mashape, a new entrant to the Magic Quadrant this year, was founded in 2010 and launched the API Marketplace in 2012 — with the goal of becoming a large API hub and marketplace. In 2015, Mashape decided to enter the API management space and introduced Kong (an open-source API gateway platform). Kong was originally built to secure and manage the marketplace, which today consists of tens of thousands of private and public APIs as well as hundreds of thousands of active developers, generating billions of requests per month. In the course of 2015, Mashape acquired a developer portal and added testing and an analytics engine.
Mashape's full product line is generally referred to as Mashape Enterprise or KGG (Kong, the API gateway; Gelato, the developers' portal; and Galileo, the analytics engine) and is available both on-premises and in the cloud.
Mashape's offering is available worldwide. Half its revenue (from support and subscriptions to the developers' portal and analytics) is already from outside the U.S.
Mashape has a simple, extensible, open core API management offering. It covers mainly the "deploy and run" life cycle stage (and basic functionality for implementation and versioning), addressing the hunger for this open-source type of solution, which has consistently grown during the past year.
Without a formal sales organization or strategy — mainly using social media, organic and integrated partnerships, open-source communities referrals and event presence — KGG has come from nowhere to having hundreds of self-service, low-touch cloud customers and several enterprise customers in just over a year.
Mashape has a good understanding of users' priorities in this market, and a clear product strategy to enrich the platform and address them.
Mashape is one of only a few independent API management platforms still in business and it makes use of investor funding to fuel additional growth. It therefore makes an attractive target for acquisition by a larger player.
Mashape is facing growing pressure: competition for fully open-source API management offerings is mounting; several small players are growing well; and the acquisition of 3scale by Red Hat is going to represent a fully functional alternative.
Mashape's offering is very young and just beginning to be proven by enterprise users. Its offering is mainly targeted at fast moving, microservices-rich projects, but overlooks users' advanced priorities beyond the first six to nine months of an API program.
MuleSoft is a provider of cloud and on-premises integration software. Anypoint Platform for APIs, a part of MuleSoft's Anypoint Platform, is its full life cycle API management solution.
An API Designer, API Developer Portal, the API Analytics component and API Gateway make up the solution. IoT protocol support has been added, and the core Mule API gateway runtime (though not the full API management platform) is small enough to be considered for deployment on small-footprint devices.
MuleSoft's offerings are available worldwide.
MuleSoft has shown effective marketing and thought leadership in the API management market, as well as other related markets such as iPaaS. Its aggressive growth strategy has resulted in rapid customer acquisition and corresponding revenue increases during the past 12 months.
MuleSoft provides open-core enterprise service bus (ESB), iPaaS and API management, with a common bundle/pricing model. These are linked because APIs are widely used for integration and orchestration of application and data logic.
Through API Designer, as well as the ability to create APIs from scratch and leverage a wide array of connectors (both cloud and on-premises), Mulesoft provides customers with the technical start to an API program (but not the business start, because the MuleSoft Catalyst offering is still evolving).
MuleSoft combines integration and API management — an attractive solution for customers requiring both, but potentially more than needed (in terms of cost also) for organizations with an ESB and/or iPaaS already.
MuleSoft's engagement with organizations is either bottom-up, through API developers, or as part of integration projects. It is lacking in the business-level API planning for API programs that is linked to overall digital strategy. Unlike its larger competitors, it is generally not engaging at CIO level. The top reason why organizations chose an alternative vendor was if MuleSoft was not viewed as a strategic partner.
There is often an assumption that MuleSoft is completely open source, and a lot of its API-related components are, but the API Gateway and the Developers' Portal are not. Alternative fully-featured and open-source offerings are emerging.
Oracle has a long tradition in the application infrastructure market. In Gartner's 2014 SOA governance Magic Quadrant, Oracle had a leading offering for SOA governance, which did not evolve into API management. To fulfill API management requirements in its client base, Oracle had an OEM agreement for the Vordel (now Axway) API gateway, which it then resold as Oracle API Gateway (up to the end of 2015). However, Oracle made an earlier decision to start a brand new product line for API management. This emerging product line was too nascent to be included in the analysis for last year's Magic Quadrant. Since then, the offering has become viable and Oracle has satisfied the entry criteria to be reincluded in our Magic Quadrant.
Oracle's full product line is generally marketed as Oracle API Platform Cloud Service. Today, Oracle offers API Manager, API Manager Cloud Service, Oracle API Catalog, and Oracle Communications Services Gatekeeper. These will consolidate into API Platform over time.
Oracle's offering is available worldwide.
Oracle has a simple and evolving API management offering, with powerful API design (thanks to a partnership with Apiary), mobile back-end options (thanks to Oracle Mobile Cloud Service), and effective integration with the rest of its application platform.
Oracle is a major force in application infrastructure, with a long track record. As more API management capabilities are added to its offering, it will become more usual for it to be included as part of larger application infrastructure deals.
Oracle has proven global sales and support for application infrastructure, leveraging a large installed base.
Oracle's offering is still young, and its functionality in policy management and the developers' portal need to be enriched to be comparable with competing products in API management.
Although offered as a stand-alone solution, the Oracle API Platform is often sold as part of larger application infrastructure deals, or cross-sold within its installed base.
Given its relative newness to the market and aggressive product strategy, and if Oracle were to acquire related technology, clients should work closely with Oracle to stay abreast of its product roadmap and partner strategy.
Red Hat has become a highly successful open-source software vendor, demonstrating that a subscription model can be financially rewarding for both software developers and buyers. Red Hat addresses a broad spectrum of OSs, infrastructure as a service (IaaS) offerings, virtualization and containers, middleware/PaaS offerings, and the management tools to control these.
In June 2016, Red Hat announced its acquisition of 3scale. Founded in 2007, 3scale was a focused and mature API management vendor. It offered a distributed architecture (partly open source) with on-premises agents and policy management in the cloud — which is different from the on-premises gateway or cloud intermediary model of most other API management vendors.
The primary offering of 3scale is its API management platform. There is no brand distinction between its on-premises or cloud offerings, which might change under Red Hat.
Red Hat plans to make the whole of its 3scale offering open source and market it worldwide.
3scale has built a fully functional API management platform, including a full-featured developer portal. Red Hat gives a totally different scale to this offering in terms of sales power, geographical distribution, and ties with other application infrastructure and integration products.
3scale brings to Red Hat a solid understanding of this market and a powerful vision, as well as a deep understanding of users' main priorities.
Red Hat is the clear Linux market leader and has established a strong market presence in application infrastructure. It will soon offer a powerful, fully open-source API management platform, which the market shows a strong demand for.
Even if this acquisition seems (on paper) to be an effective fit of two companies — in terms both of product offerings and company cultures — it is too early to say how the integration will actually go.
3scale always was very responsive to new market trends, which made up for its lack of formal innovation processes. As innovation in this market is essential, 3scale must improve its innovation capabilities now that it is being immersed in a much larger entity.
Mainly because of its small size and technology culture, 3scale's marketing was never loud or incisive. Effective marketing will be essential from now on as it will have to find its voice and harmonize with Red Hat's more overarching marketing campaigns.
SAP has a long history in the application infrastructure market, offering middleware and SOA tools through the NetWeaver family of products. SAP licenses Apigee technology for both its on-premises SAP API Management by Apigee solution extension, as well as its SAP Hana Cloud Platform (HCP) API management service. Apigee supports SAP in marketing API management technology to SAP's customers and prospects. During the past year, SAP has been focusing on integrating API management with the plethora of other offerings it markets. It has started a major marketing campaign centered around helping its clients to execute their digital strategies on top of the SAP platform.
SAP is not likely to compete in the pure-play API management market, but it needs API management capabilities to support its overall application/SaaS strategy.
The on-premises edition of SAP HCP API management is a solution extension, through a re-seller agreement with Apigee. The cloud edition is part of the public cloud SAP HCP; SAP has an OEM agreement for Apigee Edge and uses it as the API gateway. Additional API management capabilities such as the API developer portal as well as analytics are built by SAP to provide tight integration to SAP landscapes as well as to other SAP HCP services such as the integration services and the OData provisioning service.
SAP markets its SAP HCP API management offering worldwide, and diversifies it through its digital strategy over a number of industries.
SAP has a sound understanding of users' priorities when it comes to digital strategies and the enabling role an API program plays in that. This has made its API management offering strategic for its entire product line.
SAP has a huge installed base for applications. It is executing a strategy based on enabling its customers to have a digital core (S/4HANA) by providing "real-time," cloud-ready products and solutions. Its financial results are strong.
SAP HCP's API management has powerful design capabilities, including a wizard-driven capability to create and secure an API from underlying systems supporting SOAP and plain REST as well as hypermedia formats such as OData. It also supports integration with SAP platforms — such as HCP, mobile service; platform integration services (iPaaS); HCP, Internet of Things service; identity, or single sign-on — through the SAP Gateway.
SAP offers API management technology as part of a larger digital transformation platform. Even if SAP API Management can be used stand-alone, customers will get most benefit in combination with other SAP offerings. If SAP does not play a major role in your application strategy, your API management needs are likely to be addressed more effectively by competing offers.
Reference customers report low satisfaction scores with SAP's API management solution overall, pointing out that it is difficult to use.
Google's planned acquisition of Apigee might affect its OEM agreement with SAP, and SAP's strategy for API management going forward.
Sensedia, a new entry in this Magic Quadrant, is a subsidiary of CI&T (a large Brazil-based system integrator). Sensedia's solution for full life cycle API management is provided by its API Management Suite, in combination with associated professional services. The technology stack underpinning Sensedia's solution is based on a combination of open-source projects that include Drupal and MySQL.
Consultancy, including a "digital maturity assessment" and general API strategy services, is provided by CI&T. CI&T delivers a "digital playbook" covering the path from strategy to large-scale implementation of APIs, as well as change management. This process covers the business and technical aspects of APIs. Sensedia itself runs an API conference (API Experience) in Brazil, which has included speakers from Google, Spotify, Fitbit and Twitter.
The Sensedia API Management Suite is available both on-premises and in the cloud. Cloud deployments greatly outnumber on-premises deployments. In addition, Sensedia has a significant number of services-only customers, to which it provides strategy consulting, integration guidance and developer outreach services.
The Sensedia API Management Suite is used in CI&T's industrial IoT solution, running on the Google Cloud platform. The solution supports HTTP, MQTT, device registration and management, as well as over-the-air updates.
Sensedia also markets a banking API solution focused on key banking requirements for APIs. It also offers solutions for insurance, e-commerce and payments.
Sensedia has a high level of customer satisfaction, and ensures that deployments successfully go live in a managed way. CI&T consultancy also provides close support.
Sensedia understands the industrial IoT usage of APIs at scale.
Sensedia provides solutions that specifically address the usage of APIs within financial services, including for marketplaces and payments.
Sensedia has limited geographical reach beyond its home territory of Brazil.
Sensedia's solution stack has been put together with many "moving parts" from open-source components. Sensedia has integrated its solution into a unified product, but often in cases like this — especially for a young platform like Sensedia's — this may lead to support challenges.
Sensedia offers a relatively basic feature set. Customizations that require consultancy engagements are carried out by Sensedia's own professional services, but can also leverage resources from CI&T, which has a team focused on services around the Sensedia API Management solution.
Evolving its offering from its SOA governance background, Software AG provides full life cycle API management under the webMethods API Management Platform. Products within its API management solution are CentraSite (a registry/repository), webMethods Mediator (a mediation layer), webMethods Enterprise Gateway (an API gateway), and webMethods API-Portal.
The solution is provided within Software AG's overall Digital Business Platform product area. As well as API management, this platform targets hybrid integration capabilities including B2B integration, cloud integration, messaging and managed file transfer. The runtime platform is built on an event-driven architecture, which is well-suited to modern, high-traffic API use cases, including the IoT. Data synchronization APIs are provided for mobile.
Software AG addresses the planning stage of API strategy in a number of ways: with its Architecture of Integrated Information Systems (ARIS) tools for requirement gathering, business process management and enterprise architecture modelling; through API discovery and readiness workshops; using CentraSite and API-Portal for service cataloging; and in documented API planning advice, which includes the identification of business and technical stakeholders.
With headquarters in both Germany and the U.S., Software AG's API management offering is sold worldwide.
Software AG has been advancing its support of customers running a digital strategy that includes streaming analytics and in-memory computing. These capabilities complement its API management offering.
A strong installed base and credibility in the application integration/ESB markets brings upselling opportunities as well as a strong technology foundation. Software AG is particularly strong on B2B/private APIs, which are less visible than public APIs but provide significant benefits for organizations in industry sectors such as manufacturing, insurance and energy.
Software AG's product set addresses all stages of API life cycle management, including requirements planning — which is often overlooked by competing offerings.
Customers often view the mature CentraSite product, with its heavyweight governance model, as too heavy to support agile API programs. Also, overlap between Mediator and Enterprise Gateway creates deployment complexity. Software AG is working to address these issues.
Software AG was late in developing a cloud strategy — as a consequence, most customers are still deployed on-premises.
Due to its soft-marketing tradition, Software AG is rarely considered for stand-alone API management; however, it is frequently involved in API management deals, thanks to existing relationships with its larger HIP solution.
TIBCO Software is a well-established middleware, integration, visual/stream analytics and SOA application infrastructure vendor. At the end of 2014, TIBCO was acquired by Vista Equity Partners; and in August 2015, TIBCO acquired the Mashery unit from Intel. Historically, Mashery had always been at the forefront of API management, mainly with its cloud-centric offering. In the past year, Mashery has been evolving its offering and integrating it with the vast TIBCO product universe.
TIBCO Mashery Enterprise delivers full life cycle API management capabilities; it integrates with the rest of the TIBCO product line. TIBCO continues to sell the original Mashery product, now branded as TIBCO Mashery. TIBCO also continues to sell its original, pre-Mashery acquisition API management offering, under the name TIBCO Mashery API Exchange Gateway, which is now marketed for advanced security and integration projects. With the exception of the Mashery API Exchange gateway (on-premises only), all the products are available in the cloud. The Mashery Local gateway is a hybrid solution that runs on-premises with its administration in the cloud.
TIBCO markets both its offerings worldwide.
As indicated by the maturity and API traffic levels of its customers, Mashery has a solid understanding of the API economy and how to extract value from the business trends related to it.
TIBCO is an established international middleware suite and analytics vendor, with many cross-selling opportunities between several product lines. This has historically been the way that first its SOA governance technology and then its API management were sold.
Solid R&D and support groups have been behind the offerings in this market, and TIBCO has been effectively operating internationally for years. The Mashery acquisition confirms that Vista sees API management as a strategic offering.
Mashery staff have been through two acquisitions in two years. While both acquisitions were aimed at leveraging Mashery's product line, they undoubtedly brought disruption to Mashery's execution. TIBCO has also been through several management changes.
TIBCO primarily targets global enterprises with revenue of $500 million or more. While most of them are getting their digital strategies off the ground, selling to the business roles that drive those strategies is not something TIBCO is used to — having historically focused on technology excellence.
To expand the sales of its solutions, address the concerns of prospects about Mashery's future, and especially to target digital strategies, TIBCO will have to make its API-specific marketing strategy more consistent, louder and more dynamic — domestically and, especially, abroad.
Torry Harris Business Solutions (THBS) was founded in 1998 in New Jersey, U.S. The company focuses on providing high-end and technical skills, predominantly in SOA, APIs and integration, cloud, mobile, big data, and open-source services. THBS provides software services to enterprise clients across different industry verticals through a combination of offshore and on-site services.
Its offering, API-o-Blocks, is a framework of products, processes and services that spans four stages: Strategize (includes Planning), API Govern, API Connect and API Enable. The products are mostly open-source and THBS sells optional consulting projects around them.
THBS mainly markets its products in Europe, the Middle East and Africa, India and Latin America.
THBS has a lot of experience in SOA governance and middleware. It has kept pace with the evolution of SOA governance through API management, addressed the business issues related to that evolution, and consistently improved its vision of this market.
THBS has a few large and very loyal customers, mainly in the telco, financial services and energy markets. It addresses different business verticals with individualized starter packs across the technology and business areas it covers.
THBS clearly understands the market for APIs, including the execution of digital strategies and regulatory drivers such as open APIs for U.K. banks. In particular, it performs effective customer journey mapping as part of building out its Business Model Repository.
THBS is different from the other vendors in this Magic Quadrant, because it is a consulting company and has a mostly open-source application services governance product line. Apart from CI&T (Sensedia) all the other vendors featured are providers of technology and/or managed services in the cloud.
THBS's product enhancements and lines of innovation are almost entirely dictated by the markets and clients it serves. As a result, its execution during the past 18 months has not kept pace with that of the Leaders.
THBS is not very visible in the market. Its offerings are barely marketed and are mainly sold through word of mouth. This is the main reason why its execution has been lagging behind that of other vendors in this Magic Quadrant.
WSO2 provides an open-source integration solution that includes identity management and security, API management and analytics. WSO2's API management offering is WSO2 API Manager. It is available on-premises, in a managed cloud solution or as SaaS. Currently, most of its clients use WSO2 on-premises, with free downloads and paid maintenance.
All of WSO2's products share the same underlying established Carbon framework. This means that its API Gateway shares capabilities with the WSO2 ESB, including protocol support — HTTP, Java Message Service (JMS), MQTT, Advanced Message Queuing Protocol (AMQP), WebSockets, and so on. Policies are provided, including security, caching and rate-limiting (which can be distributed across gateways). WSO2 also provides an API developer portal that includes client software development kit generation. A separate product, WSO2 Identity Server, provides support for SSO and Identity Federation.
WSO2 products are available worldwide.
WSO2's open-source model is a competitive advantage — the products can be downloaded and deployed without any requirement to speak to a sales person. However, Red Hat's acquisition of 3scale, and its plan to open source the whole 3scale solution, might displace WSO2's advantage.
WSO2 provides both integration and API management, so customers do not have to deploy different solutions for each purpose.
In the past year, WSO2 has introduced innovative functionality to its platform, such as the new WSO2 Microservices Framework for Java, IoT Server (a solution for IoT application development) and IoT analytics.
As a technology-focused company, WSO2 provides little help for customers in terms of API strategy planning or preparing for the business outcomes of their APIs. With the increasing importance of digital strategies in the short term, this is bound to reduce WSO2's addressable market.
With an extensive integration offering and a significant number of moving parts and customization points, WSO2 tends to appeal to more technically minded customers — which limits its addressable market.
WSO2 has limited marketing reach and awareness in the API market, resulting in it frequently being overlooked as a strategic partner by prospects.
We review and adjust our inclusion criteria for Magic Quadrants as markets change. As a result of these adjustments, the mix of vendors in any Magic Quadrant may change over time. A vendor's appearance in a Magic Quadrant one year and not the next does not necessarily indicate that we have changed our opinion of that vendor. It may be a reflection of a change in the market and, therefore, changed evaluation criteria, or of a change of focus by that vendor.
Red Hat (3scale)
No vendor has been dropped from the Magic Quadrant this year; however, 3scale and Mashery now appear with the names of their acquiring companies — as Red Hat (3scale) and TIBCO Software (Mashery).
For a vendor to be considered for inclusion in the 2016 Magic Quadrant for full life cycle API management it must:
Market any subset of full life cycle API management, as defined in the Product/Service section (under Ability to Execute), both in the cloud and on-premises, or in the cloud only. Cloud offerings could be part of SaaS, iPaaS/PaaS or an HIP. On-premises offerings can be part of integration infrastructure or SOA governance technology.
Have been marketing offerings (general availability or beta) as of January 2016. Vendors offering on-premises-only solutions as of January 2016 do not qualify for the Magic Quadrant. Planned offerings must have been publicly announced by March 2016 to be considered for inclusion in this Magic Quadrant.
Have a comprehensive, general purpose (that is, not specific to an industry vertical) offering for full life cycle API management that covers at least two API life cycle stages (those being planning, design, implementation, deploy, run, versioning and retirement), either with a direct offering or through partner agreements. Vendors not offering a developers' portal — either with a direct offering or through partner agreements — are excluded from this Magic Quadrant.
Generate revenue of at least $10 million (or its equivalent in another currency) per year from full life cycle API management. Vendors pursuing a subscription-based, open-source business model should have revenue of at least $2 million (or its equivalent in another currency) a year for full life cycle API management. These figures include revenue from software, SaaS, iPaaS, PaaS, cloud managed services, support and professional/consulting services related to the full life cycle API management offering marketed. The figure for open source is lower to reflect a different business model (based on cloud subscriptions and/or support fees, instead of license fees).
Originally, the notion of basic API management did not include API design: it was taken for granted or assumed that an API existed already, or was easy to implement, before API management would kick in, and publish it. Over the years, clients realized that such an assumption was not always true and began looking for API design capabilities in addition to what they normally found in integration platforms. Two API design-centric companies have therefore been added to the Magic Quadrant: Apiary and digitalML.
Also, the demand for fully open-source API management solutions grew consistently during the past year, largely driven by companies who, at least initially, are looking for a simple, low-cost API management solution that they can enrich themselves in time. Even for large IT departments, this course of action typically does not bring viable solutions in the medium term (when API programs work, API management functionality is needed far more quickly than any IT department can deliver). For these reasons, two open-source API management providers have qualified for inclusion in the Magic Quadrant: Mashape and Red Hat (3scale).
Brazil-based Sensedia was never a stranger to this space, having a long history in SOA governance technology. Having been acquired by a larger system integrator (CI&T), Sensedia has strengthened its operations and has therefore been added to the Magic Quadrant. Likewise, Oracle (also no stranger to this space), in getting its newly developed API management capabilities off the ground has also qualified for inclusion in the Magic Quadrant.
The following providers were considered for this research but did not meet all the criteria for inclusion in the Magic Quadrant; they may, however, be worthy of consideration:
Based on Gartner estimates these vendors did not meet the minimum revenue criterion:
Huawei markets an API management solution; however, that solution is targeted only at communications service providers, and as such does not match the general-purpose entry criterion.
Informatica was considered, but does not offer a developers' portal, which is a minimum criterion for entry.
SmartBear was considered, but its offerings mainly cluster around API design (after the Swagger acquisition) and testing, both part of a single life cycle stage (design and implementation).
The following considerations for each criterion apply specifically to full life cycle management and are provided here for the sake of clarity and understanding. For additional information about the more general criteria please refer to Evaluation Criteria Definitions found in the final section of this document.
For full life cycle API management, we consider the providers' capabilities in five different categories, which correspond to stages in an API's life cycle:
Design and implementation
Deploy and run (basic)
Deploy and run (advanced)
Versioning and retirement
This subcriterion rates the ability of providers to help their clients in planning the right APIs for their business purposes, frequently to enable the execution of digital strategies.
A common mistake of SOA projects was to build services based on the generic requirements of future applications — it is very clear today that the "if you build it, they will come" approach for APIs will not work. APIs should be designed to meet the concrete needs of real API consumers, and to be used immediately. However, anticipating the needs of digital business applications, or meeting them as quickly as possible, is a daunting effort. Frequently, full life cycle API management providers offer workshops geared at business/innovation managers or application managers (and anything between the two), to help them determine how to engage the API economy, which APIs to publish, and how to come up with must-have APIs that API consumers need today to meet their specific business requirements. Workshops and consulting services can extend to techniques for API modeling to facilitate implementation; this effort may be iterative in nature.
Major factors in the selection of an API management platform today are the thought leadership of a vendor, and the value a platform is known to have delivered in current and mature projects for other companies. For this reason, some providers employ API "evangelists," who very publicly display their knowledge in this area: facilitating webinars, holding conference sessions, helping with planning hackathons and holding client workshops for API planning. API evangelists also play a fundamental role in clarifying the rules of the API economy (and how a company can be a part of the API economy), which has a major influence in the decision making of established companies around the opportunities of an API program.
Other factors involved in planning APIs are external ones such as government regulators. For example, the Second Payment Services Directive (PSD2) regulations in the European Union are driving banks to plan APIs in order to satisfy these regulations. API management providers with vertical domain expertise can help organizations with planning APIs for this class of requirements.
A fundamental part of API planning is the upfront assessment of the business model for the API. Is it to attract new customers, to add value to existing customers (perhaps to stave off competition), or to facilitate partnerships? API management vendors with API strategy experts can benefit customers by establishing a clear business model for the API; thereby removing later confusion.
APIs don't just appear; they are often designed to meet the requirements of one or more specific digital business applications or mobile apps and should account for different consumers and personas. One of the most common questions asked by Gartner clients in API inquiries today is: "How do I know which APIs to publish?" The answer clearly rests with the needs of the API consumer. Once it becomes clear which data and functionality an API should give access to, the API obviously needs to be fully designed and implemented as soon as possible (beyond the initial stubs that some toolkits offer), generally using a mix of the following approaches:
Creating a "quick and dirty" API stub (so the applications using the API don't have to wait for the final API to be available), often using simulated data, to then be followed by the real implementation (as outlined in the following bullet points)
Using widely available API design tools for simple create, read, update, delete (CRUD) operations over an existing system (such as a database or ERP system)
Reworking pre-existing internal APIs or interfaces exposed by an iPaaS or other (possibly hybrid) integration platform, or by a pre-existing ESB
Using an integrated development environment (IDE) as a studio to design and create APIs — in an "API first" approach — which can be later mapped to other systems
Using IoT API toolkits, which offer quick API creation to access data and manage "things"
Composing existing lower-granularity SOA services or microservices, frequently adding business logic on top
Embedding or combining external APIs (public or partner)
Programming new implementation code from scratch
Providers often package into their full life cycle API management offerings the functionality to ease identity management or speed the implementation of APIs serving mobile applications, extending to portions of what is sometimes called mobile back end as a service (MBaaS), which will be evaluated as part of this subcriterion. Because of the surge of digital business applications, this subcriterion has increased in importance, especially now that devices in the IoT are starting to leverage APIs (and vice versa).
In the implementation of an API, an API provider typically wants to enforce specific design policies. There is a wide variety of design policies and, in general, the bigger the API provider is the more design policies apply. Here are some examples of design policies:
Enforcement of standards or protocols that a specific API must comply with before being published
Definition of a specific application domain that a specific development group can implement APIs on (or out of)
Adherence to specific API templates, or patterns or models provided as input from design time
This subcriterion also rates the ease and speed with which the desired API is designed and implemented, typically in conjunction with API design functionality (which could be offered directly by the full life cycle API management vendor, or could leverage other solutions). As planning APIs is always challenging, and sometimes impossible, quick API design becomes of fundamental importance.
This subcriterion also rates generic functionality for API testing.
This subcriterion rates providers' capabilities in basic API management, which is mainly about packaging, operation, runtime and maintenance of APIs, and is generally divided in two functional areas:
Policies around operational management, security, format translation and the collection of metrics associated with the usage of the API. A policy defines, implements, monitors, enforces and manages desired behaviors and exceptions around the usage of a specific API. Examples of operational policies in basic API management include caching, throttling, load balancing, capacity planning, integrity, confidentiality, authentication and authorization (OAuth and more), threat prevention and protection, data transformation (depending on the consumer), data and functionality visibility, quality of service, and many more.
Discovery, developer access provisioning, testing and collaboration (in the so-called "developers' portal"). Developers' portals also include general reference documentation (such as code samples, sandboxes, client libraries, software development kits, test kits, references to hackathons, and API/app contests). Ease of use — for the developers who will realize apps that consume the APIs — is of fundamental importance.
This subcriterion rates providers' capabilities that go well beyond basic API management. Some of the following capabilities can be options for the mature offerings of API management providers:
Active promotion of API usage, testing and collaboration, frequently through support in setting up hackathons and API/app contests that are targeting, through social platforms, all the developer communities that might be interested in the API, and providing a social platform for developers to collaborate and share ideas around the usage of an API. This is a major enabler for companies who want to benefit from the API economy.
Advanced analytics to support the assessment of the business value of a specific API. Another frequent question from Gartner clients in API inquiries is, "How do I know if the API is of value?" Generally, the value is in the eyes of the API consumer and in the business benefits the API enables, either directly or indirectly. The benefits and value an API returns can be measured in many ways, because in the API economy APIs generally have several types of value associated with them that can change rapidly over time. The granularity and bands of usage plans may also change over time, based on API consumer behavior. Billing and a wide spectrum of API monetization policies are also related to the analytics on the APIs, and are currently of fundamental importance.
Being (at least part of) a platform for develop and run digital business applications (see "Which New and Old Applications Will Enable Digital Business?" ) and enabling the execution of digital strategies.
Ease of connection and integration with devices in the IoT, either through an IoT toolkit (which could be offered by a partner) or the support of specific IoT protocols (such as MQTT). Functionality to manage the load and analyses stream of events (typically generated by things) is of increasing importance.
Reverse gateway functionality: APIs frequently call out to other web APIs that are offered by different companies, or an organization may make use of external APIs — a reverse gateway would allow API providers to monitor the usage of and dependencies on external APIs.
Advanced security features, aimed at preventing malicious attacks to an API platform and providing protection against fraud such as competitive data mining, form spam or sustained bot activity.
Availability of professional and consulting services for the effective execution of full life cycle API management projects, and the provision of related tactical and strategic advice, is a key factor for success in this market (as already pointed out under Planning) — in this life cycle stage the services clients' needs are quite different, because they have APIs already, and relate to the capabilities of the previous bullet points.
Mature API management programs already have to deal with several versions of the same API. This issue is becoming more important as companies realize how impractical it is to keep too many versions of the same API in production at the same time.
Applications and apps using the APIs change frequently, and in digital business they will come and go very dynamically (see "Which New and Old Applications Will Enable Digital Business?" ). As APIs are typically consumed in several different scenarios, some of them will evolve to demand a new version, some of them won't be used anymore and a few of them will demand no change at all. Creating new versions of the APIs while supporting the old ones will become increasingly unsustainable, and should always be thoroughly thought through. Avoiding versioning in the first place would prevent a lot of downstream problems (see "Choosing the Right Web API Versioning Model" ). If API providers allow versioning to get out of control, the only choice is to retire old versions of the APIs — by pushing applications and apps off them into new versions, which in many scenarios is very difficult and will require a variety of hard and soft approaches (see below). It is crucial to support API providers and consumers through this conundrum, and this subcriterion will assess how wide and effective this support is.
Also, companies frequently realize that the APIs they published in the past really don't hit their current business goals, so they retire them. If the soon-to-be-retired API does not have many consumers, the decision to retire it will have manageable consequences downstream. Sometimes, however, the API is retired because it does not produce value for the provider — but it does so for the consuming applications and its users, who can be many. This situation is obviously difficult to manage: technology will help — for example, by knowing from the developers' portal which and how many developers have actually realized an app consuming the API (and giving them notice that the API will be retired/deprecated in X months) — and the gateway can give an idea of the effective usage of the app by looking at the usage of the API. Managing these cases is largely a complex organizational endeavor, involving a lot of negotiations that only humans can carry out, especially when no alternative and newer API is offered. A modern API management platform can, however, support and facilitate API retirement in many ways, and companies are increasingly hungry for this type of functionality.
Once API programs mature, API providers will incur relatively high costs to switch their full life cycle API management vendors, and the degree of change that occurs in API consumers' requirements (and the potential impact the changes can have) can be significant. For these reasons, we consider a vendor's relative size (customers and revenue), financial stability and management commitment to this market. Because of the breadth of full life cycle API management functionality, some vendors partner with other providers to complete their offerings. Some other vendors partner for multiplying sales opportunities. These partnerships and their perceived effectiveness are valuable when evaluating a particular vendor's viability. We also consider the size and quality of the vendor's active user community relative to its target market, and the availability of professional and consulting services.
We track revenue growth, including the number of clients the vendor has, the number and business impact of the projects implemented, and how and whether professional and consulting services have eased implementations. We also evaluate whether pricing models — on-premises and in the cloud — are expressed with clarity and predictability. The vendor's ability to handle large and complex deals comes into play here, too.
The dynamic nature of API programs, the furious pace of change that the execution of digital business strategies will increasingly demand, and how quickly a vendor responds, adapts and takes advantage of them, are key factors. We also look for evidence that the provider continues to respond effectively to the rapidly evolving full life cycle API management market conditions (for example, integrating full life cycle API management within an HIP, addressing new IoT requirements or being a platform for digital business).
We also assess the degree to which the full life cycle API management vendor has captured mind share, thought leadership and gained a solid reputation in this evolving and growing market, and how often the vendor is included in shortlists for full life cycle API management projects. Effectiveness in marketing and partnership programs is evaluated, too.
We track the specificity and quality of support (domestic and international), and of contracts and SLAs, for the availability of full life cycle API management functionality in the cloud. API management issues are the same worldwide, but the types of policies that organizations choose to address first (or deal with the consequences of, once a policy is breached) changes considerably in different cultures, geographies and projects. Specific attention is given to the customer experience outside the home market of the full life cycle API management vendor.
This is another area in which the availability of professional and consulting services for the effective deployment of full life cycle API management, and the provision of related tactical or strategic advice, are critical success factors. We are interested in the full life cycle API management vendor's security and privacy certifications; the scope (for example, people and data centers) and reliability of its hosted governance service platforms (for cloud offerings); and the scalability and adaptability of the software platforms offered (for on-premises), including metrics for efficiency, speed of change, or implementation of new features and scale.
Product or Service
Source: Gartner (October 2016)
The following considerations for each criterion apply specifically to full life cycle API management, and are provided here for the sake of clarity and better understanding. For information about the more general criteria please refer to the Evaluation Criteria Definitions found in the final section of this document.
Ultimately, end-user clients need to run API programs effectively (as part of their digital strategies), engage in the API economy, and manage the API security issues that will arise. Vendors are evaluated according to the degree to which they show an understanding of these market needs and anticipate new ones. We also assess how effectively a vendor partners with other technology and service providers (for example, mobile back-end services providers) to enhance its full life cycle API management platform, and how well it understands the on-premises and cloud (private and public) requirements for small, midsize and large projects in the various vertical industries and in different geographies. In short, we assess how much a vendor understands the full life cycle API management market and how powerfully its vision will drive the market forward.
We look for evidence that the vendor clearly articulates its value propositions (for example, being a digital platform), and how its offering (associated with its partners' offerings, if any) drives new business value for its clients, for example in the API economy. In this evolving market, it is essential for a full life cycle API management vendor to understand/monitor its competitors and to leverage an effective marketing channel to reach its target audience (segmentation of the target market/buying centers is fundamental).
We specifically look for evidence that the vendor is leveraging the right balance of direct and indirect sales vehicles, and is targeting the right mix of small or midsize businesses and large prospects appropriate for its target markets in the target geographies and industry verticals. We look for clarity in the identification of the target market (that is, innovation centers, or companies in a specific vertical with time-critical API management efforts) and evidence of a real business plan and an effective strategy that go after the market using presales, professional and consulting services (with the related templates, blueprints and best practices), where appropriate.
We ask specifically for vendors' offering plans and roadmaps, and assess how complete the full life cycle API management offering is likely to be in the years to come. We also look into the offering's overall architecture (whether technology or managed services), how future-proof it is and how easily it can be integrated with the users' current infrastructure, as well as how cloud features (such as elasticity) are or will be implemented, changed or extended. When the vendor uses third-party functionality from partners to extend its offering (for example, to cover other API life cycle stages), we assess how effective and seamless the extension is for the user, how viable the partner is and whether the inclusion of the functionality as part of the vendor's direct offering would make more sense, from a vision perspective.
We look at how the vendor targets or maintains profitability through its pricing models and sales strategy, and how the models work in the cloud, on-premises or for partner sales. Because of the breadth of full life cycle API management, some vendors must partner to complete their offerings. These partnerships, their effectiveness and their viability, from a user perspective, are central to evaluating a particular vendor's business model. We assess the breadth of professional and consulting services, the way the providers recognize revenue and leverage investments in R&D, and their growth strategy (including mergers and acquisitions) across various geographies. We also look at the API monetization opportunities the vendor's platform enables for its clients.
We look at the industries the vendors focus on, the industry-specific solutions (if any) they offer and how these solutions are, or are likely to be, successful or differentiating in the market. The rules by which you run an API program are frequently vertical-industry-specific, even if core API policy requirements do not change much across the industries. We assess vertical-specific blueprints or starter kits, if there are any.
In the full life cycle API management market, innovation is not just "nice to have," it is a condition for survival. Innovation targets the three corners of the API economy (see "The API Economy: Turning Your Business Into a Platform (or Your Platform Into a Business)" ): API providers, developers, and users of the application constructs which consume the APIs. We assess how innovation ideas are effectively filtered and funneled through product development. We also look to the vendor's track record of anticipating or leading new trends in the market.
We look for evidence that the provider is engaging the most fertile locations relative to its capabilities, and whether further opportunities might exist in geographies not explicitly addressed now. Our evaluation assesses the provider's nondomestic project fulfillment capacity, support centers, sales offices, partner networks, and ability to support complex international requirements and features (such as region-specific compliance with local laws and regulations).
Offering (Product) Strategy
Source: Gartner (October 2016)
A Magic Quadrant represents Gartner's judgment of vendors' Ability to Execute and the Completeness of Vision in a market (in this case, the full life cycle API management market). The criteria for Ability to Execute reflect the staying power and record of execution of vendors in the market. The criteria for Completeness of Vision reflect vendors' abilities to understand market trends, to lead and influence them, and to follow these trends with agility and consistency.
Vendors that are strong in their execution and ability to lead and influence the market are Leaders. The most recent players in the market (with a limited record of execution) and well-executing vendors that are overly cautious on innovation and risk are less likely to be Leaders.
A word of caution. By its nature, a process such as this favors comprehensive offerings and powerful sales and marketing strategies. A tightly focused product, even if exceptional, typically will not score as well in this analysis as a comprehensive offering supported by strong sales and marketing strategies. This, in turn, frequently favors the larger vendors, because their extended resources enable them to allocate substantial sales and marketing investments to support their API management products, and to offer the more comprehensive collections of functionality.
The most distinctive attribute Leaders in this market have is that they are able to address the widest variety of API use cases — internal (A2A), B2B, B2C, on-premises and in the cloud — ranging from traditional, next-generation SOA Mode 1 projects, to the most dynamic, agile, digital strategy Mode 2 execution. The rise of the API economy (see "The API Economy: Turning Your Business Into a Platform (or Your Platform Into a Business)" ) and the start of sweeping digital strategies have put API management in everybody's thoughts and brought it to the fore, in front of upper management (see "How to Make APIs a CEO and Board Priority" ). APIs must come from somewhere, and Leaders extended their offerings to API design and implementation. API programs frequently start small, with innovative ideas, and they need to execute fast. The Leaders ensure their offerings make their clients thrive in this dynamic environment.
There are many Leaders in this Magic Quadrant, because there are many ways of becoming a Leader:
Powerfully marketing and enriching an advanced API management platform
Evolving a fully functional, first XML then SOA, then API gateway, with a cloud deployment option
Addressing the HIP head on, with leading functionality in all components
Acquiring Leaders or Visionaries, and integrating them into a wider application infrastructure offering
Leaders understand the market that will bring them and their clients forward. There are currently no fully open-source leaders in this market, but we expect this situation to be temporary.
Challengers execute well today for the portfolio of work for which they have functionality, but have a blurred or incomplete view of market direction. This year, the Challengers are all very close to the center of the quadrant: they are all large providers who have recently improved their vision or their Ability to Execute (or both); they are all candidates for, and sometimes close to, becoming Leaders.
The future of these technology and service providers is directly linked to how aggressive and proactive they are in addressing their current shortcomings. Because they are so close to the center of the Magic Quadrant, and because they have all improved their positions during the past year, it is likely that they may be, or may return to being, Leaders in the future; if not, they might simply move into another quadrant (if not out of the Magic Quadrant altogether). The strong dynamics and the sharp evolution this market has experienced during the past 18 months, together with the injection of pace due to the execution of digital strategies, don't leave any other alternatives.
Visionaries typically approach this market with a fresh view from an innovative angle. While they typically feature an incomplete set of functionalities, they have the power and the mind share to grow that set for potential customers, often in a different way from the established Leaders.
During the past year, the collective vision of the Leaders has improved significantly, generally because of powerful marketing and innovation, and this has shifted the Magic Quadrant decisively to the right. Previous Visionaries struggled to keep up with the pace, or have been acquired by larger entities that gave them the Ability to Execute they lacked because of their size. In this year's Magic Quadrant, the Visionaries are not that "visionary" (they cluster to the left of their quadrant), reflecting the partial and unstructured attention to marketing and innovation that a lot of the entrants exhibit. Both innovation and effective marketing strategies are absolutely fundamental to being viable in this market going forward, and will be essential once digital business strategies start driving strong competitive challenges from the increasingly powerful and viable offerings of the megavendors.
In Gartner Magic Quadrants, Niche Players focus on a particular segment of the market, typically defined by a specific life cycle stage (for example, API design) or by other characteristics such as vertical industry, client size (and spending power), geographic area, advanced functionality required (such as performance or security), or being fully open source.
This connotation does not fully characterize the Niche Players in this Magic Quadrant. The Niche Players here have very different histories, they might be:
Previous Challengers or Visionaries, simply overtaken by the Leaders' Ability to Execute or Completeness of Vision
Small young and growing companies that have a bright future if they keep executing well and expanding their offerings and their client bases
Focused on a niche, such as API design, but still delivering value on the full API life cycle through partners
Megavendors on the rise, reworking their traditional offerings entirely and still (possibly) considering options that would allow them to leapfrog up the Magic Quadrant
In their specific niche, their offerings might be more functional than those of the Leaders; in some cases, it might be just a sign that the vendor is maturing and that its offering is being extended. Niche Players' Ability to Execute is limited to its areas of focus; it is, therefore, partial and is assessed accordingly. The Niche Players' ability to innovate and, to a greater extent, to survive in this market is affected by their narrow focus. Improving their marketing strategies and fostering innovation is, for them, the safest road to becoming Challengers.
API programs and initiatives don't necessarily need the full set of functionality from the start, but their new functional requirements, such as security and identity management, emerge very rapidly (and will need to be addressed very quickly). We therefore recommend that organizations that run API programs consider offerings that have the potential to address their needs well beyond the first project or two. Using more functionality of the current API management platform will be much easier, quicker and less expensive than extending it or even replacing it. Replacing an API management platform involves rehosting all the policies (some of which might not be standard in all platforms) and republishing the APIs in a different developers' portal. API management is generally uncomplicated in the first few months of usage, but it gets more complex as the API program matures and the policies become more sophisticated.
It is generally preferable to choose an overall API management solution from a single vendor that provides full life cycle API management. API management has evolved from being focused only on running APIs to taking a broader view of the API, its design and its usage across the full API life cycle.
An API management platform should not limit its users to only one way to consume APIs, such as via mobile apps. Full life cycle API management solutions have evolved to include support for IoT scenarios and protocols, as well as for B2B APIs (frequently used for new B2B interactions, instead of established protocols such as EDI) and APIs consumed by rich web applications.
Depending on your company priorities and digital strategies, the developers embedding the APIs you publish could be inside or outside IT, or even outside your company. Therefore, to properly get value out of the API economy you need a developers' portal now or in the near future — even if you publish your APIs in a public API marketplace. In the API economy, the developers' experience is as important as the user experience.
Innovation is out there; in order to get fresh ideas, you need to publish the right APIs and aim to create new business value. Several companies run hackathons to uncover fresh opportunities (see "Hackathon Handbook for Banking CIOs" ) — which generally involve APIs from diverse sources in different verticals — and test if those ideas might have business legs.
One of the most far-ranging and fascinating rules of the API economy is that once the API is out, developers will use it for things you never imagined: This is both a blessing (because it will bring in fresh innovation) and a curse (because you must protect yourself from malicious usages of the APIs).
Frequently, clients don't know where to start to gain benefits from the API economy. Focus first on the value of the application constructs that might be built on top of the APIs. Try to understand which ones will be advantageous to your company and will advance your digital strategy. Listen to user constituencies that have a budget for innovative application constructs — you could start with the ones that you can enable with a few APIs.
Running an API program generally requires a bimodal IT organization (see "Bimodal for Applications Hinges on APIs" ). Use a Mode 2 approach for one or more of your projects, because this is what executing a digital strategy will be like for your applications.
A market is a set of end users looking for solutions to the same problem, and providers addressing it with products and services. It is our view that all the functionality introduced in the Product/Service section is what companies will need for their API programs in the next few years.
The market did not change fundamentally from the previous version of this Magic Quadrant; however, some new trends are worth noting:
The need for API design has become sharper. In the early days of API management, it was generally taken for granted that an API was either there already, or would need little effort to be implemented. This assumption was generally true then, but not anymore: with digital strategies starting to take off, APIs are (in general) much more complicated to implement.
API programs are maturing, and the API economy is growing rapidly (see "The API Economy: Turning Your Business Into a Platform (or Your Platform Into a Business)" ), so the need for advanced API management functionality has become more pressing, especially for analytics, API monetization, real/business value of APIs, ease of implementation of digital business imperatives, IoT and advanced security (to prevent/defend from malicious attacks to the APIs).
APIs provide the internal workings of the technology platform for digital business (see "Building a Digital Business Technology Platform" ), and this notion is becoming more widespread by the day.
New, viable open-source offerings have become more popular at the early stages of API programs.
Projects have remained small (focused on very few APIs at a time), but more business-oriented, in need of very quick execution and generally needing deeper and more sophisticated interactions with systems of record (see "Use the Demand for New Applications to Drive Application Rationalization" ). Buying centers continue to shift rapidly from IT departments to business units. Vendors who adapt to a plethora of different usage scenarios and help clients deliver projects faster will do well.
Acquisitions in this space will continue to be commonplace, because full life cycle demands API design (for example, Axway acquiring Appcelerator, or IBM acquiring StrongLoop), and larger players want to buy an initial share in a rapidly growing market, needing API management as part of their larger PaaS offerings (for example, Red Hat acquiring 3scale). Google's recent announced acquisition of Apigee, which still has to close as this research gets published, is another proof of this trend.
As recently published in "Market Share: All Software Markets, Worldwide, 2015," the full life cycle API management market (still under the name of "application services governance" in the report) was worth around $546 million in 2013: it was the time when SOA governance technologies and API management largely became a single market. The market was worth around $647 million in 2014, and $726 in 2015, still in double-digit growth (12.4%). Most of the growth today is in cloud solutions, which has a delayed revenue recognition model, so we expect the overall market growth to slow down — possibly into single digits, but not before 2017. However, the rise of pressing API program requirements in financial services (spurred by PSD2 in the EU), and the data privacy regulations the banks have to comply with in most countries, will result in a continuing and strong demand for fully on-premises solutions that might extend the double-digit growth for longer.
Today, full life cycle API management is generally sold on its own. Increasingly, however, it is coupled with iPaaS — to form an HIP — to meet the needs of more complex API design (as described above). This trend will become more established in the short term. Very little API management is currently sold as part of a more comprehensive PaaS platform, and the exclusion of large PaaS players (such as Microsoft) or IaaS players (such as Amazon) from this Magic Quadrant further proves the point; however, we expect this to change in the medium term.
|API||application programming interface|
|ESB||enterprise service bus|
|HIP||hybrid integration platform|
|IoT||Internet of Things|
|iPaaS||integrated platform as a service|
|MDM||master data management|
|MQTT||Message Queuing Telemetry Transport|
|PaaS||platform as a service|
Product/Service: Core goods and services offered by the vendor for the defined market. This includes current product/service capabilities, quality, feature sets, skills and so on, whether offered natively or through OEM agreements/partnerships as defined in the market definition and detailed in the subcriteria.
Overall Viability: Viability includes an assessment of the overall organization's financial health, the financial and practical success of the business unit, and the likelihood that the individual business unit will continue investing in the product, will continue offering the product and will advance the state of the art within the organization's portfolio of products.
Sales Execution/Pricing: The vendor's capabilities in all presales activities and the structure that supports them. This includes deal management, pricing and negotiation, presales support, and the overall effectiveness of the sales channel.
Market Responsiveness/Record: Ability to respond, change direction, be flexible and achieve competitive success as opportunities develop, competitors act, customer needs evolve and market dynamics change. This criterion also considers the vendor's history of responsiveness.
Marketing Execution: The clarity, quality, creativity and efficacy of programs designed to deliver the organization's message to influence the market, promote the brand and business, increase awareness of the products, and establish a positive identification with the product/brand and organization in the minds of buyers. This "mind share" can be driven by a combination of publicity, promotional initiatives, thought leadership, word of mouth and sales activities.
Customer Experience: Relationships, products and services/programs that enable clients to be successful with the products evaluated. Specifically, this includes the ways customers receive technical support or account support. This can also include ancillary tools, customer support programs (and the quality thereof), availability of user groups, service-level agreements and so on.
Operations: The ability of the organization to meet its goals and commitments. Factors include the quality of the organizational structure, including skills, experiences, programs, systems and other vehicles that enable the organization to operate effectively and efficiently on an ongoing basis.
Market Understanding: Ability of the vendor to understand buyers' wants and needs and to translate those into products and services. Vendors that show the highest degree of vision listen to and understand buyers' wants and needs, and can shape or enhance those with their added vision.
Marketing Strategy: A clear, differentiated set of messages consistently communicated throughout the organization and externalized through the website, advertising, customer programs and positioning statements.
Sales Strategy: The strategy for selling products that uses the appropriate network of direct and indirect sales, marketing, service, and communication affiliates that extend the scope and depth of market reach, skills, expertise, technologies, services and the customer base.
Offering (Product) Strategy: The vendor's approach to product development and delivery that emphasizes differentiation, functionality, methodology and feature sets as they map to current and future requirements.
Business Model: The soundness and logic of the vendor's underlying business proposition.
Vertical/Industry Strategy: The vendor's strategy to direct resources, skills and offerings to meet the specific needs of individual market segments, including vertical markets.
Innovation: Direct, related, complementary and synergistic layouts of resources, expertise or capital for investment, consolidation, defensive or pre-emptive purposes.
Geographic Strategy: The vendor's strategy to direct resources, skills and offerings to meet the specific needs of geographies outside the "home" or native geography, either directly or through partners, channels and subsidiaries as appropriate for that geography and market.