In this blog, we explore why we shouldn’t be so quick to forget our Mule ESB (Enterprise Service Bus) roots. Understanding MuleSoft’s past offering, will help us better appreciate its foundational strengths and substantiate why MuleSoft is set to become real strategic player in the integration space in 2020.
ESB (the integration term that should not be named)
I have been fortunate enough to work in the integration space, and in particular within MuleSoft API-led integration, since its early years of industry adoption. In those days, Mule was positioned as an ESB* – a term which has since achieved Voldemort status – ‘the integration term that shall not be named.’
This is because in the last 5 years we have seen MuleSoft make the paradigm shift to API-led connectivity and away from ESB-led connectivity - mirroring the behaviour of the industry as a whole. Because, as enterprises look to accelerate their digital journeys, APIs offer more flexibility to connect the fast pace of digital innovation as compared to ESBs, which are used to integrate various systems of record, for stable, well-understood business processes.
As Ross Mason (Founder) explained at MuleSoft Connect in October: “it’s not about the big eating the small, it’s about the fast eating the slow.” In the tech industry, no matter your size, you must innovate fast or die - ESB models were out and API-led connectivity was in, so MuleSoft made the move.
How do current MuleSoft customers feel about this move?
As a Business Development Manager at Coforge, I have the privilege of speaking with very experienced individuals in their fields - both from technical and business tracks. These professionals who are embarking on API-led transformation, have explained that their experience with Mule has typically been truly progressive, but also encompassing a huge learning curve.
This is because with the adoption of any new tech, especially in its infancy, there is a certain amount of ‘skilling-up’ that is required. This is not necessarily in its core language – in this case predominantly Java – rather, the best practises surrounding it. This is particularly true in the new MuleSoft API-led view where DevOps are so closely linked.
As a result, I have noticed a considerable increase in conversations surrounding best practise, governance and correctly leveraging a C4E (Centre for Excellence) – something I will be going into more detail on in my next post.
How can embracing Mule’s ESB roots drive API-led solutions in 2020?
Greater demand from businesses for bigger and better IT solutions cannot be supported by IT budgets that, on the whole, remain stagnant and are simply used to keep the “lights on.” This results in little innovation with prolonged product release cycles.
Yes, DevOps and Agile are a start to tackle incumbent problems, but are not enough to deal with the growing demand and dwindling resources. The solution? A new operating model with a productised API at its heart and the understanding of the positive outcomes of an ESB foundation – the cumulative efforts which have resulted in a matured community and maturing business and project practises.
In short, if we treat APIs as business assets which are made reusable and available through an exchange, we essentially enable lines of business within any organisation to self- serve. The Mule narrative makes it clear that product is only half of the battle, the consumption of said assets is just as vital.
Final thoughts
With the desire among customers to press innovation forward, we should be retrospectively looking at projects to see how we could do them better in the future. The increase in re-rationalising APIs, ensuring they are correctly structured and leveraging the three-tiered approach is crucial to the entire story.
*According to MuleSoft, an Enterprise Service Bus (ESB) is fundamentally an architecture. It is a set of rules and principles for integrating numerous applications together over a bus-like infrastructure. ESB products enable users to build this type of architecture, but vary in the way that they do it and the capabilities that they offer. The core concept of the ESB architecture is that you integrate different applications by putting a communication bus between them and then enable each application to talk to the bus. This decouples systems from each other, allowing them to communicate without dependency on or knowledge of other systems on the bus. The concept of ESB was born out of the need to move away from point-to-point integration, which becomes brittle and hard to manage over time.
If you would like to discuss how you can leverage API-led connectivity or have any other queries about MuleSoft Anypoint Platform, then give us a call on +44 (0)203 475 7980 or email us at Salesforce@coforge.com
Other useful links:
Mule 4 migration accelerator
API reusability - Why does it matter?
Designing and implementing APIs using MuleSoft API Platform
