In recent years there has been a constant stream of software architecture movements: microservices, API-led connectivity, event driven architecture, composable enterprise, automation, and data mesh. We’re going to address how these trends can be positioned in a broader innovation strategy.
How is composability considered the “future” of innovation?
Innovation is top-of-mind, and businesses seek opportunities to increase customer, partner, and employee experiences. But they have to do that in labor shortages and economic headwinds. That requires organizations to do more with less.
Delivering great experiences will require creating complex solutions. Starting from scratch each time we need to create such a complex solution is too costly and too slow. New solutions need to be built using components that have been tried and tested before. That’s the essence of Gall’s law: All complex systems that work evolved from simpler systems that worked.
Now, let’s examine complexity.
Essential and accidental complexity
Many organizations have a goal to simplify their processes, applications or IT landscape. That is possible, but up to a point. The world is complex. As a consequence, the solutions that need to be created are likely to be complex as well.
That’s essential complexity: complexity caused by the problem at hand. It will be hard to reduce essential complexity. What can be reduced is accidental complexity: the complexity we have introduced ourselves. Examples would be big, poorly documented monolithic applications, spaghetti code, the big ball of mud.
That is why there is a constant stream of new technologies or approaches that seek to minimize accidental complexity. In most cases the goal of these new approaches is to reduce complexity by creating smaller, loosely coupled building blocks.
Let’s look at some of these technologies.
Building-block technologies
After service-oriented architecture (SOA) was proclaimed dead, microservices were introduced, event driven architecture, RESTful APIs, and GraphQL, just to name a few. A fairly recent trend is data mesh. Data mesh aims to break down the centralized, monolithic analytics world into composable building blocks as well.
The potential benefits are clear: independent building blocks allow you to innovate quickly and at scale.
In actual practice, there are some risks. Some businesses apply the new technologies solely in their innovation teams, almost ignoring the fact that these innovations need to integrate to the rest of the org. The assumption that adopting a single approach or a single technology would be a sustainable solution to all problems. CV-driven development is adopting technology because it looks good on your CV, not because it necessarily is the best solution to the problem.
People, process, and technology
MuleSoft is convinced that technology is just one of the three factors determining success; to drive agility at scale, you also need a consistent methodology and a set of people that drive the correct adoption of the new technology and the new approach.
MuleSoft introduced API-led connectivity to stimulate reuse through architectural consistency and advocated for a design first approach to better align consumers and producers of digital building blocks.
Gartner added to these concepts by introducing the composable enterprise. Making organizations more agile by creating Packaged Business Capabilities that could easily be combined and recombined to create new customer experiences.
Gartner also introduced the concept of hyperautomation. The aim of hyperautomation is to automate as much as possible to increase efficiency. Through a combination of pro-code, low-code and no-code tools a larger group of people can contribute to automation. An important factor to introduce low-code and no-code tools is the fact that there are only about 22 million pro-code developers. At the same time, there are at least a billion knowledge workers that are perfectly capable of building solutions that IT doesn’t have the bandwidth for.
From projects to products
When looking at these trends and technologies there are similarities. To be more agile, orgs will need a variety of building blocks that will be deployed across multiple clouds and platforms. A diverse persona will play a role in creating these building blocks.
To be agile at scale, these building blocks will need ownership, consistent builds and design, to be discoverable for reuse, and to be secure and monitored.
That is where the concept of digital products comes in. The building blocks that are created should be managed as products. This concept is one of the foundations for the microservices world; in BizDevOps small teams of business, developers and operations people own the complete lifecycle of a microservice.
In the context of the composable enterprise, Gartner calls these teams fusion teams. Fusion teams own the complete lifecycle of packaged business capabilities. In the data mesh world, these teams are called data mesh domain teams. Again, these teams own the complete lifecycle of a data product.
These products will still be created in projects, but with broader use in mind. The result will be a multitude of different types of building blocks that are managed as products.
The question now becomes: who will be the owners of these digital products? Will there be BizDevOps teams for microservices, fusion teams for packaged business capabilities, and data domain teams for data products? Probably not. These teams are all business domain aligned; there’s synergy in areas like metadata management, and there will likely be overlap in skills.
Conclusion
To be agile at scale, organizations will create reusable digital building blocks using a variety of techniques and architectures. Domain-oriented product teams will be owning the lifecycle of all these types of building blocks.
