Skip to main content

Beyond MuleSoft & iPaaS: Business-as-Code

· 9 min read
Colt McNealy
Colt McNealy
Founder & Managing Member

One of the more embarrassing moments I've had as CEO of LittleHorse was when the CTO of one of the biggest telcos in the country asked me, "we already have MuleSoft, why do we need you?"

I replied, "what's MuleSoft?".

Last week's blog comparing LittleHorse's Business-as-Code approach to Temporal resembles a Founding Perspective: I started LittleHorse with the goal of creating a higher level of abstraction as an alternative to Temporal.

This blog is quite different because I never set out to compete with MuleSoft. However, it turns out that at LittleHorse we have built a compelling, modern "next step" to the iPaaS systems of the 2000's with the open and developer-first ethos that my father hammered into me from a young age.

In short, integration platforms such as MuleSoft and Boomi excel at connecting external software systems together through an API-led connectivity approach. However, as software becomes more and more abundant, CIOs need not only to connect systems but also to orchestrate and govern business processes across an ever-growing suite of systems, agents, and departments. That’s what we created Business-as-Code for.

The Philosophy​

MuleSoft's core philosophy is to connect external software systems and synchronize data between them. Because MuleSoft was created in 2006, its architecture still has many heavyweight components (most notably, the Mule Runtime) that were necessary to enable that vision.

In contrast, LittleHorse's core philosphy is to codify, orchestrate, and govern business processes end-to-end across external systems, microservices, agents, and people. While there is some overlap (several of our customers successfully use LittleHorse for integration workflows), Business-as-Code powers more ambitious projects than API-led integration and connectivity.

MuleSoft Transformed IT in the 2010's​

MuleSoft was built in 2006, before Kubernetes, Kafka, Spring Booot, or the cloud. At the time, most enterprises ran their company through purchased software such as SAP, Oracle, and PeopleSoft rather than building systems in-house; in fact, many enterprises had only recently ventured into hosting their own website!

Given the lack of infrastructure at the time, certain things we take for granted were difficult. For example, listening to events in PeopleSoft and notifying SAP every time a new employee was onboarded was a difficult process. You had to first provision a server, connect it to the internet, and then deploy a web application to handle it.

However, MuleSoft transformed the IT industry by making this easy: all you had to do was create a new API on MuleSoft and configure it to post to SAP. MuleSoft was truly revolutionary for its time! For today’s agentic era, though, we need a better answer.

Business-as-Code: Orchestration for the AI Era​

In contrast, LittleHorse was born in the days of cloud, microservices, and AI. It's no longer difficult to deploy and expose an API on AWS that listens to webhooks and sends data to downstream systems, and there are ways to do it which are much cheaper, faster, and more lightweight than MuleSoft. Such applications and integrations are now so easy and abundant that they have created a fully separate problem: while it's easy to write a point solution application, orchestrating end-to-end business flows across the modern plethora of systems is incredibly difficult.

This architecture has a gap in the orchestration layer which happens to be exactly the same size and shape as our Business-as-Code approach. MuleSoft is a serviceable (albeit expensive and heavy) way to connect SaaS towers. However, competitive pressures mean that sometimes you need to build things that you can't get off-the-shelf.

LittleHorse's Business-as-Code approach goes further than just integrating SaaS systems by:

Architecture: API Composition vs Business-as-Code​

LittleHorse’s Saddle Command Center is designed around workflows and events; in contrast, MuleSoft’s architecture revolves around the core concepts of APIs and integration flows.

While MuleSoft excels at connecting external software systems, it was not built with long-running business processes and agent governance in mind. In contrast, LittleHorse was built specifically to enable the creation of custom capabilities, workflows, and agentic applications.

MuleSoft is Stateless Connectivity​

MuleSoft is built to connect diverse systems together and allow enterprises to consume them under a unified API layer. For the most part, this API layer is stateless and serves as a conduit to move data between different systems rather than a stateful orchestrator. This architecture was designed primarily for integration flows, which accept data from one system, transform it, and ship it off to other systems.

The core building block of MuleSoft's Anypoint platform is the API. In MuleSoft, APIs can serve as a proxy over legacy systems (System APIs), and can be composed into higher level APIs to model integration processes (Process APIs) or serve external clients (Experience APIs).

MuleSoft developers create APIs and implement integration logic using Integration Flows, which listen for incoming data, transform it using DataWeave, and invoke downstream APIs or connectors. MuleSoft also supports asynchronous flows through messaging systems such as Anypoint MQ, although its architecture is primarily centered around APIs and integration flows.

All of the above logic is packaged and deployed into a Mule Application. Mule Applications are deployed into and run on a proprietary infrastructure ecosystem. MuleSoft also pushes developers towards proprietary specifications (DataWeave) and a proprietary IDE (Anypoint Studio).

In contrast, LittleHorse has an open-source ethos and flexibility to allow developers to thrive with tools and deployment models of their choice.

Running a Mule Application requires using the Mule Runtime as a deployment runtime. In contrast, you can run a LittleHorse Task Worker inside Saddle Command Center via the LittleHorse Runtime (much similar to the Mule Runtime), but you can also run the Task Worker on a bare-metal server, on EC2, in kubernetes, or wherever you want.

LittleHorse is Stateful Orchestration​

While MuleSoft's core concepts are APIs and stateless Integration Flows, LittleHorse enables Business-as-Code with two key components:

  1. Events published in an Apache Kafka-compatible streaming engine. An event signifies that something happened and can be combined with other events, exported to other systems, or used to trigger workflows.
  2. Workflows in the LittleHorse Server that codify and govern business processes in natural code. These can be short-lived, long-running, fast, or slow processes.

Saddle Command Center has additional components, such as a suite of connectors to sink events into external systems, an OIDC plugin for human-in-the-loop governance of workflows, and an optional runtime for pre-built task workers. However, all of these components exist to enhance our two core primitives (events and workflows).

Note that LittleHorse is built on open-source and flexible APIs. Users can deploy their task workers wherever they want and write them in a language of their choice rather than being forced to use Anypoint IDE, DataWeave, and the Anypoint Runtime. Additionally, events are consumable via the well-known and loved Apache Kafka API.

Crucially, LittleHorse's event and workflow-centric model decouples connectivity from orchestration. This enables our users to specify much more complex workflow orchestration logic than what you can do in MuleSoft. By decoupling events and workflow orchestration, LittleHorse Workflows can:

  • Handle long-running business processes, not just integration flows,
  • Wait days or weeks for responses from external systems.
  • Govern agents with human-in-the-loop steps.
  • Power core product flows with custom business logic rather than simply back-office integrations.

Business-as-Code: Action Layer For AI​

Deploying APIs and connecting systems together are no longer the most pressing problems in enterprise IT. As software has become more and more abundant, IT teams find themselves wrangling dozens or even hundreds of SaaS tools powering potentially thousands of business processes! At this level of complexity, CIOs run into a wall: integration platforms can connect systems but they do not provide an action layer to codify and govern business processes.

Connecting external SaaS systems together neatly solves data synchronization challenges but it does not solve the larger problem of fragmented automation. When relying on automations within external systems, end-to-end flows are opaquely split across point-to-point integrations. This limits their automation potential to what each system provides natively.

This fragmented automation limits agentic automation: relying on agents inside external platforms means that your agents have limited context and limited access to affect external systems. Reliance on external systems’ agents also presents challenges for auditing and governing processes.

Business-as-Code has helped several of our customers break beyond this wall by providing an action layer between and across all systems. Business-as-Code codifies, governs, and executes processes end-to-end across systems, people, and agents, enabling IT teams to automate processes that you just can’t solve by connecting systems together.

What's Next?​

Adopting Business-as-Code is a surprisingly small lift. Our Business-as-Code Workshop focuses in on one specific business process which is slow, expensive, opaque, or otherwise in need of automation, and delivers results in a month or less.

Our philosophy is not to rip-n-replace the IT stack that has powered your business for decades, but rather to rise above the existing complexity and codify workflows across the SaaS systems you already have! And this includes MuleSoft: while you could rewrite already-working integrations from MuleSoft to use LittleHorse, our customers generally find initial value faster by codifying workflows that MuleSoft itself can't do.