Introducing a new technology requires advocacy on its behalf. Sometimes that means building a mathematical model for the expected benefits of that new technology. GraphQL is no different. Several enterprises we’ve worked with have often collaborated with us to benchmark the potential value of their adoption journey to get leadership approval or, in some cases, to better articulate the self-evident benefits and promote GraphQL to other teams.

In any space, there are two broad ways to think about ROI,  i.e. the benefits and costs:

Tactical benefits: Cost is a combination of writing some code/configuration and/or using a tool to do something. The benefit is someone else having to do less of what they used to do because it's inefficient, expensive, or both.

For example, a backend engineering team builds an API platform with built-in domain data aggregation (cost) so that the frontend team doesn’t need to write glue code to combine data from requests to multiple APIs(benefit).

Or, a backend engineering team learns how to use a tool and uses it (cost) to build an API platform in X weeks, as opposed to spending Y months without the tool (benefit: using alternatives, DIY, etc.). This comparison only works if the API quality in both cases is the same.

Strategic benefits: Again, cost is a combination of writing some code/configuration and/or using a tool to do something. The benefit is unlocking some competitive or strategic advantage – a gift that keeps on giving.

Examples:

• A backend engineering team builds an API platform with built-in domain data aggregation (cost), enabling the product team to deliver rich AI-driven user experiences (or even products) leveraging org-wide data/intelligence (benefit).
• A backend engineering team builds an API platform with built-in domain data aggregation (cost), enabling the product team to innovate 3x faster by testing new ideas in the market (benefit).

1. Replace other tools: For some use cases, it’s possible for your GraphQL or GraphQL federation stack to replace more traditional API aggregation tooling like API gateways and/or IPaaS tooling. It is also possible that you may have to use the two sets of tools together, temporarily or otherwise, for various reasons. Mapping out your architecture and requirements can potentially help you realize some gains by eliminating redundant components of your traditional stack.
2. Developer productivity: GraphQL provides an operating model for teams to collaborate on a single federated GraphQL API with tooling-based checks/balances that can help reduce the traditionally high cost of collaboration. This federated GraphQL API is inherently self-documenting. The individual components can also be standardized to ensure a high-quality API. This makes it easy for developers to learn the organization’s data model and execute on it.

An engineering leader’s role is to enable innovative ideas from stakeholders, most of which require data to be queried or manipulated. Strategic investments like GraphQL, if done well, allow you to do this rapidly, safely, at scale. The key is to balance the tactical benefits with the strategic gains.

ROI modeling blueprint

At a high level, to build an ROI model for GraphQL, you will need to:

1. Be sure of your motivation and clearly articulate your goals.
2. Build an architecture and an operating model for your engineering teams.
3. Define an API quality rubric; be mindful of how your architecture will evolve over time.
4. Choose approaches that deliver quickly without sacrificing quality.
5. Identify redundant legacy components.
6. Build an ROI model with estimates based on architecture and its evolution.
7. Test your hypotheses with PoCs. Iterate.

Prerequisites

Before we start to build GraphQL models, it's imperative to understand some fundamental factors that can influence the outcome of your model and even the success of your adoption journey.

Understanding the following trends in GraphQL is necessary to define and model the costs and benefits of of adopting GraphQL in your organization:

#1. Back to the backend: Fueled by the success of a self-serve API layer offered by GraphQL, product requirements typically find their way back to the backend or the domain data itself. As the need for new data increases in almost every GraphQL adoption journey, GraphQL has started becoming more of a backend engineering concern, especially with performance being a critical requirement.

Depending on where you introduce GraphQL, your benefits and costs are going to be different. For e.g. if you introduce GraphQL at the frontend (left), your benefits will impact frontend dev. If you introduce it in the backend, with the right tool, the benefits also go to your backend developers (see domain-driven GraphQL pattern below).

#2. Diverse subgraph tooling: To aid engineers working on the implementation journeys of revenue and time-critical projects, domain-first, and code-first subgraph patterns of building subgraphs have emerged, in addition to the typically resource-intensive schema-first pattern.

The time and effort investment needed to develop GraphQL APIs varies depending on your choice of pattern and data sources.

To “do the math” on the benefits of GraphQL, you’ll need to know how you’re going to use it. You don’t need to nail down all the details at this stage, but it helps to know the high-level data-to-API architecture. This design will give you a better understanding of all the moving parts, and the potential for operational, performance, and cost optimizations.

It is also important to understand that your architecture will evolve if/when the adoption of GraphQL spreads in your team or organization.

Check out our post on GraphQL maturity cycle to understand how it could potentially pan out in your own organization.

Example ROI models for GraphQL

It’s hard to come up with an accurate all-encompassing ROI model in any domain.  From our experience, we recommend using a combination of:

• Qualitative insights: A well-thought-out narrative for the motivation to use GraphQL, key goals or pain points to be addressed, architecture, and associated benefits.
• Quantitative gains: Pick your top quantitative gains. Keep your ROI model simple by focusing on key measurable gains that will help pay for the adoption effort. This can be a combination of cost savings, reduced hiring requirements, costs of redundant tools, profitable business outcomes, etc.

With the above context and the benefit of Hasura’s work with several enterprises and SMBs, let’s take a look at how some engineering teams have estimated and measured their ROI from adopting GraphQL. These two models contrast not just the approaches taken but also the level of detail their estimates were based on.

The following detailed model is based on a GraphQL adoption story in a large bank, with several engineering teams interested in building three GraphQL-driven API platforms for different lines of business. Due to the scope of the program, estimates were modeled with some degree of sophistication.

GraphQL goals

The central API platform architecture group in this large bank wanted to address the challenges of growing demands from new client applications, each with diverse data requirements, by building purpose-built API platforms on existing domain databases.

The goals of each of these platforms was to:

• Provide a unified view to all consumers (website, mobile app and other services).
• Improve customer experience, product autonomy, development efficiency, and integration capabilities.
• Accelerate time to market
• Reduce the need for constant API updates and maintenance

Architecture

To meet the above goals, the architecture team decided to use GraphQL. Specifically, they decided to use a domain-driven approach to building subgraphs using Hasura, and use Hasura to also federate over these subgraphs (they built three supergraphs or federated API platforms).

ROI model

The team determined the rates for building APIs traditionally (REST) and using domain-first GraphQL. These rates applied to the API requirements across all projects over three years gave them a sense of their total costs for the two approaches. They were also able to determine that for one of the use cases, they could eliminate the need for a gateway as their new tooling was capable of handling gateway features like caching and API limits for this internal but performance-sensitive project.

Their ROI model looked something like this (the definition of API and the numbers here are illustrative):

Here’s how to interpret this model:

1. Investing in domain-first GraphQL is profitable for the team, saving them several hundred thousands of dollars.
2. Investing in domain-first GraphQL frees up a lot of time for the backend engineering teams, which can be invested to solve more undifferentiated problems.
3. There are additional benefits to the frontend engineering team (see next model), which haven’t been factored in to keep the focus on the key takeaway.

The following high-level model is based on a two-year adoption story of one of the many GraphQL projects at a communications giant. This engineering team faced issues stemming from the natural drawback of microservices sprawl – a hard-to-consume suite of many REST APIs, and the overhead of running and maintaining these many APIs. The team modeled the benefits at a very high level, choosing to focus on key productivity gains and testing their hypothesis with carefully crafted proofs-of-concept.

GraphQL goals

• Strategic: Improve time to market for features
• Tactical: Improve developer productivity by reducing API chatter between frontend and backend engineering teams. And also, reduce operational overhead of maintaining APIs

Architecture

The team decided to adopt GraphQL in two phases. Phase 1 focused on building a quick facade on existing REST APIs to test the benefits to the frontend team (check out the architecture diagrams from the above section on tactical gains).

Subject to success in the first phase, phase 2 improved the architecture by building GraphQL-native domain services using Netflix DGS instead of a facade on existing REST endpoints. The team also used some simple custom tooling to federate over multiple domain services.

ROI model

Frontend developer productivity: The engineering leadership of this team estimated that the frontend team would be 50% more efficient in building frontend features if a self-serve GraphQL API was made available to them. At this threshold, the team estimated that the benefits would outweigh the benefits of building a GraphQL facade over existing APIs. A PoC with a domain helped benchmark the fact that developers were more than 2x productive with GraphQL.

Backend developer operational overhead: Given the choice of schema-driven tooling, the effort that went into building the domain GraphQL services was almost on par with the effort to produce equivalent REST APIs. However, the team was able to reduce about 80 endpoints to approximately 14 domain services. This resulted in lower infrastructure costs, maintenance costs (upgrading libraries with vulnerabilities, etc.), etc. In the long run, they also reduced the number of iterations needed in the backend by 20%.

Caveats

1. No model can completely accurately capture all the moving parts or details that’ll only emerge when actually using new technology. Experimenting and iteration are highly recommended.
2. GraphQL is just a spec. There are several approaches to implementing a GraphQL API, and sometimes you’ll pick more than one based on your requirements. Again, experimentation is key to understanding the tradeoffs between different approaches.
3. Sometimes GraphQL could be an enabler in a larger initiative like technology modernization, public cloud adoption, etc. In these cases, your ROI model is likely going to be a part of the overall model and needs to demonstrate exactly how GraphQL is effective or more efficient than alternatives at helping meet the larger initiative goals.
   

If you’re interested in learning more about how Hasura can bring value to your organization, our team of solutions architects can partner with you – please contact us here.