What Makes Composable Projects Successful?
Introduction
This article provides my personal perspectives regarding factors that lead to the success or failure of composable software solutions. If you have questions or suggestions, please comment on this article.
Strategy and Long-Term Thinking
Composable requires commitment. Migrating to composable architecture should be part of an overall digital progression strategy rather than a decision made due to industry trends without understanding the implications. Some organizations may not have the skills, experience, requirements, or other elements sufficient to justify a long-term investment in this paradigm shift. Simple solutions, such as brochureware sites with no integration, may be better served by legacy technologies.
Effective Project Management
Regardless of the methodology used, any significant technical undertaking requires competent project management. This consideration affects every issue described in this article.
In fact, project management is not the right term. Composable solutions tend to be programs that survive for the lifetime of the organization, not projects that have a specific completion date. Organizations can break solutions down into projects that can be scheduled, managed, and implemented independently.
Clearly Defined Requirements
While it’s always possible to enhance a solution, it’s not possible to implement efficiently without a thorough understanding of requirements. If you know what you need to build, you can select appropriate tools and invest in optimal solution architecture from the outset. Under these circumstances, implementation should be relatively straightforward.
From my perspective, requirements analysis should be 50% or more of a project’s lifecycle, less as we move towards low-code solutions. While it is a necessary evil best minimized, there will always be custom code in any solution that is even slightly complex. There are too many reasons not to use simple solutions for website management.
Proper Solution Architecture
While composable software architecture may be the best option for solutions of any complexity, it’s quite possible to implement solution architecture that defeats the objectives of this entire approach. The topic of solution architecture is not within the scope of this article but is the reason that I joined Conscia. Service buses provide a partial alternative to orchestration, but I see these technologies working together – the Digital Experience Orchestration engine can interface with the service bus where appropriate.
Diligent Vendor Selection
When an organization is in a rush to build something, it faces pressures to select vendors without a complete understanding of requirements, let alone analyzing vendor offerings against those criteria. This goes back to strategic thinking: an organization should never make long-term decisions in a rush or an information vacuum. Vendors that provide misleading or even false information compound this challenge for the customer.
We talk about composable solutions being compostable in that an organization can replace components such as CMS and Commerce in their composable stacks. Of course, such changes would take significant effort, including code updates, data migration, user training, and otherwise. This is one reason that it’s important to apply proper architecture and to confirm with best practices for implementation. Otherwise, the composable software stack is likely to topple under its own weight.
While quality technology offerings are one key to success, it is not the only reason to select a vendor. Support and human relationships are critical. Get a feel for an organization by working with its people before buying, whether by going through an internal Proof of Concept project or paying the vendor to assist with a Minimum Viable Product implementation.
Realistic Expectations
User acceptance is a major factor in the success of a project. User acceptance is higher when users begin with proper expectations. If users are involved in product selection, vendors can set their expectations beyond what is possible with the available resources and within the intended timeline. Trying to do too much at once is a recipe for disaster.
This applies at the executive and managerial levels as well. From the outset, an organization needs to know what it’s getting into, what it will get, and what it will need to invest. Surprises in any of these aspects are almost never a good thing.
Rather than expecting every possible feature, organizations should set realistic expectations for users and focus on Minimum Viable Product (MVP), scheduling additional project phases to deliver functionality with less immediate need.
Talented and Coordinated Implementation Team
It will always take incredibly smart and experienced people working in coordinated teams to implement solutions of any significance. My perspective is that most organizations should not need staff with these traits. For example, a company that sells tractors should not need expertise in experience management. Since most organizations have relatively few relevant projects, they cannot possibly have the background required to develop sufficient strategy and delivery optimal solutions.
Most organizations would likely benefit from working with partners, not just for implementation, but for strategy definition and refinement as well. This allows outside perspectives that prevent the myopia that can result from working within a single organization for a long period of time.
Adherence to Best Practices
Of course, any project should apply best practices. Unfortunately, the composable software industry is only beginning to define these characteristics. I previously posted by suggestions here:
Practical Investment
Regardless of what vendors might project, especially salespeople working for vendors, nothing is free, and if it’s cheap, it’s probably not worth much. Organizations need to recognize the need to invest significantly in composable solution architecture and budget accordingly.
Solution Documentation
Composable solutions, especially without orchestration, can be incredibly complex. Implementing a composable solution requires documentation from the vendors, not just in terms of what parameters and JSON formats for Webservice API calls and Webhooks, but for architectural patterns and specific use cases.
Additionally, organizations should develop internal documentation sufficient to troubleshoot, support, and maintain their implementations.
Conclusion
Composable software architecture represents the foreseeable future of enterprise solutions. While there are challenges, especially for an organization’s first project, understanding the factors that lead to success and applying best practices will lead to greater value and agility at less cost in the long term.
I will maintain a copy of this post at