With new digital channels increasing customer expectations, traditional methods of application integration are becoming less and less feasible. From SOAs and ESBs to standard API Gateways and MuleSoft, it can be challenging to know what’s right for your business.

There are two paradigms in programming: imperative and declarative. As a developer you are likely using both paradigms with different code even if you may not be familiar with the terms. 

Source: https://xkcd.com/783/

The comic strip from XKCD above perfectly describes both programming paradigms: imperative programming focuses on the how while declarative programming focuses on the what. For example: 

How: Go straight for one mile, make a left on ACME Ave. It’s the first bright red house on the right.

What: 1234 ACME Ave.

So when it comes to MuleSoft, other API gateways, and programming, where do the what and how come in? And what differentiates them?

Defining how

SOAs and ESBs introduce better services

Software Oriented Architecture (SOA) was introduced long ago with the intention of creating well-defined services that were discoverable and reusable. SOA uses a top-down approach to design and create interfaces prior to implementation. The idea was noble, but not easily adopted. The top-down approach meant significant overhead on time to market (typically years) so only large enterprises with big enough budgets could leverage SOA. 

To leverage what remained of SOA efforts along with other applications, Enterprise Service Bus (ESB) started gaining popularity. The ESB’s platform-agnostic nature and its ability to integrate with anything (including SOA) was ideal for enterprises looking to leverage application functionality while adopting SOA. 

This trend, however, also did not last. Maintaining each individual application encapsulation required a subject matter expert for each application to update both the application and the ESB configuration. There was also the problem created by point-to-point integration; reusability was quite difficult to achieve. 

The problems endured by SOA and ESB consumers led to a concept that almost all of us are familiar with today — API gateway. 

API gateways improve services

API gateway uses bottom-up approach to create the services first using RAML or Swagger and implementation followed soon after. This approach was faster in terms of project delivery and quite reusable at the same time. End of story? Not quite. 

• Organizations still needed to rely on small, dedicated development teams to stay competitive and meet ever-evolving customer demands.
• What if consumer demand for new feature increased and the delivery schedule had to be shortened still? 

The primary function of an API gateway is to provide common API management functionalities such as authentication, SLA, QoS, and authorization. However, how to create each API was still left to the enterprise. Developers needed to be very prescriptive in the way each API was built, with every detail mapped out specifically for each need. This created challenges when trying to reuse or repurpose previously existing API gateways — because the initial developments were made in a way only the creator could truly understand. 

The problem of how was not limited to just development either. Enterprises still had to contend with security scan for packages, security scan for code, and a slew of other non-functional requirements for delivery. 

Incorporating what

MuleSoft innovates services

The most of today’s enterprise architecture is highly fragmented and full of disconnected endpoints. MuleSoft’s Anypoint Platform was designed to take on any integration challenge whether it is modernizing legacy systems with services, publishing device APIs for mobile consumers or connecting SAP and Salesforce. 

MuleSoft’s integrated development environment (IDE), Anypoint Studio, is not like any other IDE in that programming experience is not required to start development. Much like declarative programming, Anypoint Studio uses logic (i.e., visualization features and XML framework) to drive development. The effects of using MuleSoft are simple:

1. Negates the need for a dedicated team of language-specific developers and administrators, along with the resources needed for deployment. 
2. Declarative programming practice is proven to be less error-prone and easier to test. Therefore, delivery time is generally shorter. 

As a former DevOps engineer, item #1 resonates with me as a crucial benefit of using MuleSoft. The time and resources spent on development and deployment of APIs can now be reallocated the most important aspect of of delivery — the “what.”

With MuleSoft, a person can define the ultimate goal without worrying about connecting all the dots. The user simply identifies what they want accomplished and behind the scenes, MuleSoft takes care of how it is done. MuleSoft uses APIs to connect and expose assets, creating a better user experience and replacing traditional methods of integrating applications with custom code. This saves time during development and increases ease of use in production environments.

Why it matters

According to Salesforce’s State of IT Report, “while speed of development and delivery is a high priority and important KPI, IT teams say the speed at which they can complete projects is the second biggest challenge to meeting strategic objectives.”

For those enterprises looking to tackle this problem head on, MuleSoft’s declarative programming (i.e., less-code/visualization) approach is the right choice.

See how Silverline’s MuleSoft expertise can help your business improve agility and increase productivity.