There is a lot of noise in the market lately about APIs and whilst web-based services that pass, extract and push data to applications and other services have been around for a fair while, for many in the business community this is still fairly new.
The transformation of most regular business environments to be software driven has been a big driver for this change.
There are a lot of false assumptions and misunderstanding around this whole space. Often that automation is in itself a cost saver — it often isn’t. That all stakeholders have the same motivations and drivers for doing business — they don’t. That creating an API service is as simple as “we need to automate passing this data” — it's not.
There are also major cost implications for developing and supporting infrastructure at scale. Many organisations struggle to deliver value from automation as they fundamentally struggle to take a view of the bigger picture and factor in the inevitable challenges of existing infrastructure, payments and support automation, SLAs they need to support, security, compliance, data privacy, data governance….the list goes on.
So how do we go about evaluating API services whether we need one or not? Identifying existing services and their possible use cases for our products, services and benefits for our organisations?
Customer value proposition
This is the best place to start. What is the benefit for the end user? Is it really a benefit? What are the hard motivators for this customer to use your service? Will they make money? Save money? Measurable metrics, measurable metrics….
See Strategyzer templates here: https://www.strategyzer.com/canvas/value-proposition-canvas
Product-orientated businesses need to define a product persona because you need to know how much demand you will have for your service, as this drives requirements and ultimately how big your TAM is..
Total addressable market (TAM)
If you are developing an API as a service, you need to understand how many users you will have to sell to. If you are serving internal customers in a big org this will still have an impact on future requirements for any service and performance of that service. 100 API calls per day are a different beast if you suddenly have to add a few zeros. Do your research to make sure your numbers are defensible.
https://blog.hubspot.com/marketing/total-addressable-market
Business case — value for your business
The customer may get a benefit. But what is the benefit for your organization? There is little benefit in transactions that result in a financial loss. You need to define the short to medium-term, as well as a longer-term picture. Remember in business most orgs are looking at quarterly results, forecasting 5 years in the future when you need to hit a 5% sales lift or cost cut in 3 months frames the business drivers somewhat. Make sure you include hard measurable metrics here.
Build versus Buy
Building infrastructure is time-consuming and expensive. Building out API infrastructure including automating invoicing/payments from users, account management, rate limiting, throttling, automated scaling, security monitoring, compliance and support, could be weeks, months and years. Most startups begin with a single product proposition test that as a product and build out the other components as they scale. It's important to understand that a function to pass the data is only one component of your API service. For enterprise solutions and services, your scope is much bigger than that.
Big platform providers offer a lot of this out of the box for a license fee and allow you to build applications and connectivity within days for a variety of common use cases. These do however fall down when additional data fields are missing (and can’t be easily implemented), there are dependencies on other infrastructure, or a lack of data integrity. Is the API the product? Or is the platform part of the service you offer as an organisation because other platform providers you have looked at don’t offer X key requirements? What are your requirements for speed to market? If you have a demand for speed to market and earning transaction fees quickly being able to implement as many services as quickly as possible might be critical to success, but understand that may severely limit your use cases and USP.
Requirements gathering
A template you can copy here:
Define your customer value proposition: For example — by automating X service we anticipate a 30% cost saving for our customers.
Define your customer profile: How does it fit with the customer value proposition?
Define your total addressable market. How many users based on your product persona will you have? Do you have a good reliable source of data to guide this? or are you guessing? How many users is it realistic to get?
Define your performance requirements. How many calls will these users make to the APIs each day? Within what time periods? How business-critical is this?
What is the benefit to your organisation? What will implementation cost? What returns do you need to make in what timeframe? How will this meet your shareholder's expectations or your organisation's KPIs’?
- Insert Excel document with pricing model forecasts and ROI.
What pricing approach will best serve your users? Are they enterprises? or individuals? How might different approaches change your cost forecasts?
Guidance from Nordic APIs on pricing models and which will fit your org here;
What are the value drivers for other players in the ecosystem? Do you need to be able to send or receive data from other 3rd parties? Are they motivated to do business with you? What is the financial benefit for them? Are there other value drivers?
How will you distribute your product? Will it be packaged up with other vendors? Will you have to consider direct marketing costs to users? Do you have to tackle outbound sales? Or will your pricing/market position / internal user requirements etc generate enough inbound? How will this affect other business value drivers or product propositions? Will it affect other product pricing?
What's your “Go to market strategy”? How will you scale your product offering? How will you reach your customers?
What data are you passing to where? What fields and in what file and format? Does this data need to be stored? Does it need to be deleted or updated or maintained in some way? Do you need user permissions for that data?
Data privacy — do you have permission to process your user's data? Is it subject to any compliance requirements (for example GDPR for the EU)?
Data access — do you have access to the data you need? Is it in a “clean” and maintained format? Is there good data integrity or does it need to be transformed? (example: Is it in a different file type you need to change to pass to store or be consumed by another solution/service)?
How will you control data access with your users? Will the service be rate limited? Will it be packaged with other services? How does that affect your pricing?
What are the barriers to ensuring data integrity? Are there any organisational barriers? Do you have the appropriate infrastructure in place to manage secure data at scale? Who is responsible for this ongoing?
What are your SLAs? What happens when you have a system outage? What happens when your service is hit with a cyber attack? How long do you have to recover? What will the terms and conditions of your contract be and who will be responsible for this? How will this person be notified and in what timeframe?
Costs and billing — how will you ensure you get paid? Will this be automated so your customers just sign up and invoices are automatically submitted? Does this need to be negotiated? What is the overhead for this? Can you buy a solution which does this? Or do you need to build it? Do any restrictions affect your pricing and customer value proposition?
Support — what support do you need to offer to your users? How much of what is included in the pricing tiering for the product? What are the SLAs there? Who will be responsible for this?
Team — do you have the right competencies, and manpower to implement the new product or service? Do your team need training? Will their roles change? Do you need to hire someone?
and Finally….
Given all of the above if you go back to your original forecast…was it accurate? Or is there a lot more you need to add now? What impact will this have on your architecture? What is your product roadmap now? What is your technical roadmap? How has that changed with these new requirements?
Understanding technical documentation
Most people without a lot of programming knowledge can learn to read code and therefore read API documentation. How easy this is depends on the quality of the documentation. Things like file formats, types, fields that are available or missing, and whether the data can be updated or deleted should be with a bit of learning not too hard to grasp. A guide you can find here.
https://betterprogramming.pub/how-to-read-and-understand-api-documentations-2f894b51d0b7
Further considerations
Architecture and specific technical components and how that affects your product choices is another conversation I will add at a later date.
I am an AWS and Azure Cloud Architect. If you have any queries about API products or architectures please find me on LinkedIn.