Taking a Platform Approach to Application Development
How to break down silos and build integrated applications at scale
If you’re an engineer at a company that has undergone rapid transformation, you’re likely to have come across an unintended side-effect of growth: organizational and product silos. Left unchecked, these silos can influence the way you build applications and inhibit your ability to integrate experiences and functionality across applications.
In this post, we’ll share with you how Q4’s engineering team overcame this challenge using Platform Architecture.
“Platform architectures are modularizations of complex systems in which certain components (the platform itself) remain stable, while others (the complements) are encouraged to vary in cross-section or over time.”
Prior to going public several months ago, we were in the early stages of building a new offering, Capital Connect. This ambitious new product aimed to unify our customers’ experience by integrating functionality and data across traditionally siloed products and business domains. This broke our pre-existing model for building applications and forced us to re-architect how we build applications going forward.
We decided to break down the silos by taking a platform approach to creating an enterprise system that would enable us to build highly integrated products and services, while also introducing efficiencies in how we build them. We shifted our mindset from “building for the application” to “building for the enterprise.”
What did we want to achieve?
While there’s no one-size-fits-all approach to platform design, our goal was two-fold: both to solve technical challenges and to use architecture to solve functional problems as well. To maintain focus and guide our approach, we set out five objectives:
- Enable the integration of functionality and data across multiple products and business domains
- Build an ecosystem of domain and functional services that could be used across the enterprise
- Provide value across domains as growing business capabilities are introduced to the Platform
- Improve efficiency, allowing teams to focus on building products by providing the underlying infrastructure and services to build upon
- Enable teams to work independently, with their own roadmap and release cycle, while still contributing to a single application
How we did it
We needed a new pattern of building applications, but we couldn’t let pre-existing practices and organizational structure influence the direction of any potential solution. We needed to focus solely on the problem and how we could use architecture to solve it. The practices and organizational structure to support the new system would be influenced by the design.
Tip: Stress test your design by inviting stakeholders from across the company to review and run use-cases against it. Some of the best feedback can come from non-technical teams including product and design.
Inspired by Domain-Driven Design, we wanted to design a platform where the components of the system are domain-focused and can evolve over time without impacting the system as a whole. While this pattern is prevalent in microservices, we wanted to extend it to the full vertical slice of our application architecture, including front-end, API, and data.
The solution
The diagram below illustrates the layers and components that make up our platform. We won’t touch on all the components of the platform in this post. Instead, we’ll focus on domain-owned and related services. The interfaces between components allow the platform to evolve; as new technologies emerge, components can be replaced provided the interface remains intact.
Front end
We chose to leverage micro front-end architecture where the front-end is broken down into smaller independently built and deployed bundles of code, owned by the domain. These pieces together form a single application. This architecture allows teams to build, test and deploy front-ends without any dependencies on other teams or the need to coordinate cross-team deployments. The micro front-ends are loaded at run-time instead of build-time, decoupling the front-ends from the build process of the main shell application. This allows for the continual evolution of components without the need of deploying the shell application. To achieve this, we leveraged Webpack Module Federation. Module Federation made it easy for us to build and export remote modules that could be asynchronously imported into the shell application.
Building micro front-ends in a decoupled environment has its challenges, however. Engineers, QA and Product still need the ability to preview, interact and test these micro front-ends before integrating them into the shell application. Without these decoupled components being embedded in any kind of webpage, this posed a challenge. To help with this, we utilized Storybook. Storybook acts as a component library for our micro front-ends. As front-ends are developed, they can be previewed in real-time via hot reloading. Having this component library has helped provide transparency to teams and stakeholders, giving them a central destination to access and preview the latest components.
Enterprise services
The Enterprise Services layer was one of the biggest transformations for us. We were accustomed to building API’s to meet the needs of individual products, rather than building domain-focused services for the enterprise that could be used across any product in the future.
We divided our Enterprise Services into two categories:
- Enterprise Domain Services (EDS)
These decoupled, domain-owned micro-services provide units of business functionality and data across the enterprise. - Enterprise Core Services (ECS)
These micro-services provide core functional capabilities to the enterprise, such as notifications or account management.
Tip: Build for the enterprise, not the product! By building for the enterprise, these capabilities are available across the organization to leverage, outside of any silos. As products evolve and get re-packaged, the core capabilities that support these products remain intact.
The Q4 Graph
We use GraphQL as the interface for our Enterprise Domain Services (EDS). Each EDS implements its own nodes and corresponding GraphQL schema (subgraph). Using Apollo Federation, we’re able to combine these subgraphs into a larger graph we call Q4 Graph. Having a single graph to query provides us with a single entry point to access all the functionality and data from our EDS. Accessing data from multiple domains is now possible, in a single request, allowing for tighter integration of functionality and data across traditionally siloed domains.
The Q4 Graph is accessed through a service we call EDS Gateway. This service is responsible for routing requests to the underlying Enterprise Domain Services.
Data
Our data layer was typically handled by a single team in the past. This created dependencies on external teams and required sequencing of work and releases. We wanted teams to own the full vertical integration, including data. Teams would now be responsible for implementing any necessary views needed to support their domain, alleviating any dependencies on other teams.
A new approach to working
This new architecture changed both how we work and how we structure our teams. The majority of our teams are now domain-focused, building functionality and data to support a specific domain. Because the scope of the domain is much more focused and decoupled from other domains, teams are able to execute and deliver faster and more effectively.
If you’re facing challenges with siloed and disconnected products, you’re not alone. We hope this post has inspired you to consider taking a platform approach to move forward as a united organization, staying connected as you grow and transform.
Stay tuned for more posts from Q4’s architecture and engineering teams. We’re doing lots of exciting things and look forward to sharing our experiences with you. If you have any topics you’d like us to cover, please let us know in the comments below.
