Director of Avenga Labs
Today enterprises are software companies selling and managing their products and services using software solutions. The only constant is the fact that everything changes, so they need to predict and react rapidly to those changes.
Composable enterprises are the enterprises that take advantage of composable architectures to build and adapt their digital solutions faster, both 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 access to it by the developers and business users, and then dynamically combining 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 components 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 to external partners. Usually this type of architectural integration is the combination of REST web services, SOAP, SaaS APIs, microservices, and serverless.
Enterprises have hundreds or even thousands of applications, systems, and APIs.
IT budgets are increasing more slowly now, but the demand for digitalization is on the rise. This trend is an answer to these new challenging demands.
Delivering new functionalities faster for business users, external customers and partners is the primary goal.
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 faster. Modern CI/CD technologies combined with microservices and serverless enable this (i.e., Kubernetes, PaaS, Function as a Service, etc.).
The goal is also 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, in order to save money and allocate resources to more pressing APIs.
For the developers, it means access to all the APIs of the organization so as to be able to combine them in a creative way to help the business achieve its goals. Or even more so, to create solutions which previously were impossible because of the lack of APIs or organizational silos, which prevented information flow between the different parts of the organization.
For the internal users (citizen developers), it means a new set of capabilities, that were not available before, to integrate into their low code solutions.
→ Read about Low code and citizen developers: Pros are invited
Event driven architecture enables organizations to benefit from the detection of business facts as they happen (for instance new customer registered, sales event, etc.) 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.
Let’s do this! What are we waiting for?
The majority of companies are indeed on their path towards composable architecture. However, the path is longer and more difficult than many expected.
More components connected with each other means a lot of complexity. Why?
In the worst case scenario, it’s square of the number of APIs, for instance 500 systems (API groups) can create 500^2 = 250,000 API connections.
And, integration is not just about connecting two APIs with each other and exchanging messages. That’s the trivial part. The integration is about maintaining the correctness of data, meaning of data, correct flows, and something else which is often out of focus, dealing with business and technology exceptions.
APIs are so essential and basic now, that there’s no separate integration path. Integration between components and applications is part of the software development and maintenance.
→ Check out Generic API or Back-End for Front-End? You can have both.
It means a hidden assumption that all developers are good at integration. Unfortunately, often they lack the proper training and focus for 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.
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 requires often much more code than implementing just a happy flow.
Integration is a fundamental part of every enterprise now and almost nobody talks about it anymore.
Generally, ESB (Enterprise Service Bus) integration and products are usually a very bad 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.
Graphical tools promised to help a lot with integration scenarios, but most of the developers prefer to write code.
For non-developers it seems totally counterintuitive. Why?
With hundreds and thousands of nodes in API, graphs are not useful at all. Tens of thousands of lines connecting various components are not really that helpful in practise either. When you go beyond the simplest of examples, they explode exponentially. When you properly 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, and this also applied to the API integration.
A new generation of tools uses a paradigm of code-driven integration.
→ Read more about Star as code – Everything as code, the times of total automation
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 are supposed to be a product which is monetized directly and indirectly, and marketed and traded. All the rules of modern product management apply here. Which means another skill gap, because it’s a new domain and the old proven methods from the physical products do not apply here.
→ Explore New trend for enterprises: Managing the internal platforms as product
When someone plans the cost of API development and continuous improvement they can not forget about 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.
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.
API marketplaces seem to be an easy place 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 duplicated 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.
How do you earn money and still be an attractive API provider? How do you retain profitability while being competitive? The answers to these questions are not easy, again, it’s still in the learning phase and there’s a lot of examples of API monetization gone bad, creating the eternally unprofitable model for APIs.
Evolutionary architectures have replaced the false dream of fixed sets in historical stone architectures. Composable architectures are to replace the old integration demons of the past enabling a much faster reaction to digital organization for changes in the business needs.
→ Explore Evolutionary architectures in practice
Open initiatives for API, integration APIs, and aggregation APIs are helping to standardize API management, design and security so as to lower the barrier of interoperability between different API organizations.
All the digital enterprises are moving towards the goal of becoming composable enterprises, thanks to composable architectures.
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 clearly ahead of the other industries, but every other industry will follow.
Let us help you transform your organization towards API business, as we, at Avenga, are focused on transforming industries to become even more successful digital business players.