What is an API Product?
What is an API Product?
This is a concept I have been trying to define in full for a bit now, and haven't found any great write ups on. With that in mind, as always this is a learning and discovery blog, and that's the aim here. I encourage discussion on the topic, and for you to consider this a working definition, share your thoughts and opinions, and hopefully find what I have collected here somewhat useful.
To those of you that have read my blogs, attended my webinars, or seen any of my presentations, you know I like to relate things to analogies. So to answer this question, let's start with a scenario...
Say you are man shopping for a few dress shirts for work (feel free to swap pronouns and clothing articles as desired). You hop onto the home page of your favorite generic shopping site and start to look for what you need. What is the first thing you click on to start to narrow your search? Often you will see several departments (eg. beauty, kids, jewelry, watches) to narrow your selection, which in this scenario will likely result in you choosing 'Men[s Clothing]'. Once this has been selected you may see any number of subcategories such as clothing, shoes, accessories, etc. From here you click on clothing --> dress shirts and start to narrow down your selection (color, size, price). Let's keep this scenario in mind as we move forward and investigate how an API Product is defined and what value they bring to an organization.
As a basic working definition, an API Product is a logical grouping of APIs to be used by a group of developers. From a more technical point of view, an API Product is a bundle of resources, potentially from multiple API sources, with a defined security protocol (eg authentication mechanisms, usage constraints) for access. These should work as a baseline to discuss the topic of API Products, that we can hopefully build upon as we go along.
Products vs Services
Is an API a product or a service? What does it mean to treat an API as a Product? Often when trying to answer such questions at this, my first stop is Google with some "define: x" syntax to get a base level definition set to then determine better how it applies to the topic at hand. Some basic GoogleFu turned up the following:
Product: "An article or substance that is manufactured or refined for sale".
Service: "The action of helping or doing work for someone".
Looking over these two definitions, I lean to product (and hopefully you do as well). When I think about API consumption models, I think discovery of complete and refined artifacts via an API Registry or API Developer Portal, and their consumption. Obviously there is the initial development of APIs, but ultimately aimed at the goal of reuse and consumption of a finished product. I think a large part of the confusion comes from the consumption of APIs via the SaaS approach, or software as a service. The name can be a bit misleading. When we look at "as a service" models, they are being run and hosted as a service, but for subscription based consumption of software that has already been created. Customization and one offs are not the model we generally see used, which would be more of a service model approach. If we revisit the above shopping scenario, what we are doing is using a service on the web to locate products based on different groupings. Ultimately what is purchase is a product, something prebuilt and consumable.
So with this in mind, we should think about managing our APIs as a Product, but what goes into that and how do we get from API consumption to API Products?
APIs as a Product
Hopefully at this juncture you are with me and we can define APIs as Products, but whats next? We see APIs being used in many ways to address different communities of interest. They may be created for:
Whatever the case there are some major concepts that apply across the board. Your APIs should be compelling. Be it to drive customer consumption for profit or simply to encourage internal adoption of a new process, design, ease of use, quality assurance, and new capabilities should be addressed and maintained over time. So you have different groupings of capabilities that need oversight to ensure a consumer experience, ongoing support, and progressive capabilities? This is where we start to see the idea of API Products start to come about, as well as the adoption of the API Product Manager role. Much as a Product Manager at a software vendor might oversee a set of solutions that make up a deliverable suite, the same concept applies to APIs. The grouping of like capabilities to address a problem set, the consolidation of redundant capabilities, and the overall management of these items in a group all fit the same paradigm. You can imagine as well the grouping of APIs emerging as almost a product line that needs leadership and management to succeed.
So while it may make sense to group these resources together for management and development purposes, why bundle them together in different groups for consumption rather than stopping at simply segmenting the appropriate views into different communities of interest? What is the value of API Products?
Discovery
Some organizations may have a small group of APIs for the independent communities of interest. Sharing them out in isolated silos may be sufficient, but what happens as more and more business operations and capabilities come on board as APIs? While there may be some organizations with tens of APIs, we also see groups using APIM solutions across an entire enterprise, spanning many lines of business, with hundreds or thousands of APIs to manage. As the number of APIs in an organization scales up, it only makes sense to organize them accordingly. If we refer back to our shopping scenario, as a consumer, how would it be to access the website and not have the initial filters into different product lines? Sure, I may be interested in buying new cookware or bath towels as well, but do I really want to see all products lumped together in a single registry? In much the same way, the idea of bundling like APIs into logical Product groupings only makes sense to support discovery and ease of consumption. It's important to note here that in the same way I can access the different product lines on the shopping site, an API Product does not need to be all inclusive for what any community of interest may want. They could perhaps subscribe to multiple API Product groups if there are different ones that apply. What matters is that the API Product contains like resources for their use.
Crossover Reuse
One strong capability APIs bring to the table is reuse, not just within a single community of interest, but also often cross communities. Let's take our shopping example into mind again. Might a salesperson at point of sale register be as interested as a consumer in seeing if a certain article of clothing in a specific size was available at a single location? Maybe we even have external developers that want to see stock and compare prices from our store as well as many others to aggregate information for consumer comparison shopping. Why reinvent the wheel to support these different groups? Aside from simple discovery, API Products make sense for reuse across different groups and lines of business where subsets of functionality from different APIs makes sense to come together to support a new logically grouping of those components into a new superset.
Security Profile
Let's build on the last scenario. We have this stock discovery API that is being used by a point of sale register, by the web site under the covers to provide information to our shopper, and by external developers. Will we manage and authenticate all these people the same? Will we provide the same quality of service to each group? Perhaps we utilize API Keys with external developers so we can track their consumption and charge accordingly. Do we apply the same logic to employees at the point of sale register, or perhaps utilize employee logins for this?
When security is applied at a per API level, the requirement because to either implement complex and brittle policies to handle all scenarios, or to maintain multiple versions of the same API in order to have different security protocols depending on the consumer. API Products also bring value in allowing resources to be grouped in a superset, and security protocols to be applied at the API Product level as opposed to the API level, allowing logic to be executed dynamically based on the consuming group or attributes, rather than via complex and hard to maintain all-user encompassing logic.
API Enterprise Strategies and Best Practices
Another important point to touch on is that these concepts also strongly support other enterprise API strategies. Let's take the product stock API discussed above for example. Would that API only contain the method to return the stores stock numbers as a GET request? Would it also perhaps include other APIs to POST new stock options to the stores registry, UPDATE stock amounts as sales occur, and potentially DELETE stock items as they are no longer offered? When we look at enterprise strategies such as API-first design, often we would see these like operations grouped within a single API in the initial definition. From here, it could be shared to allow development from many groups in tandem, such as the updating the website logic to display the stock, updating the back end servers to manage stock numbers as shipments arrives or items are sold, and allowing for data modeling to connect to the databases where this information is stored. As well as being of value for the other reasons mentioned, API Products gives us the ability to develop our APIs in a fashion that supports enterprise strategy, and then deliver and manage them a logical method to the different communities of interest.
In Conclusion
API Products are a value strategy that is emerging and furthering our use of APIs. Understanding the concept and utilizing it is a powerful strategy to fortify our use and adoption of RESTful API architecture. API Products give us the ability to take an API, apply applicable security protocols, while maintaining a paradigm where the methods can be shared across many groups. APIs should be managed and owned as Products, focusing on creating the best capabilities to support ease of use and consumer experience, which is best supported by rationalizing operations into reusable components, developed by design first strategies (eg. API-first), and owned by a Product Manager.
Curious to learn more about API Products, API Management, or any other topics discussed in this article? Come visit us at https://www.axway.com/en to learn more.
This is a concept I have been trying to define in full for a bit now, and haven't found any great write ups on. With that in mind, as always this is a learning and discovery blog, and that's the aim here. I encourage discussion on the topic, and for you to consider this a working definition, share your thoughts and opinions, and hopefully find what I have collected here somewhat useful.
To those of you that have read my blogs, attended my webinars, or seen any of my presentations, you know I like to relate things to analogies. So to answer this question, let's start with a scenario...
Say you are man shopping for a few dress shirts for work (feel free to swap pronouns and clothing articles as desired). You hop onto the home page of your favorite generic shopping site and start to look for what you need. What is the first thing you click on to start to narrow your search? Often you will see several departments (eg. beauty, kids, jewelry, watches) to narrow your selection, which in this scenario will likely result in you choosing 'Men[s Clothing]'. Once this has been selected you may see any number of subcategories such as clothing, shoes, accessories, etc. From here you click on clothing --> dress shirts and start to narrow down your selection (color, size, price). Let's keep this scenario in mind as we move forward and investigate how an API Product is defined and what value they bring to an organization.
As a basic working definition, an API Product is a logical grouping of APIs to be used by a group of developers. From a more technical point of view, an API Product is a bundle of resources, potentially from multiple API sources, with a defined security protocol (eg authentication mechanisms, usage constraints) for access. These should work as a baseline to discuss the topic of API Products, that we can hopefully build upon as we go along.
Products vs Services
Is an API a product or a service? What does it mean to treat an API as a Product? Often when trying to answer such questions at this, my first stop is Google with some "define: x" syntax to get a base level definition set to then determine better how it applies to the topic at hand. Some basic GoogleFu turned up the following:
Product: "An article or substance that is manufactured or refined for sale".
Service: "The action of helping or doing work for someone".
Looking over these two definitions, I lean to product (and hopefully you do as well). When I think about API consumption models, I think discovery of complete and refined artifacts via an API Registry or API Developer Portal, and their consumption. Obviously there is the initial development of APIs, but ultimately aimed at the goal of reuse and consumption of a finished product. I think a large part of the confusion comes from the consumption of APIs via the SaaS approach, or software as a service. The name can be a bit misleading. When we look at "as a service" models, they are being run and hosted as a service, but for subscription based consumption of software that has already been created. Customization and one offs are not the model we generally see used, which would be more of a service model approach. If we revisit the above shopping scenario, what we are doing is using a service on the web to locate products based on different groupings. Ultimately what is purchase is a product, something prebuilt and consumable.
So with this in mind, we should think about managing our APIs as a Product, but what goes into that and how do we get from API consumption to API Products?
APIs as a Product
Hopefully at this juncture you are with me and we can define APIs as Products, but whats next? We see APIs being used in many ways to address different communities of interest. They may be created for:
- internal systems or developers to consume
- partners or external developers to utilize to drive traffic or return shared data
- resources to be monetized for consumption by a third party
- And so on.
Whatever the case there are some major concepts that apply across the board. Your APIs should be compelling. Be it to drive customer consumption for profit or simply to encourage internal adoption of a new process, design, ease of use, quality assurance, and new capabilities should be addressed and maintained over time. So you have different groupings of capabilities that need oversight to ensure a consumer experience, ongoing support, and progressive capabilities? This is where we start to see the idea of API Products start to come about, as well as the adoption of the API Product Manager role. Much as a Product Manager at a software vendor might oversee a set of solutions that make up a deliverable suite, the same concept applies to APIs. The grouping of like capabilities to address a problem set, the consolidation of redundant capabilities, and the overall management of these items in a group all fit the same paradigm. You can imagine as well the grouping of APIs emerging as almost a product line that needs leadership and management to succeed.
So while it may make sense to group these resources together for management and development purposes, why bundle them together in different groups for consumption rather than stopping at simply segmenting the appropriate views into different communities of interest? What is the value of API Products?
Discovery
Some organizations may have a small group of APIs for the independent communities of interest. Sharing them out in isolated silos may be sufficient, but what happens as more and more business operations and capabilities come on board as APIs? While there may be some organizations with tens of APIs, we also see groups using APIM solutions across an entire enterprise, spanning many lines of business, with hundreds or thousands of APIs to manage. As the number of APIs in an organization scales up, it only makes sense to organize them accordingly. If we refer back to our shopping scenario, as a consumer, how would it be to access the website and not have the initial filters into different product lines? Sure, I may be interested in buying new cookware or bath towels as well, but do I really want to see all products lumped together in a single registry? In much the same way, the idea of bundling like APIs into logical Product groupings only makes sense to support discovery and ease of consumption. It's important to note here that in the same way I can access the different product lines on the shopping site, an API Product does not need to be all inclusive for what any community of interest may want. They could perhaps subscribe to multiple API Product groups if there are different ones that apply. What matters is that the API Product contains like resources for their use.
Crossover Reuse
One strong capability APIs bring to the table is reuse, not just within a single community of interest, but also often cross communities. Let's take our shopping example into mind again. Might a salesperson at point of sale register be as interested as a consumer in seeing if a certain article of clothing in a specific size was available at a single location? Maybe we even have external developers that want to see stock and compare prices from our store as well as many others to aggregate information for consumer comparison shopping. Why reinvent the wheel to support these different groups? Aside from simple discovery, API Products make sense for reuse across different groups and lines of business where subsets of functionality from different APIs makes sense to come together to support a new logically grouping of those components into a new superset.
Security Profile
Let's build on the last scenario. We have this stock discovery API that is being used by a point of sale register, by the web site under the covers to provide information to our shopper, and by external developers. Will we manage and authenticate all these people the same? Will we provide the same quality of service to each group? Perhaps we utilize API Keys with external developers so we can track their consumption and charge accordingly. Do we apply the same logic to employees at the point of sale register, or perhaps utilize employee logins for this?
When security is applied at a per API level, the requirement because to either implement complex and brittle policies to handle all scenarios, or to maintain multiple versions of the same API in order to have different security protocols depending on the consumer. API Products also bring value in allowing resources to be grouped in a superset, and security protocols to be applied at the API Product level as opposed to the API level, allowing logic to be executed dynamically based on the consuming group or attributes, rather than via complex and hard to maintain all-user encompassing logic.
API Enterprise Strategies and Best Practices
Another important point to touch on is that these concepts also strongly support other enterprise API strategies. Let's take the product stock API discussed above for example. Would that API only contain the method to return the stores stock numbers as a GET request? Would it also perhaps include other APIs to POST new stock options to the stores registry, UPDATE stock amounts as sales occur, and potentially DELETE stock items as they are no longer offered? When we look at enterprise strategies such as API-first design, often we would see these like operations grouped within a single API in the initial definition. From here, it could be shared to allow development from many groups in tandem, such as the updating the website logic to display the stock, updating the back end servers to manage stock numbers as shipments arrives or items are sold, and allowing for data modeling to connect to the databases where this information is stored. As well as being of value for the other reasons mentioned, API Products gives us the ability to develop our APIs in a fashion that supports enterprise strategy, and then deliver and manage them a logical method to the different communities of interest.
In Conclusion
API Products are a value strategy that is emerging and furthering our use of APIs. Understanding the concept and utilizing it is a powerful strategy to fortify our use and adoption of RESTful API architecture. API Products give us the ability to take an API, apply applicable security protocols, while maintaining a paradigm where the methods can be shared across many groups. APIs should be managed and owned as Products, focusing on creating the best capabilities to support ease of use and consumer experience, which is best supported by rationalizing operations into reusable components, developed by design first strategies (eg. API-first), and owned by a Product Manager.
Curious to learn more about API Products, API Management, or any other topics discussed in this article? Come visit us at https://www.axway.com/en to learn more.
Comments
Post a Comment