A composable architecture is a DIY approach to building a robust architecture using best-of-breed APIs. Composable architectures provide superior user experiences, without all of the work and maintenance of a homebrew system or monolithic solution.
With a composable architecture, teams are able to choose the APIs that best suit their use case, team size, and budget, and connect them together to have all of the functionality that they need, without paying for features they don’t. As those needs change, it is easy to connect or disconnect services, freeing teams from the expensive vendor lock-in of the past.
Teams benefit from the continuous delivery of features and maintenance common to SaaS products, and no longer have to worry about quick fixes of homebrew development or maintaining a critical piece of software over time. Instead, they can be flexible and build the products they want to build with reliable, hassle-free services. To build an effective composable architecture, teams should use a core content hub that manages the flow of data between systems and then connect other best-of-breed services that fit your use case.
#What is the difference between a composable architecture and a monolith?
While you may be asking yourself, how is this different from choosing a legacy, monolith system that has these features out of the box just with more work? Monolith systems are certainly powerful tools; however, they are costly, rigid, and often teams are paying for functionality they do not need or want. When teams are building a generalist tool that can do everything, they are often reflections of digital products of the past rather than the future.
With a composable architecture, teams have the opportunity to choose specialized tools that consider the best practices for their specific use case. Teams are able to build the workflows that they want with exactly the functionality that they need without paying for more. After the core services are chosen and the initial setup is complete, teams will not have to worry about maintaining the services. The team is able to get to work creating the modern digital product that they envision using tools that are intended for that purpose. Monolith systems often consider the world with a web-first outlook. API-first services share the modern understanding of digital products having frontends ranging from mobile applications to smartwatches to smart assistants.
#What possibilities do composable architectures offer?
Composable architectures allow digital products to be flexible and enable teams to work agilely. By working with tooling that was created to be the backbone of innovative solutions to problems, teams are able to have reliable components that match the needs of the team. One of the biggest benefits of composable architectures is that they assume that data may be relevant in several different presentation layers.
Digital experiences are no longer synonymous with web browsers. For example, an eCommerce company may have a website, mobile site, mobile app, smartwatch application, and a personal assistant skill. Avoiding content silos and making sure there is a free flow of information is crucial to building a user experience that is seamless and meets consumer expectations. Composable architectures allow all of these frontends to pull from content from a single content hub, powered by a content federation. With composable architectures, existing monolith systems are not immediately rendered useless. Instead, the valuable data stored in these systems can be fed into the new composable architecture to enrich the content hub and reduce the amount of time needed to migrate all of the data into new systems. With content federation, feeding data into the CMS becomes instantaneous.
#Why should you create your own composable architecture?
Creates more sustainable architecture
Composable architectures are more sustainable than monoliths because of the continuous delivery of features and versions present in API-first SaaS products. Teams no longer have to rebuild their entire infrastructure every time there is a new version. Teams invest time in research and making sure the services they choose are a good fit for their use case and then can rely on these services for years to come.
Removes vendor lock-in
With composable architectures, teams are no longer locked into a single vendor. As teams test new channels, they are able to easily add services to accommodate them. If these services are no longer useful, then they can easily remove them without disrupting other services or channels. This keeps teams flexible and ensures that teams are only paying for services that bring value.
Avoids double work and removes content silos
With content federation, teams are no longer having to manually import the same data to a variety of services over and over again. Instead, the development team populates the data into the content core and then this service distributes it to the frontends and various services. This saves developers precious time and ensures that content is consistent across platforms.
Keeps teams agile and experimental
Because teams no longer have to worry about architecture maintenance or migrating large sets of data to a wide range of services every time they want to try a new idea, teams are able to be experimental. Testing new channels or adding functionality is all possible with a composable architecture. Developers will be excited to take on new projects and build rather than having to spend time on architecture maintenance.
#What should teams consider when building their own composable architectures?
Start simple
When building a composable architecture, choose the most critical systems first and begin building an MVP with them. This will help teams determine what functionality they are lacking or if there are other features needed that they did not initially anticipate. If you are building an eCommerce site, starting with the payments, PIM and CMS could be a good place to start. For a marketing site, the CMS, support, frontend software are some of the essential services.
Invest time during the evaluation to save work later
The time spent during the planning and evaluation phase will not be lost. Understanding how services will work together can save time in the long run and help make sure that the essential elements are well chosen. The content core is the most critical here as not all CMSs are created equal. Content federation is a unique attribute that can be critical to creating a seamless composable architecture.
Choose tools that have a strong community supporting them
Tools that have a stronger community will continue to develop and evolve. They run less of a risk of petering out because of slow adoption and will continue to deliver features. Tools with strong communities will have better networks for support and problem solving should the need arise. When considering how to build sustainable composable architectures, strong community support can be a good indicator of tools sticking around for the long haul.
To explore best of breed APIs that contribute towards building resilient architectures over time, explore our curation at Build Your DXP.
#Frequently Asked Questions (FAQ)
What are content silos?
Content silos are pieces of data that do not communicate with other systems within the larger tech stack. In making content inaccessible to other systems, editors may have to manually re-enter data. Content silos can be a bi-product of systems not being properly connected to one another to ensure a free flow of information, or they can be intentional as a way to increase security of certain data.
What is composable architecture?
Composable architectures are architectures driven by API-first products that are built modularly and light-weight. Composable architectures should make it easy to test and experiment with services without disrupting the core functionality. As team’s needs change composable architectures make it easy to adapt.
What are agile workflows?
Agile workflows are project management workflows that are intended to keep teams working efficiently and productive. Agile workflows often stem from agile methodology such as Scrum or Kanban which have different approaches to breaking down a project into smaller pieces and setting broader deadlines for the modularized projects. Iteration of projects is also a key element to agile methodology.
What are API-first SaaS products?
API-first SaaS products are services that are connected to other services via API. They are specialized services that when connected together can create a powerful modular DXP. API-first systems can reduce the cost of developing apps, increase the speed to market, and enable a custom tech stack without the custom development times.
What is content federation?
Content federation is pulling content from several sources programmatically to enrich your Hygraph data. Content federation reduces architecture complexity, removes redundant copies of data, and enriches content programmatically. With content federation, teams are able to leverage their existing services while modernizing their stacks without a large overhaul. For more on content federation, take a look at our content federation blog post.
Blog Author