App & Data Integration 12 mins read

Architecting for change: The power of composability

As business evolves, IT must adapt. But change is disruptive, costly and time-consuming. Can we design IT systems for easy adaptation?

Matthias Biehl Matthias Biehl

Now, more than ever, businesses need to navigate uncertainty and rapidly adapt to evolving economic conditions—consider the impact of recent events such as the pandemic, disruptions in supply chains, and the widespread use of AI. As the pace of change accelerates, organizations must innovate and quickly adapt their IT systems to changing business needs.  

And as the pace of change accelerates, many architects may have wished they could keep up with the changes by assembling, reassembling and extending their IT systems as effortlessly as Lego building blocks. Composable Business Architecture realizes this vision by applying a couple of architectural principles, including modularity, composability and reusability. Embracing these principles empowers organizations to make strategic architectural choices that prioritize much-needed flexibility, agility and adaptability. 

While these benefits can be achieved conceptually with a Composable Business Architecture, as any practitioner knows— nice concepts are not enough to make it work in real-world environments. In practice, there can be many challenges to establishing a composable architecture: multi-cloud environments, hybrid cloud and on-prem environments, business IT teams vs. corporate IT teams, and lack of governance.  

In this situation, you need all the support you can get, from platforms, infrastructure and technology to make the composable architecture a reality. 

Let’s delve into these principles, explore the best practices for their implementation, and discuss how to integrate them into an organization’s framework using APIs, integration technologies, and marketplaces.

Change is the new normal

Economic uncertainty has been rising over the last years as businesses struggled with many external, unforeseeable events, such as a pandemic, supply chain shortages, de-globalization, wars, energy crisis, skill scarcity, inflation and climate change. While you don’t know exactly what will happen next, the uncertainty is rising. 

The first step is to react to changes as they arise. Businesses strive to adapt to these external changes, which will require changes in all domains, including their IT systems. In the past, changes to IT systems were hard, because IT systems were rigid, and actually hard to change, thus hindering businesses from adapting much faster. 

The second step is to not only be reactive, but to prepare for change. And it starts with the realization that “Successful software always gets changed”, as Prof. Frederick P. Brooks said, who is known for his book The mythical man month. This is truer today than ever—and it is evident to everyone working with software. However, dealing with this change, unfortunately, is quite hard if you have a rigid software architecture. 

Since change has become so commonplace, it would be an illusion to attempt to build rigid IT systems, pretending that they will remain unchanged for decades to come. Forward looking businesses not only react but prepare for change. 

But preparing for change is not as easy as it sounds. The complication is that you cannot prepare for only a single scenario; instead, you need to prepare systemically for whatever comes and for many possible scenarios so you have options and can react to change. Being prepared for change means avoiding any kind of rigidity and focusing on flexibility, so you can adapt the system without too much pain.

Is your system architecture resisting change?

What is important when the storm of change approaches?  

In nature, trees can break in a storm, but bamboo will persist. The difference? The tree is rigid, but bamboo is flexible, which helps deal with strong and shifting winds. 

In our architecture, we should avoid rigidity and instead focus on creating flexibility. The challenge lies in the level of flexibility, as we do not want it to turn to chaos. 

Flexibility is key to deal with change effectively. So how can you build IT systems that are as flexible as bamboo? Building systems that are easy to change needs to become a requirement from the start for all the systems that are built. Dealing with change becomes easier with composable architectures that exhibit inherent flexibility. 

Principles for flexibility and dealing with change

There are several principles that lead to more flexible architectures: Modularity and composability, scalability of the cloud, and democratization of digital solutions 

The goal should be creating flexible systems, that can be more easily adapted to changing business needs. 

  • How should you decompose the system?  
    The Lego principles modularity, composability and reusability are key for creating more flexible systems, as we know from the work of D. L. Parnas. You focus on creating modules with high internal high cohesion and composing them in a lightweight fashion, i.e. with weak coupling. Nowadays, you represent the modules in the form of APIs, events and data, using the same decomposition principles. You turn your system into a collection of Lego blocks.  
  • How should you organize the work?  
    Democratizing the work and allowing Business-IT teams to create digital solutions. AI plays a big part in democratization. At the same time, governance needs to be in place to provide guardrails and limit complexity. Ideally your development platform will provide UIs which cater to both non-technical users and specialists, to optimize collaboration and efficiency. 
  • On which platforms should the system run?  
    Cloud-based platforms and architectures are ideal for flexibility. Scalability is an important aspect of flexibility, and that is best achieved in the cloud. At the same time, some components may be better deployed close to the source of data in local regions or on-prem for fulfilling special non-functional requirements. Overall, this results for many in a hybrid architecture. 
  • Which tools should you use?  
    Building composable architecture can be difficult—but don’t make it more difficult than it has to be. Use the right tools that help you achieve outcomes quicker, easier and more reliable. You can speed up the process with an integration platform that provides all three technologies in an architecture designed for complex hybrid environments and multiple types of users known as a  Super iPaaS

Let’s see how we can put these principles into action and build more flexible architecture. 

The Lego Principle: Modularity, composability and reusability

Modern enterprise IT landscapes have grown organically to become heterogenous. They typically comprise an assortment of applications in the cloud and on premises, SaaS, vendor-provided applications, custom-developed applications and legacy applications running on mainframes.  

To provide flexibility, the data and functionality in this system landscape needs to be made accessible as modules, typically in the form of APIs. Most SaaS products already come with APIs, either as API-first or headless API products. For custom-developed or legacy applications you typically need to create your APIs. A Super iPaaS platform helps you create these APIs with a standard RESTful interface at the front and a custom connection on the backend that fits the technology stack of your custom or legacy applications.   

Once your system landscape is (partially) covered with APIs, you may end up with many APIs. The design of these APIs, including observability and security, needs to be governed to ensure the integrity of the solutions that are built with them. A Super iPaaS platform with its built-in API management functionality helps to keep an overview of the various APIs, wherever they are located, helps to operate, maintain and govern them according to a common set of quality guidelines. 

Composable architecture turns the system landscape into a platform that your IT teams can build on, to customize, personalize automate workflows. And this platform has at least 3 personas that operate on and in it: 

  • API Developer: Creates APIs and provides them as building blocks on the platform. This persona expects self-service from the platform.  
  • API Consumer: Focused on solving a particular business demand with IT. Finding the right APIs and composing them as quickly as possible. Maybe graphically and even with the help of AI. You need the ability to compose the building blocks in an easy and straightforward manner.  
  • Platform Operator: Runs the platform infrastructure and a marketplace with self service capabilities, focused on governance, smoothens the interaction between Corporate IT departments typically take on the role of platform operators and API developers, whereas business IT teams have the role of API consumers. This goes hand in hand with the principle of democratization. 

Democratization of access to data and capabilities

IT solutions and integrations used to be created by a central corporate IT. However, they were far removed from the various business functions and their needs, and often a bottleneck for requests originating from business functions all over the enterprise.  

More and more, IT teams within the business units are established and enabled to take on the digitization projects of the business. Gone are the days when IT functions within business units were called “shadow IT”. The new mindset is “all hands on deck”, and it is required to manage change. The advantage of business IT lies in the closer alignment with the business, shorter feedback cycles, and more specific domain knowledge in the IT team. As a result, Business IT can do a better job providing digital innovations, quick turnaround times and more autonomy. 

But the system still needs to be safe, secure and performative—a function typically taken care of by Corporate IT. Collaboration between Business IT and Corporate IT is required. A typical split of responsibility is: 

  • Corporate IT typically provides a safe platform for Business IT to innovate by means of guardrails, constraints and governance, and  
  • Business IT uses the platform to innovate and cater to the specific needs of their business function.  

While Business IT typically works on top of the platform, Corporate IT runs the platform. Some enterprises even operate fusion teams, where Corporate IT and Business IT collaborate in a DevOps model. 

A Super iPaaS is the safe platform for Business IT to quickly and safely build integrations that can be easily run and operated by Corporate IT. With a visual representation, predefined connectors and AI-support Business IT can reach its goals quickly. Corporate IT operates the Super iPaaS platform, ensures seamless connectivity to cloud and on prem resources, curates the available connectors, and watches out for IT security.

Embracing the cloud

Most organizations move parts of their system landscape to the cloud to take advantage of the cloud’s scalability and elasticity. But the cloud is not a uniform place; multiple vendors and types of offers are used, often as a strategic choice to achieve some level of independence from a specific cloud provider.  

This results in a hybrid landscape—where some systems are on premises, some in the cloud and where multiple cloud providers and cloud offerings are used. In this scenario, flexibility is a plus. Systems might be moved to a different cloud provider, from on-prem to the cloud or very selectively from the cloud to the edge. 

On top of that, global organizations need to comply with data governance requirements, where data can only be stored and processed in certain jurisdictions and their appropriate cloud regions. Global organizations typically need to deploy functionality to cloud centers in various jurisdictions. 

Two types of challenges arise in modern cloud environments: 

  • You need to separately develop for the various deployment scenarios in multiple clouds, regions and on prem.  
  • From an operational perspective, you need to maintain an overview over the deployed APIs and integrations—no matter where they are deployed. Each cloud provider might provide a control plane, but that only covers the elements in the respective cloud, and misses out on deployments on other cloud providers and on prem. 

If these challenges are not taken care of, there is a risk that the advantages of cloud such as scalability and elasticity get overshadowed by additional complexity. To deal with these challenges, a Super iPaaS provides: 

  • An independent control plane spans the APIs and integrations on all your deployment targets, no matter which cloud provider it is deployed on. This makes multi-cloud a feasible choice. 
  • The possibility to develop once-publish anywhere, giving you back the flexibility in the of cloud.   

As a Super iPaaS provides these two capabilities, the control plane and the develop once-publish anywhere features, it helps making hybrid setups and multi-cloud environments a manageable platform for composable architectures.

Accidental complexity: Using the wrong tools for Composable Architecture

By using the wrong approaches for dealing with change, you tend to introduce accidental complexity—in addition to the essential complexity. Essential complexity is inherent to/in the problem and the business domain and its processes. Accidental complexity arises when you use the wrong tools to solve a problem. Using a hammer to chop down a tree will introduce accidental complexity—so is using the wrong APIs, API management, and integration platform for creating IT solutions. 

webMethods.io. iPaaS helps you avoid accidental complexity and is a basis for composable business architecture. 

While change and disruption can be threatening, it only becomes a problem when met with rigidity—or a rigid system structure. By following the principles of the composable business architecture, you gain the flexibility to effectively deal with the high pace of change. You turn change into your ally, into an opportunity for more innovation and fuel for future growth.