API Development Efficiencies

Evidence and data. According to Forrester, API design is one of the most important aspects of API strategy: It will make or break adoption.⁴ Using SmartBear’s API solutions, interviewees reported efficiencies across their organizations’ API development lifecycle: from design to document to test. With the shift to an API design-first mindset, interviewees explained how communication across their development and product teams improved. Teams gained the ability to communicate asynchronously, cutting down on time spent answering questions and in meetings documenting APIs together. Interviewees also shared that developers and architects gained the ability to test APIs earlier in their development cycles and identify potential challenges sooner.

• The product architect at a software organization explained how their software team realized time savings of 15% to 20% in the design phase of their API development lifecycle. They said: “The benefit of Swagger API is the ability to provide the API design-first approach. We first design the APIs without the real code in the backend. By using the linting feature as a shift-left concept, wherein you can test and validate the application without the real implementation, it improves developers’ efficiency.”

• The product owner at a financial services organization said, “It used to take 20 hours for an API provider to create a template and integrate that with contract testing — and now it’s an hour.”

• The director of enterprise architecture at a retail organization said: “Swagger has been a big help to make sure that we’re all working off the same sheet of music and we’re able to collaborate. Teams can post comments and updates, and then other teams can leverage them in a different part of the world during their working hours. That’s been a big success of Swagger for us.”
  The same interviewee continued: “[Now] we’re starting to get more adoption [around being API-first]. We have successful stories where we’re able to develop more in parallel and have contracts at least drafted and mutually agreed to before we go out and build or modify the component that’s going to deliver that API or consume that API. This goes back to the efficiency piece. It has allowed us to identify and have those conversations more upfront, where historically we probably would have built the component and the last thing we would have focused on was the integration to the ecosystem around it. Which is where we would discover, ‘Oh, I didn’t account for that attribute,’ or ‘I didn’t realize the consuming system needed to know that, and I’m not handling that in a way that I can share it easily.’ This enables us to discover opportunities or potential challenges sooner in the process.”

• The senior software engineer project lead at an IT organization said: “First we did an internal pilot with one team that was already under very active API development. They started making a lot of use of the features and, right off the bat, they started using the commenting features when reviewing documents. One person writing the document and other team members jumping on comments, making suggestions for changes, and standardizing processes — all before anybody has invested any time in a line of code. … We saw that immediate efficiency come through.”
  The same interviewee continued: “Our quality engineering team saw efficiencies from first being able to see these designs before any code is released, as they could start creating test cases. Then when they did have code available, they would use the ‘try it out’ functionality within [the] API Hub design to start to test out some of those APIs before doing their automated testing.” The interviewee estimated that testing times were 25% faster for the quality engineering team.

• The VP of platform and infrastructure at an IT organization explained that their developers save at least an hour of time per API due to eliminating a meeting with their product team for documentation discussion.

Modeling and assumptions. Based on the interviews, Forrester assumes the following about the composite organization:

• The composite organization develops 75 APIs in Year 1, 100 in Year 2, and 125 in Year 3.

• It takes 160 hours to develop an API in the prior environment.

• With SmartBear, the composite organization gains efficiencies of 50% in the time to develop an API.

• The fully burdened hourly rate for a developer is $84. The average fully burdened annual salary for a developer is $175,000.

• Only 50% of the recaptured work is spent on productive activities.

Risks. The value of this benefit may vary among organizations depending on:

• The number of APIs developed annually and their design complexity.

• The time it takes to design, create, and test APIs in their prior environment.

• Developers’ salaries.

Results. To account for these risks, Forrester adjusted this benefit downward by 15%, yielding a three-year, risk-adjusted total PV (discounted at 10%) of $699,000.

API Reusability Improvement

Evidence and data. Interviewees explained that improved documentation meant API discoverability across their organizations increased. Developers gained a better understanding of which APIs existed and how they could reuse these APIs for additional use cases. Interviewees explained how their developers saved time by leveraging the design-first mindset and templates available in SmartBear’s API solutions and reusing content for other services rather than creating a new API.

• The product architect at a software organization estimated around 30% to 40% of their APIs are now reused or adapted from existing designs. They said: “The legacy approach involved an [API] customer asking for some attributes and us delivering because one customer asked for it. What we want to do is provide a reusable solution or a scalable solution. [Now, we ask] if the API is following industry standards as well as whether we are adding this attribute only for the benefit of this customer or any other customer.”

• While not yet fully realized, the global enterprise architect at a retail organization said, “Best case is more than 50% of our APIs can be reusable [as part of our ongoing strategy].”

• The director of enterprise architecture at a retail organization said: “We are trying to push hard on the reusability piece. I think we’ve been pretty successful in doing so. As a specific example, I was involved in being able to manage the task sequence of a customer enrolling in loyalty, whether that be in the store or on a mobile app or on the web. We had a single standard onboarding flow and then we were able to leverage that same onboarding flow when other programs came up — subscription programs or a ‘pay by your license plate’ experience on the mobile app. Historically, those would have been unique projects handled in their own silo. As a practice and in the use of the tool, we’re able to showcase, ‘Hey, this is what this API already does. I think it meets your use case as well. Let’s talk through it. Showcase it.’ Or ‘We had to make this one tweak because there’s an additional attribute we need to capture in the onboarding flow.’”

Modeling and assumptions. Based on the interviews, Forrester assumes the following about the composite organization:

• The composite organization develops 75 APIs in Year 1, 100 in Year 2, and 125 in Year 3. Cumulatively, this equates to 75 APIs in Year 1, 175 APIs in Year 2, and 300 APIs in Year 3.

• In Year 1, 20% of the APIs can be reused. This increases to 25% in Year 2 and 30% in Year 3.

• It takes 160 hours to develop an API in the prior environment.

• The fully burdened hourly rate for a developer is $84. The average fully burdened annual salary for a developer is $175,000.

• Only 50% of the recaptured work is spent on productive activities.

Risks. The value of this benefit may vary among organizations depending on:

• The number of APIs developed annually and their design complexity.

• The time it takes to design, create, and test APIs in their prior environment.

• The extent to which APIs can be reused across use cases.

• Developers’ salaries.

Results. To account for these risks, Forrester adjusted this benefit downward by 15%, yielding a three-year, risk-adjusted total PV (discounted at 10%) of $672,000.

API Consumer Support Efficiencies

Evidence and data. According to Forrester’s research, internal developers seek to access and provision resources without opening a ticket to a central shared services team. For external developers, the portal isn’t just an API directory: It is a means of improving developer engagement.⁵ In addition to development efficiencies, interviewees reported that their organizations spent less time addressing API consumers’ needs after implementing SmartBear’s solutions. Interviewees shared that their use of Portal through SmartBear’s API solutions allowed their organizations to customize a branded portal so that external consumers could easily navigate their API catalog. With access to accurate and up-to-date documentation and improvements to contract testing, consumers onboarded APIs quicker. This resulted in less back and forth with the development team.

• The product architect at a software organization estimated a 30% to 40% reduction in time spent managing API-related questions and onboarding support. They said: “If we want to showcase the Swagger API or our portal documentation to some customers, we go to [domain name]. It is easier for customers to see how the API looks before the implementation. That is super efficiency from our point of view. Previously, we either needed to send some JSON sample requests and responses or emails or [provide] some demos, but now, it’s self-explanatory.”
  The same interviewee continued: “In Swagger, there is an option to generate code using different languages. Once we create our API, if we want to sell to a customer and they want to use our code on their user interface (UI), they can simply go to our Swagger URL and download the software development kit (SDK) in Java or Python and develop their UI application easily. Previously, that was not possible. This is additional value for our customers.”

• The global enterprise architect at a retail organization said: “We have so many users and a huge enterprise architecture with a lot of systems that have a dependency to each other. If we send out an API that has an incorrect contract, even in the worst case, it can block our business. That’s why it’s so important to have this contract checking so early.”

• The product owner at a financial services organization said: “Because of several standard templates, onboarding for both consumers and providers used to last a day, which included a bit of time waiting. Now, that has moved to 18 seconds [for some APIs].”

Modeling and assumptions. Based on the interviews, Forrester assumes the following about the composite organization:

• Cumulatively, 75 APIs are available in Year 1, 175 in Year 2, and 300 in Year 3.

• Fifteen APIs are reused in Year 1, 44 are reused in Year 2 and 90 are reused in Year 3.

• In the prior environment, it takes 10 hours per API to support consumers’ activities.

• With SmartBear, the composite organization gains efficiencies of 70% in API consumer support activities.

• The fully burdened hourly rate for a developer is $84. The average fully burdened annual salary for a developer is $175,000.

• Only 50% of the recaptured work is spent on productive activities.

Risks. The value of this benefit may vary among organizations depending on:

• The number of APIs developed annually.

• The extent and complexity of API consumer support provided.

• Developers’ salaries.

Results. To account for these risks, Forrester adjusted this benefit downward by 15%, yielding a three-year, risk-adjusted total PV (discounted at 10%) of $151,000.

Unquantified Benefits

Interviewees mentioned the following additional benefits that their organizations experienced but were not able to quantify:

• Developer satisfaction. Interviewees shared how SmartBear’s API solutions unlocked developer capacity, improved their day-to-day workflows, and eased ways of working with other developers and architects. The global enterprise architect at a retail organization said: “We have a huge number of developers who need access to documentation and the ability to test APIs. This is something they can do in Swagger. They say, ‘Wow, that is exactly what we need.’”

• Cross-functional collaboration. Interviewees emphasized that SmartBear’s API solutions improved visibility into the API development lifecycle, which streamlined collaboration with various teams across their organizations. The director of enterprise architecture at a retail organization shared an example: “As an organization, we have not done a great job documenting a lot of things. Our security team [recently] said, ‘Hey, we’re taking a deep-dive focus on API security. Is there a catalog of APIs?’ And I said, ‘Yes.’ They were so impressed because it’s just that type of thing doesn’t exist in a lot of other areas of our organization, and it made their job really easy.”

• The creation of API quality standards. According to Forrester’s research, API programs need a strategy for versioning APIs and for governing their compliance with design and security standards.⁶ Each of the interviewees’ organizations was at a different point in defining and applying API quality standards practices across their development lifecycle. Interviewees explained that ensuring quality was a collaborative initiative and shared how SmartBear’s API solutions provided their organizations with a centralized repository to track these standards.
  The product owner at a financial services organization said: “I became a work group lead for the vision of quality for the bank, leveraging the quality maturity model, which is in development. When a squad starts engineering work — whether they have a product they’re releasing or a feature change — at the point of code to release, they should know their product risks are all solved and taken care of. It’s at that critical moment that we can discuss knowledge gaps.”
  The senior software engineer project lead at an IT organization said: “We are starting to define standards that we want our APIs to adhere to, whether they’re internal or externally exposed. As much as possible, we’re codifying those standards within the API hub.”
  The product architect at a software organization said: “I am not alone in making the decisions of writing the schemas. I ensure that once the design is completed, I exchange notations with other product architects and [get] thorough reviews by other colleagues.”

• Process standardization, which influences best practices across teams. Interviewees explained that SmartBear’s API solutions afforded their teams the ability to design and centralize structured and repeatable processes. As these processes created operational efficiencies, interviewees shared that their teams used this way of working as a model to drive further standardization in other areas of their organizations. The product owner at a financial services organization said: “By using contract testing as an example of what a good standardization opportunity is, we were able to also inspire others around the story and help them leverage the way that we created a managed standardized service, [which had] far-reaching inspirational impacts. This became a blueprint for someone who wanted to create a managed standardized service with monitoring for our provider squad [to show] how our production and pipeline is doing and a health monitor of what is happening for our consumers.”

Flexibility

The value of flexibility is unique to each customer. There are multiple scenarios in which a customer might implement SmartBear’s API solutions and later realize additional uses and business opportunities, including:

• Improving the time to market for revenue-generating APIs. Forrester’s research shows that those using APIs to deliver new products or push the business in new directions will use a commercial financial model with a direct or indirect monetization strategy.⁷ Interviewees anticipated releasing revenue-generating APIs to consumers more quickly as their organizations continue to gain API development lifecycle efficiencies. The VP of platform and infrastructure at an IT organization said: “With our quality engineering group being able to start testing that before the code is written and having an understanding of what that API is going to look like, I think our turnaround time on pull requests is going to go down. Our time to market will speed up for those APIs.”

• Expanding to additional users. Interviewees expressed excitement at offering SmartBear’s API solutions to their full development teams over time to continue to drive the API-first mindset and standardize practices. The product architect at a software organization said: “We wanted to start small and showcase the benefits to our enterprise leadership team. Soon, we are planning to increase the [number of] team members.”

• Exploring additional functionality. Some interviewees discussed adding additional integrations, while others mentioned specific testing functionality requests like bidirectional testing or AI features. The VP of platform and infrastructure at an IT organization shared: “I expect developers to use HaloAI as a primary path going forward. I would expect it to be used during the design and development of OpenAPI documents.”

• Providing a consistent platform experience. Interviewees spoke about the benefit of accessing a consistent platform experience for managing multiple SmartBear API solutions. They shared an expectation that a unified platform would drive efficiencies, such as managing user licenses. The director of enterprise architecture at a retail organization said: “I’m excited to see [SmartBear] bring it together as a more consistent platform experience. … I think that it will create value for us as we adopt it more and are able to leverage more of that single platform than a collection of different tools that are loosely connected.”

Flexibility would also be quantified when evaluated as part of a specific project (described in more detail in Total Economic Impact Approach).