Over my years in the Salesforce ecosystem, I have encountered many projects (far too many!) in which either the architect was not aware of the benefits that middleware can provide to a system’s architecture, or the teams discarded it and saw it as “unnecessary”. In the end, these projects ended up being extremely complex for tasks as simple as updating accounts, for example.
I write this article not only for mentoring and orientation purposes to anyone who needs middleware or hesitates about its importance in a multi-system environment and architecture, but also as professional support for any new projects that might come in the future and do not see the value that middleware can provide.
What Is Middleware?
The technical definition of a middleware tool, according to the MuleSoft website, is as follows:
“A middleware solution is essentially a layer between two systems that makes it easy for the two to communicate. It can be considered the glue that holds together applications.”
This same definition can be translated into business language as follows: middleware is a communication service between two or more systems that also can ensure the needs of each system are met individually (language used by the system, security measures, error handling, retry mechanisms, etc.).
Let’s describe a practical example in order to visualize it better: in a conversation, if System A speaks English and System B speaks Spanish, either one of them makes the effort to learn the language the other system knows (which is feasible, but can take a lot of time and effort), or they will require a translator in order to understand each other. If we add System C to the dialogue that speaks only Chinese, you can imagine how nightmarish that scenario becomes.
How much easier would the communication be if there were just one person who knows all the languages and needs of each interlocutor, and translates and adapts the message for everybody? That is exactly the role of a middleware.
Do the Downsides Outweigh the Benefits?
Before I try to sell you middleware for your project, let’s take a brief pause to talk about the common arguments against using middleware, which are usually not so solid and are more subject to criticism.
Question: You are asking me to hire an entire team just so that systems that have the resources to understand each other by themselves find it easier. Given the fact that this solution involves more systems and teams, is it not more expensive?
Answer: Indeed, in many integrations, and especially when talking about Salesforce, the systems that want to communicate between themselves already have the capabilities to do so. However, integrations by nature tend to be complex, requiring a lot of logic and transformation behind, and the different systems usually struggle to understand each other – quite a lot, actually. Solving these issues individually requires a lot of time and effort. In the end, all these issues stack on top of each other, resulting in a solution that can easily become far more expensive than if middleware had been put in place from the start. The more systems present in different integrations (even when they are independent), the worse this problem gets.
Question: This solution implies adding an extra system into an integration between just two systems. Is it not a more complex solution?
Answer: Quite the opposite, actually. Even when we are adding a system specifically for communication between systems – and precisely because it is focused on doing so – everything becomes much simpler. Each system can forget about many of the other system’s needs (or most of them, at least), as middleware can usually take care of them. This makes implementation in the source and target systems a very straightforward process. These benefits stack with others, such as flexibility, scalability, security, etc.
Let’s dive into it…
Key Benefits of Using Middleware
Long-Term Savings Are Likely
Middleware can take away a lot of the complexity between the integrated systems. Less complexity equals fewer people involved and less time spent both building and maintaining the solution. Ultimately, less time and fewer people mean more money for your company and your client!
Performance
It is very important to economize resources inside Salesforce as much as possible (given reasonable parameters, of course). Every transformation performed inside Salesforce consumes part of these valuable resources. Some examples of these valuable resources would be:
- Data stored inside Salesforce.
- Data not stored inside Salesforce, which is used to translate the data to integrate with additional systems.
- More Apex characters spent in your solution, in the following features:
- Specific Apex logic to senddata from Salesforce into a format the other system can understand.
- Specific Apex logic to receive data from the external system into a format that Salesforce can understand.
- An Apex wrapper defined for incoming data.
- An Apex wrapper defined for outgoing data.
- Security adjustments to adapt to the needs of each system individually.
- Providing separate credentials for each system integrated with Salesforce, or compromising them to share a set of credentials (questionable from a security standpoint, to say the least).
- And many more constraints from an architecture perspective.
These negative traits and constraints are multiplied by the number of systems Salesforce needs to call or retrieve information from. They can grow out of control very quickly if not properly reviewed and handled. If all the logic is handled internally within Salesforce, the same logic that would be relatively simple when written in middleware can overcomplicate things inside Salesforce quite easily.
I don’t think any developer or architect wants to be involved in a mess of queuing, rescheduling jobs, and throwing platform events randomly in order to fit within governor limits – do you?
Keeping Things Simple
When you need to translate a message from one system to another, you need to write many functions and code (similar to when you develop internally in Salesforce). If there is no middleware, Salesforce itself becomes the limit, as if it were not present in the integrations. The same or similar logic needs to be written in two different places, and duplicating logic is always harmful.
Let’s work with an example: imagine that you need to translate a label (which contains the user’s country) into the main currency of the country it belongs to. Are you going to maintain this dictionary individually for every integration? You might be able to do so in Salesforce with the currency picklist, but what about the integrations where Salesforce is not present? Are you going to make them go through that effort as well?
When looking exclusively from a Salesforce point of view, it might not make much sense, but from a multi-system landscape, it does significantly. Especially referring to the example above, as new countries that do not work with business today might be included tomorrow, meaning you’ll have to propagate the fix or change for the currency for each and every system and interface that requires it.
In addition to all the arguments mentioned above, it is always good to aim for simplicity and separation. Solutions that have all the translation logic across systems tend to be cleaner and simpler to maintain in middleware.
Error Handling
Things can and will go wrong in an integration. Even if they do not, it never hurts to have a security net. Errors come in all shapes and forms. You could get a 500 internal server error, trigger a validation rule, run into a certificate issue, and so on.
Middleware can set up different logic for each scenario that is also reusable across many integrations, allowing complex, robust, and scalable error-handling mechanism to be developed over time without feeling overwhelming. Middleware tends to be very flexible in this field, as you can configure custom error policies, retry mechanisms, store errors by integrating with an external system, and return them in a specific format.
Salesforce Benefits From It – A Lot!
There are many Salesforce features that are out of the box and can be used for integrations. These translate into enhancements from which the business can benefit. Some examples of these are:
- External Objects
- Fixed IP addresses
- IT Security certificates
- Salesforce Standard API
- Salesforce Composite API
- Identification mechanisms, using tools such as external apps or OAuth 2.0
The same applies to the other systems that want to integrate with Salesforce. They will have very specific needs and adjustments, and Salesforce is not the ideal system to adapt to those specific needs.
In addition, Salesforce enforces API version changes, which can only be delayed to a certain degree. For example, up until a few months before this article was published, integrations using OAuth with Salesforce worked only through Connected Apps for verification purposes, as the External Client Apps did not yet exist.
Salesforce is on a schedule to move away from Connected Apps to External Client Apps – an effort you would need to do individually for every system that wants to integrate with Salesforce. This effort can be drastically reduced by using middleware, as it can reuse a set of credentials shared across multiple integrations that use the same Salesforce interfaces, saving considerable effort in testing from a Salesforce perspective.
Are All Middleware Benefits Covered?
Absolutely not! There are specific benefits that may apply, depending on the middleware you are using.
Talking about MuleSoft specifically, some examples include:
- Spike Control
- Rate Limit Policy
- Queues
- Secret Manager
Using middleware in the most profitable and efficient way is a topic so complex and technical that it deserves its own separate article. I am not focusing on these specific layers of the conversation in this article, but there is definitely much more to discuss here.
Too Good to Be True?
You might be thinking either that I have a very unfair and one-sided view of what middleware really is, or that I believe middleware in general is perfect – but the reality is far from it.
Middleware does have significant issues associated with it, and it is important to be aware of them before deciding whether to include it in your system landscape, which I will outline below.
Few Professionals Available
Middleware is considered a niche subject, and experts can sometimes be quite difficult to find. It is very important to have one of these experts on the team to build a good solution, as a poor implementation of the middleware system can do more harm than good.
Impact of Middleware Issues on an Architectural Landscape
The moment you decide to unify the translation and communication logic in middleware, your integrations become dependent on it. For cloud-based apps such as Salesforce or MuleSoft, if the middleware undergoes maintenance, nothing works at the integration layer, and all services stop. This is similar to what might happen in Salesforce during one of its maintenance routines.
Ultimately, you’re relying not only on Salesforce being available but also on Mulesoft – that is twice the maintenance time. This assumes there are no dependencies on the rest of the systems, which is very unlikely and unrealistic.
This issue specifically can also be mitigated by considering an alternative that works on-premise and is not dependent on a cloud-based service.
Additionally, bugs can appear, and an issue in middleware can affect multiple interfaces at the same time, increasing the impact on the overall architecture.
It Is Not Always Necessary
For very simple integrations at very small companies – between just Salesforce and one other system – it might be like building a hotel for a single person to use. The building is beautiful and designed to handle more traffic, but it is somewhat unnecessary for a project that is so simple.
Summary: Is It Worth Including in Your Project?
It depends, but most of the time it does, and the issues and costs associated with it are not as impactful as the benefits it brings. Therefore, it is usually a good idea to include middleware in your system landscape – especially if many systems are involved or if there are plans to add more systems in the future.
What Middleware Should I Choose?
There are many middleware options available on the market, but I suggest MuleSoft, as it is frequently used in top-performing architectures for important projects. It is highly integrated and works very well with Salesforce (they even share the same learning platform: Trailhead).
If you are still unsure about using middleware or the arguments provided in this article, you can always check out some other SF Ben articles that go more into detail about it:
- Salesforce ETL Tool Market Overview: How Should You Choose?
- Choosing the Right ETL Tool or Middleware for Your Salesforce Data Migration or Integration
- Salesforce Integration Checklist: How to Ensure Project Success
- Complete Guide to Salesforce Integration Best Practices
- How MuleSoft is Used With Salesforce
