In recent times the whole world has suffered, and it is still suffering the effects of the COVID-19 pandemic. We have heard, especially from the news media and social networks, about the need for companies or organizations to face what is known as digital transformation. But this concept is nothing but new, due to the irruption –among many others-, of mobile technology, cloud tech, social media, Big Data and analytics, the Internet of Things (IoT), etcetera.
What this implies is that organizations have to be prepared to meet these present and future changes in order to implement them in an agile an swift way:
- Increasing IT operational efficiency.
- Increasing business efficiency.
- Improving the customer experience.
- Implementing new products and services more quickly.
- Improving the employee experience.
- Improving the partner experience.
The only aspect that is constant is change. We are in a world of extreme competitiveness. It is not the biggest or the strongest who survive; rather, it is the fast one that eats the slow.
What is Mulesoft?
MuleSoft is a market-leading integration software company, acquired by Salesforce in March 2018 for $6.5 billion, that offers solutions for cross-system integration.
Its flagship product is Anypoint Platform, a complete Integration Platform-as-a-Service (iPaaS) solution for the connectivity managed by API that allows companies to create create networks of data applications and devices, both on their premises and in the cloud. Besides that, it allows the integration of any system (CRM, SAP, SAS, etcetera) from a methodical approach known as API-Led Connectivity.
It is a methodology to connect applications, data and devices through an API, as opposed to point-to-point integrations.
The main goal of this methodology is to allow integration flows to be reused by many parties within the integration platform. Thank to this recycling of the already available logic (implemented in flows), developers can implement their logic in a safer and quicker way, leading to a shorter time to market.
All this means that the APIs are created in layers, allowing, unlike the E2E approach, that more components (flows) can be reused, facilitating the implementation of new systems and services.
The comparison between this methodology and those known as “traditional” can be summarized in this chat:
|API-Led Connectivity||Traditional approaches (P2P, E2E)|
|On time and on budget.|
Aimed at reuse rather than construction.
|A On time and on budget.|
|Designs ready for change.||Little or no reuse capacity.|
|Incorporates governance, compliance, security and scalability.||Hard to manage.|
|Satisfies the needs of your business.||They don’t always meet business requirements.|
It encompasses the APIs in three different groups:
- Experience APIs: API aimed at presenting information in order to be easily processed.
- Process APIs: API aimed at data processing, for data obtained in the system layer, and adapting it to meet business needs.
- System APIs: API dedicated to the lowest-level processes of connection with data sources.
This is a hybrid integrationo platform, base don the API-Led Connecitivy methodology, and enables:
- The connection of any application, data or devices.
- The connection and disconnection of applications without impact on other consumers.
- Design, deploy, manage and secure APIs.
- Business processes automation.
- Recycling existing APIs to build new, more complex and complete APIs: allow other consumers from other business verticals to enter, discover and use those assets.
All of these processes happen through the construction of the Networks Application, which aims to create and deliver new products more efficiently and thus address the digital transformation.
An application network is a way to connect applications, data and devices through an API that exhibits some or all of their assets and data online. The construction of an application network implies the development of reusable assets, and then encourage business participants to reuse and have a self-service with those assets. They can then be used and reused in different ways within the organization. Consecutively, new connections can be made between these assets and through APIs, because it is the best abstraction for information exchange between two parties (information exchange between other applications).
There are not only reusable assets available to be implemented across the organization in order to create and deliver new products more efficiently, there are also teams to help those development groups understand best practices on how to build new products and services, that is, to point the way to a repository of services available for reuse.
Everything that is published in the application network can be discovered, managed, controlled and protected. The central IT organization has the management and governance of all the services and allows development teams from the business lines to reuse them for every project in which they might be considered necessary. People who create new services and products in the organization can take these assets as they are or they might take just a basic component, aggregate it and publish a new basic component. Therefore, a possibility is opened for several teams to take advantage of that asset created previously.
An applications network is not an architecture, it is a set of building blocks on which architectures can be created. Its managed and federated nature allows it to bend, not break. New products and services can be easily connected and disconnected, and technologies such the one offered by Mulesoft allow to achieve the agility and flexibility that every organization needs to continue driving and leading the growing challenges of digital innovation.