Define your Use Case
Define the business use case that consumers and producers will align on
Before you start creating your platform, establishing a clear, shared understanding of your first use case is an essential first step that sets up your project for success.
Defining the use case for your graph helps you:
Align stakeholders toward a common goal
Reduce implementation friction
Provide prioritization guidelines for your team
Improve delivery times
Ensure your GraphOS implementation delivers measurable business value
Identify stakeholders
A graph use case connects one or more consumers to one or more producers to solve a problem. Identify and involve the stakeholders that can represent the platform, consumer, and producer systems when defining the use case. Involving these teams early in the process replaces friction with a creative tension, and helps ensure a more optimal outcome for the business.
Graph consumers are the clients that execute operations against your graph endpoint. Consumers are often closer to where organizations capture business value. Examples of consumers include web clients, mobile clients, AI agents, MCP servers, and other client-side technologies.
Graph producers are responsible for providing the data represented by your graph schema. Examples of producers include APIs, databases, data services, and other reusable components.
Consumers and producers are connected by the Apollo GraphOS platform.
In most graph implementations, different teams typically manage each of these roles. Sometimes, a single team might be responsible for managing the GraphOS platform, the consumer and producer sides of the use case.
Each team may have a different set of priorities, motivations, and constraints, representing potential points of conflict that might introduce friction in your graph development lifecycle.
Define the pain points
A pain point is a point of friction that prevents teams from delivering a fast, safe, enjoyable, and successful flow of work.
Quantifying the pain points up front helps you align on the problem you are trying to solve. It also establishes a way to measure your progress against a desired improvement outcome.
Examples of typical pain points addressed by graph use cases include:
Product velocity issues: teams blocked, waiting for API changes
Poor user experience: poor application performance due to under-fetching and over-fetching
High costs: engineering costs, infrastructure costs
Security risks: lack of scoped authorization access, lack of observability, and audit
Bring together representatives from the platform, consumer, and producer teams to discuss the following:
What are the main pain points that are driving your graph use case? Be specific about the technical, organizational, or business problems you're facing.
Gather quantitative and qualitative evidence of these pain points.
Define the constraints
Constraints are requirements and boundary conditions that you must satisfy for the use case to be successful. Constraints might include technical requirements, organizational requirements, or non-functional requirements.
Examples of constraints include:
Infrastructure constraints: using AWS, GitHub Actions, Helm, Datadog
Security constraints: implementing corporate security requirements and passing an assessment
Team constraints: having two full-time developers on each team available for three months
Operational volume constraints: supporting 2 billion operations/month by end of month 3
Cost constraints: the environment supporting operational volume without exceeding a runtime fleet operational cost of $2K/month
Other non-functional constraints, such as response time, p95/p99 latency, availability, and scalability requirements
Discuss, define, and document the constraints that are truly required for success. Seek ways to reduce or eliminate constraints where possible, to allow for flexibility when you don't know the solution in advance.
Identify goals, actors, impacts, and deliverables
Define the goal
A goal is a positive business outcome you aim to help achieve through the implementation of your graph use case. It addresses one or more pain points.
Well-defined goals are specific, measurable, ambitious, realistic to achieve, and time-bound. They're often tied to strategic priorities for the organization.
Defining the goal aligns efforts across teams, helps eliminate unnecessary steps, and speeds up decision-making.
Examples of well-defined goals:
"Reduce the average time it takes to ship mobile app features by 20% in the next 3 months, by eliminating the need to wait on API changes in our frontend development cycle."
Decrease API maintenance costs by 40% in the next 3 months, by consolidating our 15 REST endpoints into a single GraphQL endpoint that serves our web and mobile teams."
"Improve customer experience by reducing the page load times for product search and add-to-cart by 35% in the next 3 months, by implementing more efficient data fetches and API invocations for those pages."
Using your pain points as a point of reference, take the time to discuss, define, and document your use case goals. Your graph use case might have one or more goals. Consider goals that provide benefits to end users, to development teams, or to the organization as a whole.
Define the actors
Actors are the teams and people who have a role to play in the achievement of your goal.
At minimum, identify actors who are responsible for implementation efforts of graph consumers, graph producers, and the platform itself. Key actors might also include additional internal and external teams involved in the value stream.
Examples of actors include:
Application end user or user cohort
Web and mobile frontend developer team
Third-party partner developer team
Service owner maintaining microservices and APIs
DevOps engineering team
Security and compliance team
Using your goal, discuss, identify, and document the actors who could help or prevent the achievement of your goal.
Define the impacts
Impacts are the changes in behavior you need to see in your actors, to achieve your higher-level goal.
Associate each actor with one or more impacts that they would consider desirable and relevant in the context of the goal.
A well-defined impact can start with "increase" or "decrease". Although not required, it helps ensure it defines a behavioral change in those actors.
Often, reversing the polarity of a pain point is a way to express the impact you wish to achieve. For example, if the frontend team is experiencing an increase in the time spent waiting for API updates, then decreasing their wait time is the behavior you need to see in your frontend developers.
Examples of impacts:
Decreased wait times on API updates (Actor: Frontend devs)
Decreased time required to expose a new Product attribute to frontend teams (Actor: Product microservice team)
Increased assurance that PII is securely protected from unapproved access (Actor: Security team)
Increased app enjoyment while using the product catalog main page (Actor: end users)
Discuss, define, and document the key impacts needed to achieve your goal. Review your pain points to identify key impacts.
Define the deliverables
Deliverables are the specific work items or features you need to implement to create the impacts needed to achieve your goal.
You can often solve a problem or create the desired impacts in multiple ways. Identifying multiple deliverables that provide different ways of achieving your impacts and goals is a useful practice at this stage. Identify these deliverables based on observations and evidence that suggests the deliverable is likely to produce the desired impact.
By tying deliverables to impacts, which in turn are tied to actors and goals, you will be able to create a testable hypothesis: "If we build these deliverables, they will create these impacts in these actors, which will help us achieve our goal."
Conversely, if deliverables are not easily tied to impacts, it might indicate that the work isn't actually required to achieve the goal, or that a key impact isn't yet well-defined. Examples of deliverables include:
Implement new product catalog capability using 5 new GraphQL queries (Impact: Decreased API wait times)
Use connectors to add our 15 product catalog microservices (REST APIs) to the graph (Impacts: Reduced wait time, reduced attribute exposure time)
Implement query plan caching and entity caching for operations related to the product catalog (Impact: Increased app enjoyment)
Implement OAuth scopes that ensure PII is not exposed (Impact: PII assurance)
Discuss, define, and document key deliverables needed to achieve your goal, tying each to at least one defined impact.
Find the shortest path to the goal
The shortest path to the goal is the set of deliverables that most likely achieves your goal with the lowest effort and risk.
A common anti-pattern of graph platform engineering is platform over-engineering. Platform over-engineering occurs when implementation teams spend an excessive amount of time in the design phase, preventing delivery work from occurring, creating delays for consumers and producers.
It typically occurs because a platform team is trying to build a system that satisfies a broad set of concerns seen across many different teams across an organization. The platform team aims to drive broad adoption to achieve the economies of scale that great platforms provide. As a result, they can fall into the trap of attempting to satisfy all potential parties, which leads to delays, a reduced return-on-investment, or even the disbanding of the team due to a lack of demonstrable results.
Instead, aim to ship the Minimum Viable Graph (MVG) required to build your use case and achieve your goal. Examine your set of deliverables, impacts, actors, and goals. Look for multiple pathways to your goal. Discuss the paths, including their likelihood of being successful, the implementation efforts and/or costs involved. Find the shortest path to the goal: the one with the best impact-to-effort ratio.
Conclusion
You have now defined a clear, shared understanding of your first use case. Refer to it often to keep teams focused on a common goal, eliminating unnecessary work, improving delivery times, and ensuring your GraphOS setup delivers measurable business value.
Getting Help
Looking for expert assistance in GraphOS use case identification? Contact the experts at Apollo to schedule time and we can help review your company's infrastructure and goals.