Case Study

Syneos Health

Complex monolithic system refactor & GraphQL API development

In a market short in GraphQL expertise, Xolvio not only showed us exactly how to build our supergraph but also refactored our monolithic system in just three months.

Will Rigby, Senior VP of Engineering, Syneos Health

Supergraph-powered Customer Experience

Syneos Health is a leading provider of clinical trial recruitment and retention technologies connecting patients, sites, and sponsors. However, their monolithic system architecture was increasingly hampering engineering productivity. Syneos Health turned to GraphQL with the aim of decoupling backend from frontend for greater user experience agility.

Looking to support their GraphQL efforts, the company enlisted Xolvio, the official Apollo GraphQL professional services partner, to evaluate its GraphQL practice and to make recommendations for proper design and implementation of a federated Supergraph architecture. Following this assessment, Xolvio refactored Syneos Health’s monolith in three months and built a federated GraphQL API on top of it to supercharge innovation.

As a result of the engagement, Syneos Health skyrocketed their ability to iterate on new features, consequently accelerating a new product launch by a full quarter.

The Challenge

Highly coupled, complex monolith

As Syneos Health’s monolithic system grew in complexity over the years, it became increasingly difficult to maintain. A high degree of coupling, especially around some entities, meant that new feature development required careful attention to many different parts of the system. This became particularly problematic for evolving customer experience, which led to Syneos Health introducing GraphQL to their tech stack, with the aim of decoupling backend from frontend.

However, the monolithic system’s complexity made GraphQL schema design difficult and posed the risk of maintaining one giant GraphQL server. Consequently, a refactor of the monolith seemed inevitable. Syneos Health’s challenge was then threefold: to plan out a new, distributed, microservices architecture; to execute the refactor in a safe and controlled fashion; and to create a federated GraphQL schema to match the new architecture.

The Solution

Domain-Driven Design for both system refactor & API development

Our engagement with StudyKIK began with Apollo GraphQL consulting. Over a period of two weeks, our team interviewed key product and engineering stakeholders, conducted event storming workshops, and analyzed the gathered information to produce a set of targeted recommendations and a roadmap to follow. Trusting our expertise, Syneos Healththen tasked us with refactoring their system and revamping their GraphQL journey by designing and implementing an Apollo supergraph.

Event Storming

This highly effective workshop technique allowed us to quickly model Syneos Health’s business domains from a high level by extracting tacit knowledge from the relevant stakeholders and making it visible on a virtual whiteboard. Then, we dug deeper to document the relevant business processes in more detail, before using the modeled processes for software design and development.

Bounded Contexts

In Domain-Driven Design, a bounded context is defined as a boundary of language consistency. These domain boundaries emerged from the Event Storming workshops and allowed us to define the new, distributed architecture in terms of modules. Later, we applied this domain-driven approach to GraphQL schema design, as bounded contexts naturally map to subgraphs in a supergraph.

Refactor

Armed with initial bounded contexts and a detailed understanding of StudyKIK’s business domains, we began the refactor in a stepwise fashion, creating a mixture of code repositories and microservices. In order to ensure great scalability, reliability and performance benefits, we applied an event-driven architecture with a message broker enabling decoupled communication between the different modules.

Digital Experience Integration

In parallel to the refactor, we laid the foundations for StudyKIK’s GraphQL API by designing and implementing a federated GraphQL schema. We focused on current data demands on the client side, so that the GraphQL API could provide the correspondent supply through the appropriate subgraphs of the supergraph. This demand-driven approach allowed us to quickly build a fully operational API, ready to be expanded as per StudyKIK’s roadmap.

Creating demand for the e-tron

Apart from the basic reservation taking functionality, the platform was meant to create marketing buzz around the e-tron car. Audi’s team devised features that created demand for the new car, which in turn immensely increased the solution’s complexity.

High performance requirements

The reservation system had to be capable of processing thousands of reservations per minute to meet the expected demand for the e-tron car sales. This furthered the need for the solution to be of as high quality as possible.

Breakneck deadline

For various reasons, not least because of complications that can occur within a large enterprise software project, Audi was left with only around 4 months to prepare the reservation system for the product launch.

The Outcome

CX delivery transformation and roadmap acceleration

When we started our engagement with StudyKIK, their engineering organization was wrestling with a highly complex monolithic system that hampered their ability to improve on customer experience. Three and a half months later, they could boast a brand new, refactored, event-driven, distributed system with a federated GraphQL API on top. Apart from these hard deliverables, we armed StudyKIK teams with knowledge, skills, and best practices to continue growing both their system and the API. As a result, StudyKIK was able to accelerate their roadmap and moved an upcoming product launch by a full quarter.

More case studies

Close