Composable architecture as a key for composable enterprises in the digital future

Composable architecture is the answer from slowly-moving product building, deployment, and testing.

Today enterprises are software companies selling and managing their products and services using software solutions. The only constant is that everything changes, so they must predict and react rapidly. Composable enterprises use composable architectures to build and adapt their digital solutions faster for internal and external users.

The idea of composable architecture is to API-enable all the systems and processes within the enterprise and its partners, allowing the developers and business users to access it, and then dynamically combine those APIs into digital solutions for the ever-changing business needs. A key idea to make it more efficient is to divide large complex systems into smaller autonomous components (in the true spirit of microservices architecture). This is called disaggregation, which is the opposite of aggregation. The smaller and smaller parts of the enterprise architecture enable much more flexibility than the monolithic architectures of the past.

There are different ways to make them available to the rest of the organization and external partners. Usually, this type of architectural integration combines REST web services, SOAP, SaaS APIs, microservices, and serverless. As a result, enterprises have hundreds or even thousands of applications, systems, and APIs.

IT budgets are increasing more slowly now, but the demand for digitalization is rising. This trend is an answer to these new challenging demands.

The goals of composable enterprises

The primary goal is to deliver new functionalities faster for business users, external customers, and partners. It’s important to emphasize that both internal and external users are relevant. Digital transformation is not just about consumers facing digital products and their experiences.

Build faster, test faster, and deploy more quickly. Modern CI/CD technologies combined with microservices and serverless enable this, for example, Kubernetes, PaaS, and FaaS. In such a case, the goal is to reduce the cost of the new development and changes, so less writing code from scratch, less duplication of functionalities, and more integration.

The other goal is to enable scaling, which means being able to serve more customers when the need is higher, but on the other hand, to scale down when the situation demands it to save money and allocate resources to more pressing APIs. Finally, for the developers, it means access to all the APIs of the organization to be able to combine them in a creative way to help the business achieve its goals. Or even more so, to create previously impossible solutions because of the lack of APIs or organizational silos, which prevented information flow between the different parts of the organization.

For the internal users, it means a new set of capabilities not available before to integrate into their low-code solutions. The event-driven architecture enables organizations to benefit from detecting business facts as they happen and to react to those events in milliseconds rather than in days or weeks, as one API may respond to the changes notified by another API.

Adoption challenges for composable architectures

The majority of companies are indeed on their path toward composable architecture. However, the way is longer and more complicated than many expected.

Integration means complexity

More components connected mean much complexity. In the worst-case scenario, it’s the square of the number of APIs. For instance, 500 systems (API groups) can create 500^2 = 250,000 API connections.

Integration is about more than just connecting two APIs and exchanging messages. That’s the trivial part. The integration is about maintaining the correctness of data, the meaning of data, correct flows, and something often out of focus,  dealing with business and technology exceptions.

Nobody talks about integration anymore

APIs are so essential and fundamental now that there’s no separate integration path. Instead, integration between components and applications is part of software development and maintenance.

It means a hidden assumption that all developers are good at integration. Unfortunately, they often need more training and focus on integration issues. It works for me in the context of my application, but it is no longer a valid approach; it never was, but now this type of attitude is even more expensive for IT and businesses.

Unhappy flows

There’s too much focus on happy flows, which make the application ‘work’ for businesses, but it is too often at the expense of less visible code, which is triggered when something goes wrong. For instance, there’s a lack of money on the account for a money transfer, the credit card was blocked, and the other party is not responding. Handling these events often requires much more code than implementing just a happy flow. Integration is a fundamental part of every enterprise; almost nobody talks about it anymore.

The lousy spirit of ESB

Generally, ESB (Enterprise Service Bus) integration and products usually need a better memory. They promote configuration over code, complex flows, custom, and pipelines. Many times developers felt they could complete the integration tasks without the ‘help’ of the enormous, heavy, and complex integration engine easier and orders of magnitude faster. Yet, they weren’t allowed to do so outside of the ESB.

Hate of the pictures

Graphical tools promise to help with integration scenarios, but most developers prefer to write code. For non-developers, counterintuitive.

With hundreds and thousands of nodes in API, graphs are not applicable. Likewise, tens of thousands of lines connecting various components are not helpful in practice. When you go beyond the simplest of examples, they explode exponentially. When you correctly add all the corrective actions, even the simple (on the surface) process becomes a web of lines, arrows, and boxes.

Code won over configuration, and graphs are everywhere, which applies to the API integration. A new generation of tools uses a paradigm of code-driven integration.

Forgetting about networks

Developers like to live in the world of high level abstractions and don’t even think about the infrastructure. Treating API calls like local calls, forgetting about the network IO, latency, and performance is always a bad idea, in addition there’s been constant fighting between tech leaders and developers to make sure the other will never forget again, so it’s not really local.

APIs as products

APIs are supposed to be a product monetized directly and indirectly and marketed and traded. So all the rules of modern product management apply here. But unfortunately, this means another skill gap because it’s a new domain, and the old proven methods from the physical products do not apply here.

The cost of APIs

When someone plans the cost of API development and continuous improvement, they can remember test environments, sandboxes, trial versions, upgrades of underlying components, and runtimes. As an effect, there’s much more cost wise to API development than designing and coding APIs.

API security

Tokens, SSO, and multi factor authentication are the current standards which everybody expects. An API without the properly implemented authentication and authorization mechanisms has no chance on the market and should not be allowed to be used because of the security requirements.

To make it even more difficult, there are different data protection and privacy policies globally (EU, USA, Asia, Africa, Middle East, NZAC etc.) which have to be followed and have a direct impact on API design, implementation and deployment.

APIs on sales

API marketplaces seem to be accessible places to promote your APIs. However, it is also easy to lose the benefit of being the first to introduce an idea, and very easy to be copied and duplicate by your competition.

The growth hacker is the new role focused on how to get more customers to use your API and pay for it. The traditional product selling strategies no longer work for APIs. The way to sell efficiently is still in the experimental phase, and everybody’s learning how to do it.

Monetization strategy for APIs

How do you earn money and still be an attractive API provider? How do you retain profitability while being competitive? Unfortunately, the answers to these questions are not easy. Again, it’s still in the learning phase, and many examples of API monetization have gone bad, creating an eternally unprofitable model for APIs.

APIs as the products of the future

Evolutionary architectures have replaced the false dream of fixed sets in historical stone architecture. Composable architectures replace the old integration demons of the past, enabling a much faster reaction to the digital organization for changes in business needs.

Open initiatives for API, integration APIs, and aggregation APIs are helping to standardize API management, design, and security to lower the interoperability barrier between different API organizations.

Thanks to composable architectures, all digital enterprises are moving towards becoming composable enterprises. They continue to improve the offering by allowing APIs for their business partners and customers, also internally, not just externally.

Fintech, insurtech, and banking are ahead of the other industries, but every sector will follow. Contact us to help you transform your organization towards API business. Our expert teams are focused on transforming industries into even more successful digital business players.