Composable Architectures to Modernise Your ICT
Most ICT systems were built to be a stable, low cost "monolith", which are extremely difficult and expensive to maintain and change. There are two main alternatives to monoliths: microservice architectures and composable architectures.
A composable architecture is a modular approach where the ICT environment is built from interchangeable, plug-and-play components, including internally developed services (such as microservices) and vendor SaaS products. It promotes flexibility, and strong business-ICT collaboration. It's the best of both worlds.
Download the full white paper (PDF)
A composable architecture is a modular approach where the ICT environment is built from interchangeable, plug-and-play components, including internally developed services (such as microservices) and vendor SaaS products. It promotes flexibility, and strong business-ICT collaboration. It's the best of both worlds.
Download the full white paper (PDF)
The Problem with Monoliths
An ICT "monolith" is a software system built as a single chunk. They are often efficient and low cost to keep exactly as they are. They exist primarily because, before the arrival of cloud Software-as-a-Service (SaaS), integration between services was extremely difficult and expensive, and vendors had no other way to package, install, upgrade, and license to their thousands of users.
Unfortunately, the world around us is constantly changing in a way that is very difficult to avoid. Business needs, security threats, changing vendor support, the evolving talent market and more are all factors that impact our software.
Monoliths were not built to be easily updated or changed to keep up with these factors. They are also very expensive to customise, with many costs coming later. For example, one MXA client paid $7M for a large ERP solution, before spending an additional $40M to customise it. Then, when the ERP vendor had a major upgrade, the client had to spend another $40M to implement the upgrade with their changes.
The final challenge with monoliths comes from testing. The complexity means that few people understand all of the internal workings. This means any change, no matter how small, needs a full end-to-end-test regime to ensure confidence that the change hasn't broken something in another functional area.
Unfortunately, the world around us is constantly changing in a way that is very difficult to avoid. Business needs, security threats, changing vendor support, the evolving talent market and more are all factors that impact our software.
Monoliths were not built to be easily updated or changed to keep up with these factors. They are also very expensive to customise, with many costs coming later. For example, one MXA client paid $7M for a large ERP solution, before spending an additional $40M to customise it. Then, when the ERP vendor had a major upgrade, the client had to spend another $40M to implement the upgrade with their changes.
The final challenge with monoliths comes from testing. The complexity means that few people understand all of the internal workings. This means any change, no matter how small, needs a full end-to-end-test regime to ensure confidence that the change hasn't broken something in another functional area.
Three Approaches to Dealing with Monoliths
The standard approaches to dealing with the challenges of monoliths are:
1. Reactively fund remediation initiatives when challenges become too big to tolerate. Technology laggards have dealt with this by putting their finger over the hole; it works fine provided the holes aren't too big and there aren't many. Unfortunately, the longer they avoid addressing the underlying issues, the more expensive and risky maintenance activities become.
2. Transition to microservices by breaking down the monolith into small, loosely coupled, independently deployable services. This is extremely difficult, owing to the significant increase in capability and dramatically different operating model required.
3. Transition to a composable model by progressively replacing with fit-for-purpose SaaS. This is similar to transitioning to microservices, but with a preference towards utilising vendor SaaS solutions. Build efforts are restricted to specific use-cases with a very strong business case. The challenge is that it needs a very different operating model; one that allows careful selection of SaaS as well as an architectural design that minimises vendor lock-in.
1. Reactively fund remediation initiatives when challenges become too big to tolerate. Technology laggards have dealt with this by putting their finger over the hole; it works fine provided the holes aren't too big and there aren't many. Unfortunately, the longer they avoid addressing the underlying issues, the more expensive and risky maintenance activities become.
2. Transition to microservices by breaking down the monolith into small, loosely coupled, independently deployable services. This is extremely difficult, owing to the significant increase in capability and dramatically different operating model required.
3. Transition to a composable model by progressively replacing with fit-for-purpose SaaS. This is similar to transitioning to microservices, but with a preference towards utilising vendor SaaS solutions. Build efforts are restricted to specific use-cases with a very strong business case. The challenge is that it needs a very different operating model; one that allows careful selection of SaaS as well as an architectural design that minimises vendor lock-in.
Microservices: Benefits But Hard to Implement
A "microservice architecture" is a design approach where applications are built as a collection of small, loosely coupled, independently deployable services, each responsible for a specific piece of business functionality and communicating over standard protocols.
Microservices were designed for high-performance, hyper-scale companies with ample supply of top-tier engineers. They have rarely been adopted effectively by organisations outside of big-tech. Benefits include faster iterations, improved system resilience, optimised resource usage, enhanced maintainability, and increased team efficiency.
However, organisations often fail to gain the benefits when transitioning from monolith to microservices because:
The cultural shift is large: Transitioning requires a cultural change towards agile practices, automation, and team autonomy, which can be difficult for organisations accustomed to monolithic and top-down approaches.
The end-state is complex: Managing many microservices instead of a single monolith is a big step-change in difficulty that many organisations don't have the needed talent or sophisticated technical practices to execute.
The end-state can be expensive: When not managed well, it is common for development staffing, cloud consumption and hidden license costs to balloon, blowing the business case and creating friction between ICT, business, and finance areas.
Microservices were designed for high-performance, hyper-scale companies with ample supply of top-tier engineers. They have rarely been adopted effectively by organisations outside of big-tech. Benefits include faster iterations, improved system resilience, optimised resource usage, enhanced maintainability, and increased team efficiency.
However, organisations often fail to gain the benefits when transitioning from monolith to microservices because:
The cultural shift is large: Transitioning requires a cultural change towards agile practices, automation, and team autonomy, which can be difficult for organisations accustomed to monolithic and top-down approaches.
The end-state is complex: Managing many microservices instead of a single monolith is a big step-change in difficulty that many organisations don't have the needed talent or sophisticated technical practices to execute.
The end-state can be expensive: When not managed well, it is common for development staffing, cloud consumption and hidden license costs to balloon, blowing the business case and creating friction between ICT, business, and finance areas.
Composability: A Compelling Alternative
A composable architecture is a modular approach to system design where the ICT environment is built from interchangeable, plug-and-play components, including internally developed services and externally sourced SaaS products. This enables easy integration, scalability, and adaptability.
Composable architectures differ from microservices mainly by emphasising assembling vendor SaaS products, rather than building your own solutions. Doing this correctly can allow organisations to gain much of the value of a custom solution at a fraction of the cost.
Benefits of Composable Architectures:
- Reduced costs for maintenance or large remediation projects, as SaaS vendors will cover most of this
- Less complexity, as there are "few pieces of the puzzle" to manage
- Best of both worlds; ability to incorporate built applications where it makes sense
- Can be more secure in practice; since large SaaS vendors often have superior talent and greater funds for security management
- Lower requirements for recruiting and retaining expensive engineering talent
- Less management time spent on technology build projects, providing more time to focus on business priorities
Composable architectures differ from microservices mainly by emphasising assembling vendor SaaS products, rather than building your own solutions. Doing this correctly can allow organisations to gain much of the value of a custom solution at a fraction of the cost.
Benefits of Composable Architectures:
- Reduced costs for maintenance or large remediation projects, as SaaS vendors will cover most of this
- Less complexity, as there are "few pieces of the puzzle" to manage
- Best of both worlds; ability to incorporate built applications where it makes sense
- Can be more secure in practice; since large SaaS vendors often have superior talent and greater funds for security management
- Lower requirements for recruiting and retaining expensive engineering talent
- Less management time spent on technology build projects, providing more time to focus on business priorities
Why Composable Has Become Viable
The rise of composable architectures is driven by four factors:
1. Increasingly sophisticated SaaS products: There has been an explosion of high-quality SaaS products providing ready-to-use solutions that can be configured to meet business needs, easily integrated, and scale as an organisation grows. They also come with robust security features and compliance certifications.
2. Advances in integration management: Many modern SaaS providers design their products with an API-first approach, ensuring seamless integration and easier orchestration of services. In addition, there has been a rise in Integration Platforms (e.g., Mulesoft, Workato) that are designed to enable organisations to easily connect and disconnect systems.
3. Frequent technology build failures: Building technology is difficult, often very expensive, and it can be a distraction from your core mission. A study by Boston Consulting Group found that more than 30% of technology development projects experienced cost and schedule overruns, and more than 50% delivered less than satisfactory benefits.
4. Accelerating need for business agility: Business areas expecting faster responsiveness and change from ICT functions. Composable architectures provide a relatively low-cost-and-effort way of responding, by configuring existing SaaS products or quickly replacing them if they cannot meet evolving needs.
1. Increasingly sophisticated SaaS products: There has been an explosion of high-quality SaaS products providing ready-to-use solutions that can be configured to meet business needs, easily integrated, and scale as an organisation grows. They also come with robust security features and compliance certifications.
2. Advances in integration management: Many modern SaaS providers design their products with an API-first approach, ensuring seamless integration and easier orchestration of services. In addition, there has been a rise in Integration Platforms (e.g., Mulesoft, Workato) that are designed to enable organisations to easily connect and disconnect systems.
3. Frequent technology build failures: Building technology is difficult, often very expensive, and it can be a distraction from your core mission. A study by Boston Consulting Group found that more than 30% of technology development projects experienced cost and schedule overruns, and more than 50% delivered less than satisfactory benefits.
4. Accelerating need for business agility: Business areas expecting faster responsiveness and change from ICT functions. Composable architectures provide a relatively low-cost-and-effort way of responding, by configuring existing SaaS products or quickly replacing them if they cannot meet evolving needs.
A Different Operating Model is Required
Success requires a proactive operating model, a strategy and architecture to mitigate vendor lock-in, and increased business-ICT collaboration.
Strong, proactive operating model: ICT must be resourced to be responsive to business needs by proactively understanding the SaaS market and engaging with business areas. Vendors must be managed carefully, since critical business capabilities will be served by vendor solutions. Vendor management resources must have the skill and the teeth to deal with vendors not acting in the organisation's best interest.
Strategy and architecture that maximises agility: Over time, procured software solutions will no longer be the right match. Vendors will implement lock-in strategies to make it challenging to change. To ensure agility, architecture governance and design mechanisms must be aligned to the intent of composability, and technical enablers are required (e.g., modern integration and data platforms).
Increased business-ICT collaboration and empowerment: By making heavy use of SaaS, business and ICT must accept that they are gaining most of the benefit of a custom build at a fraction of the cost. This acceptance means compromises will need to be made. ICT will need to establish clear guardrails and standard patterns to empower business areas to leverage SaaS low-code/no-code capabilities.
Strong, proactive operating model: ICT must be resourced to be responsive to business needs by proactively understanding the SaaS market and engaging with business areas. Vendors must be managed carefully, since critical business capabilities will be served by vendor solutions. Vendor management resources must have the skill and the teeth to deal with vendors not acting in the organisation's best interest.
Strategy and architecture that maximises agility: Over time, procured software solutions will no longer be the right match. Vendors will implement lock-in strategies to make it challenging to change. To ensure agility, architecture governance and design mechanisms must be aligned to the intent of composability, and technical enablers are required (e.g., modern integration and data platforms).
Increased business-ICT collaboration and empowerment: By making heavy use of SaaS, business and ICT must accept that they are gaining most of the benefit of a custom build at a fraction of the cost. This acceptance means compromises will need to be made. ICT will need to establish clear guardrails and standard patterns to empower business areas to leverage SaaS low-code/no-code capabilities.
Implementing a Composable Architecture
Implementing a composable architecture requires initiatives to establish the new operating model across three phases:
Phase 1: Build the Case for Change
- Conduct and ICT audit, including all existing systems, roadmaps, data and contracts
- Develop a business case and recruit sponsors/champions from business and ICT areas
- Leverage the insights from the ICT audit to define cost-saving initiatives that will help pay for the transition
- Communicate the case for change and benefits clearly; anticipate and manage resistance
Phase 2: Establish Firm Foundations
- Uplift business and ICT strategies to support the new direction
- Develop an implementation plan
- Design your new operating model, diverting resources from technology build to procurement, vendor management, architecture, security, integration, and tighter business-ICT processes
- Design your future state business and ICT architecture
- Align with finance on a funding model that shifts emphasis from capital funded projects to predictable operational costs (primarily SaaS licences)
- Upskill people on the new composable architecture approach
Phase 3: Continue to Grow Needed Capabilities
- Resource and operationalise your new critical capabilities; procurement, vendor management, architecture
- Develop a vendor strategy and procurement policy and guardrails
- Procure and implement key ICT enablers, such as an integration platform and data infrastructure
Phase 1: Build the Case for Change
- Conduct and ICT audit, including all existing systems, roadmaps, data and contracts
- Develop a business case and recruit sponsors/champions from business and ICT areas
- Leverage the insights from the ICT audit to define cost-saving initiatives that will help pay for the transition
- Communicate the case for change and benefits clearly; anticipate and manage resistance
Phase 2: Establish Firm Foundations
- Uplift business and ICT strategies to support the new direction
- Develop an implementation plan
- Design your new operating model, diverting resources from technology build to procurement, vendor management, architecture, security, integration, and tighter business-ICT processes
- Design your future state business and ICT architecture
- Align with finance on a funding model that shifts emphasis from capital funded projects to predictable operational costs (primarily SaaS licences)
- Upskill people on the new composable architecture approach
Phase 3: Continue to Grow Needed Capabilities
- Resource and operationalise your new critical capabilities; procurement, vendor management, architecture
- Develop a vendor strategy and procurement policy and guardrails
- Procure and implement key ICT enablers, such as an integration platform and data infrastructure
