How to keep things on track when building API portfolios
As important as APIs have become, many still fail to achieve API success by not setting goals properly. Tom Nolle explains why this matters and how to manage an API portfolio.
In a development environment that's moving from services to microservices and from data center to hybrid clouds, it's clear that applications will be built from reusable and Agile components and hosted on virtual resources. In short, they'll be built by building API portfolios, which makes managing your inventory of APIs critical to development efficiency and compliance. It's important to prioritize your drivers for API management; keep development, application lifecycle management and compliance goals separate; and integrate your implementation to ensure all your API viewpoints converge.
Over half of enterprises report at least a portion of their application services, whether developed in-house or acquired, are uncontrolled. Nearly all say that even where API controls have been put into place, they aren't supporting at least some of their IT goals. In fact, it's clear that enterprises' problems with API management lie in failing to set their goals properly. APIs face three different organizational directions -- development, application operations and ALM, and internal audit and compliance. All these goals have to be made explicit and supported.
Who's responsible?
Development builds APIs and, in most cases, will also be the part of the organization that acquires third-party services represented by APIs. It's convenient if the development organization has the exclusive right to build the company's API portfolio, and the first requirement for the portfolio is that it provides the API's characteristics -- for instance, calling sequence, parameters, dependencies on other services and databases, stateful and stateless behavior, and execution requirements.
One error many companies make in API management is allowing operations to incorporate cloud APIs into the portfolio directly. APIs are development resources, and they should always be presumed to influence application design, even for subsequent development. It's critical that every third-party API, including cloud APIs, be introduced by developers who understand that process and can properly define the API's characteristics.
Data center operations should be responsible for the application lifecycle management implications of every application and by extension the APIs that make it up. This group should sign off on APIs put into inventory by development and approve the services for production use. If multiple versions of an API are created by software evolution, it's the operations team that must separate the versions and control when they can be used.
APIs are development resources and they should always be presumed to influence application design.
Compliance and internal auditing have a responsibility in both the commissioning of new APIs and in lifecycle management, so they must be able to work with both development and operations personnel in building API portfolios. One important capability that this group must exercise is the ability to pull an API or service from a production state in the case of a security problem. This flagging process should be integrated with both development and ALM processes to ensure that anyone using a suspect API is made aware of the status.
These three drivers for API management are likely found in any large business, but in most cases, one will dominate. If you have a lot of self-developed software, then look for API management tools and concepts that favor developers. For most companies, operations-driven API management strategies will work well even when there are large numbers of third-party APIs introduced. Heavily regulated businesses may need to focus on internal audit and compliance capabilities.
The tools for building API portfolios
The challenge in making all this work is the state of the tools. API management today has evolved from service-bus usage; vendors like Tibco (Mashery) and MuleSoft (Anypoint) will accommodate these three goal sets and work with SOA and RESTful APIs, but their evolution from the developer side means that many operations and internal audit groups find them difficult to use. For companies who aren't planning to use service busses at all, they can be overkill.
Operations and even internal audit personnel like cloud-based API management, such as that offered by vendors like Microsoft, Oracle, Hewlett Packard Enterprise and IBM, where ALM integration is a feature of the package and the service-bus bias is less visible. Apigee is popular with governance-driven users and suitable for broad API management tasks, particularly those that cross over between different architectures (Java, .NET).
Even development organizations who are not fully committed to a service bus may find these IT vendor tools friendlier. Tools designed for the current microservice-and-cloud environment, like WSO2's API manager, are well-suited for multirole portfolio management, particularly if the rest of their broad application and middleware portfolio is considered.
Speaking of the cloud, Amazon is now entering the space with its API Gateway, but this tool is less comprehensive than the rest and is valuable primarily to augment other API management tools for the cloud portion of an application. Amazon's deployment offerings complement the API gateway, but the product set is best suited for public cloud users because of the use-licensing model in place.
The fact that different organizational constituencies like different tools can lead to an unfavorable and often accidental loss of focus and consistency in management. Wherever possible, the best approach to building API portfolios is to use only one product or tool set and offer each organization a different view or role. This is easier to do if you minimize the number of tools by ensuring that all the tools you select will work across the deployment options you propose and support the models of application evolution your company can expect.
That same approach is needed throughout the API-building process. A good strategy has to support where you are, where you're going and how you get there -- and do so while providing the features needed for the three critical API management roles. Plan API management in terms of API evolution, and you'll obtain a better result with less effort and risk.
