One Place for Data and AI Enablement
At a glance
Problem
Employees had no single, trusted place to find current data products, internal APIs, approved software, training, or documentation. Instead, people moved between SharePoint sites and internal portals without knowing which sources were current or maintained. Teams often rebuilt tools or purchased licenses independently because finding and coordinating with the official internal solution took more time than solving the problem locally. The deeper technical constraint was that many APIs needed for a consolidated employee experience either did not exist or could not participate in modern SSO/OAuth authentication.
Solution
Modernize identity first using OAuth2/JWT and SSO so applications could share a consistent authorization model. Then provide a federated GraphQL platform as a service, allowing domain teams to expose their capabilities as subgraphs rather than creating another isolated REST application. On top of that foundation, build a React-based data and AI enablement portal plus Atlas, an employee collaboration platform. Atlas also owned the shared employee/user domain on the graph so other applications could query and extend a common User entity instead of repeatedly importing and maintaining their own employee-directory data.
Services
- Identity & access (OAuth2 / JWT / SSO)
- GraphQL federation platform
- Data & AI enablement portal
- Schema governance
- Developer experience & training
- Domain-specific subgraphs
- 5
- Languages with boilerplates
- 4
- Enablement workshops
- 3
- Time to first subgraph
- 1 mo
The Context
What was happening before we got involved?
The Chief Data Office wanted an AI enablement platform.
The first step was an inventory of the existing environment: data products, internal APIs, approved software, training resources, and documentation.
There was no reliable source of truth.
Enablement was spread across SharePoint sites and internal portals, and employees could not easily tell which information was current.
That fragmentation encouraged duplication. In many cases, standing up a new tool or buying a local license was faster than discovering and coordinating with an existing internal solution.
The larger issue was architectural.
Some of the APIs required for a single employee experience did not exist, while others used authentication patterns that could not support modern SSO/OAuth.
That meant a unified experience was not simply an interface or integration problem. The platform foundations were missing.
How did the collaboration evolve?
The work began as research inside the Chief Data Office: understand what existed, identify gaps, and design an enablement experience around those findings.
It became a broader platform program once it was clear that a portal by itself would only hide the underlying fragmentation.
Fyve's work centered on the shared infrastructure and the flagship applications built on it.
Domain teams would continue owning their capabilities, but those capabilities would be published as subgraphs into a federated graph rather than becoming another REST silo with another login.
That required leadership alignment, a GraphQL platform offered as a service, and a developer experience strong enough for REST-native teams to adopt it.
“GraphQL enabled us to build better and faster while accomplishing true federation of our data.”
Discovering the Root Cause
At first glance, what did leadership think the problem was?
Findability.
The apparent solution was to organize the existing links better: improve the catalog, improve SharePoint, and publish more documentation.
The assumption was that if employees could find the right resources, duplication would decrease and AI teams would have what they needed.
What did we discover?
The catalog was not the real constraint.
A single trusted employee experience could not be composed from APIs that did not exist or from APIs that could not participate in modern SSO/OAuth.
REST was the default architecture.
Each domain could create its own application, but those isolated surfaces could not easily be combined into one unified product.
Teams were not avoiding reuse because of poor discipline.
Duplicating capabilities was often the path of least resistance.
The Platform Strategy
1. Modernize identity
Move to OAuth2/JWT and SSO so products and subgraphs could participate in a shared authorization model.
Identity had to move first. Otherwise, every new application would simply become another authenticated island.
2. Create a federated GraphQL platform
Provide federation as shared infrastructure rather than requiring every team to build and operate it independently.
The platform included a subgraph registry, gateway/router, CI/CD, schema validation, schema composition, and governance guidance.
Domain teams retained ownership of their capabilities while publishing them into the shared graph.
REST coexistence was expected. The goal was not to force the entire enterprise to become GraphQL overnight.
3. Build flagship applications on the graph
Build the products that proved the platform could support real employee experiences.
The first was a React-based portal serving as the front door to data products, approved software, training, documentation, and events.
The second was Atlas, an employee collaboration platform originally used by mobility application consultants.
Atlas also exposed the employee/user domain as part of the graph.
Other applications could then extend and query a shared User entity instead of independently ingesting and normalizing the company directory.
What Was Hidden Beneath the Surface
What problems were hidden just beneath the surface?
Maintenance and ownership were major issues.
Listings became outdated, and responsibility for keeping information current was unclear.
The same duplication appeared in the data model.
Internal applications often consumed daily copies of the employee directory and normalized that data into their own databases.
Core entities such as User were repeatedly reimplemented.
That meant teams spent time rebuilding shared plumbing rather than focusing on their domain.
Federation also introduced an adoption challenge.
GraphQL Federation could not simply be installed and expected to succeed inside organizations accustomed to REST.
Without platform-as-a-service, governance, boilerplates, CI support, documentation, and live training, the graph would have remained an architectural mandate rather than a platform teams wanted to join.
Developer Experience and Adoption
How did the platform team support adoption?
The platform team ran the difficult shared infrastructure: registry, gateway, composition, and validation.
Domain teams received boilerplates in languages they already used, shared libraries, CI workflows that rejected invalid schemas before production, documentation, and live workshops.
Governance came from a small oversight group rather than a centralized team building every API.
Leadership made the destination official.
Developer experience made joining the graph easier than continuing to operate as another silo.
A shared employee domain further reduced the need for teams to recreate foundational data structures.
Results
What happens when a data organization stops asking employees to hunt for the source of truth — and gives domain teams a graph they can join without giving up their systems?
- 1
- Official front door to the data organization
- 3
- Domain teams onboarded at handoff
- 1
- Shared employee entity on the graph
What remained after handoff?
The program was handed off, so Fyve no longer operates it and cannot cite current usage.
Federation also did not replace REST everywhere.
Teams that never joined the graph continued operating their own portals and, in some cases, continued maintaining their own copies of employee-directory data.
The work demonstrated that a better catalog alone would not solve the original problem.
Without modern identity and a graph that teams could realistically join, the organization would have reproduced the same fragmentation behind a cleaner interface.
Likewise, a graph without strong developer experience and shared foundational entities would have remained an architecture diagram rather than an adopted platform.
A platform only works when teams can actually join it
The biggest shift was not replacing REST or launching another portal.
It was creating the foundations that allowed independent domain teams to participate in one shared employee experience without giving up ownership of their systems.
Modern identity made composition possible.
Federation created the shared architecture.
The portal, Atlas, and the shared employee domain showed teams what that architecture could enable in practice.
Your AI strategy needs a platform people can actually use.
We help organizations turn fragmented data, APIs, and internal tools into shared platforms that teams can adopt and build on.
