Composable architecture is a design approach that allows for the flexible and modular assembly of software or hardware components to create customizable and scalable solutions.
Embracing its adoption accelerates innovation in today's dynamic landscape and enables organizations to leverage the best tools for various tasks, enhancing user experiences. However, transitioning away from traditional workflows can seem challenging.
This article gathers insights from industry experts to help you on this exciting journey.
1. Select the Right Technologies for Each Layer
Choosing technologies that align with your requirements is always essential, especially when transitioning to composable architecture. This approach involves selecting specific tools for different layers of your system, such as a Content Management System (CMS) for content, a Customer Data Platform (CDP) for decision-making, and a distinct data layer, explains Brian Graves, Vice President of Engineering at digital consultancy Forum One.
He says that neglecting the importance of the decision or orchestration layer, which manages interactions between front-end and back-end services, is a common pitfall. “This layer handles complexity, including caching, access control, and security. Ineffective communication and content caching can lead to challenges in a composable architecture.”
Adapting to this shift may be challenging, primarily if your team comprises non-full-stack developers or experts in different technology stacks. Graves stresses ensuring the right team members possess the necessary skills and clarify roles in the new stack. In this modern era, developers can thrive by honing their expertise in JavaScript, as these skills serve as the glue that connects various components.
It's also important to consider the organization of software functionality into separate modules that can operate independently, seamlessly integrate, and whose appearance can be easily customized without touching the underlying functionality. This involves creating reusable components, like UI atoms, molecules, and so forth, with code best practices backed in and appearance decoupled from logic behavior. Many OEMs are investing in this as part of their "platform engineering” effort as it provides an efficient and effective way of developing different products, models, and even across brands.
2. Balance Composability with Business Relevance
“One misconception is that a composable architecture can solve everything,” observes Eberhard Wolff, a business and technology consultant and Head of Architecture at SWAGLab. “By implementing composability without grasping the business context, you risk building flexibility and composability in the wrong areas. When you adopt a new approach, deviating from established practices demands substantial effort and investment. You must focus on where to implement these changes and be prepared to explain why.”
He adds that technical people often need to pay more attention to business drivers. “They invest effort in explaining technical choices but fail to ascertain the systems' business value. Understanding the business strategy and how it translates to your software landscape is core. The primary challenge in IT is achieving greater business impact and efficiency, not merely churning out lines of code.”
Wolff continues, “Composable architecture is not a silver bullet that takes you to the next level of productivity. It's not something you can purchase off the shelf and expect immediate results; it often entails a fundamental shift. It is imperative to establish how IT can best support the business, and this necessitates involving business stakeholders in the decision-making process.”
3. Embracing Incremental Progress with Composable Architecture
“In my view, a composable architecture, which aligns with the principles of MACH (Microservices, API-first, Cloud-native, and Headless), signifies a step in the right direction, even if you're transitioning from an on-premises infrastructure to the cloud,” resumes Graves. While this alone doesn't fully achieve composability, it does represent progress.
He has seen many developers mistakenly believe embracing composability requires rebuilding the entire stack from the ground up. “It's crucial to understand that the essence of a composable architecture allows for incremental progress rather than starting anew with a blank slate and saying, ‘Let's burn everything down and start up a whole new thing.’”
If you come from a world where you're building websites relying on coupled CMS, you tend to depend heavily on pre-built templates, tools, and systems handed to you out of the box. He advises utilizing libraries or open-source design systems to help reduce costs when striving for a more tailored approach.
4. Master the Signal and Slot Mechanism
Modularity and composability are at the very heart of Qt and appear in various use cases. One particularly fascinating and unique example is the signal and slot mechanism. By fostering loose coupling and seamless communication between different application segments, it enables components to interact harmoniously without direct dependencies.
According to Matteo Capelletti, Product Marketing Manager at Qt, signals and slots function like maestros conducting an orchestra: “In a service-oriented architecture (SOA), signals and slots minimize knowledge dependency between objects. An emitting object doesn't need intricate knowledge of the receiving object. Instead, the receiving object only needs to be aware of its connected signal.”
This decoupling ensures that changes or modifications in one part of the system won't disrupt or impact other components. By following the principles of composable architecture and leveraging signals and slots, your application gains a significant advantage – the ability to adapt and evolve quickly.
“Invest time in understanding the opportunities of signals and slots and explore ways to customize this powerful communication mechanism. Stay updated with best practices and evolving features to ensure your composable architectures remain robust and adaptable,” advises Capelletti.
5. Prioritize Collaboration in Software Architecture
“The reason we do software architecture is humans,” underlines Wolff. “We must structure complex landscapes and software systems to allow people to understand them. The architecture must be adjusted to those working on it. If you hand a system over to a new team, they will encounter difficulties maintaining it because it's not something to which they are accustomed. Therefore, labeling architecture as good or bad makes little sense; its effectiveness depends on the people working with it.”
In software architecture, the emphasis should be on fostering collaboration, particularly in composable architecture, which requires a closer partnership between business and technical experts. It demands active communication and a transformation of the company's culture.
He ends by saying, “The rationale behind our pursuit of software architecture lies in the number of individuals involved in system development. We require a structured approach emphasizing collaboration, communication, and a shift in organizational culture.”
