Reading Time: 8 minutes

Integration Platform as a Service (iPaaS) is often pigeonholed as a means of providing APIs that can be used to connect multiple systems together and nothing more. However, looking at this through a slightly different lens can provide a viewpoint on how IPaaS can be just as effective at automating commonly-executed tasks as an IT Process Automation (ITPA) solution.

Read on to learn what ITPA is; the needs it serves; examine how an iPaaS can address the same needs; and discuss the pros and cons of each.

What is IT Process Automation?

latest report
Learn why we are the Leaders in API management and iPaaS

ITPA was created because Network Operations Centers (NOCs) needed reliable ways of automating repetitive tasks that were executed to remediate network and infrastructure issues detected by monitoring systems. Prior to this, the “recipes” for doing the same were written on sheets of paper that were stored in 3-ring binders. Known as Run Book Scripts, these contained a list of actions that a system administrator would execute to confirm that an outage occurred and gather diagnostics or restart a server.

Early versions of ITPA, then known as Run Book Automation (RBA), were produced by companies such as Opsware, RealOps, and Opalis. Although their architectures differed, from a user’s perspective they all provided a visual method of building an interconnected set of actions (known as flows). The actions within the flows could be integrations with other systems (directly or via the OS shell) as well as common programming constructs like conditional statements or loops.

The purpose of creating flows was to provide a repeatable way of executing commonly required processes, similar to the goal of creating Run Book Scripts in the NOCs of early technology companies. These flows, which were created by either Citizen Integrators or developer-class IT staff for more complex processes, could then be easily executed via an exposed API or a Command Line Interface (CLI). 

How does this compare to iPaaS?

Boiling down the previous section into its essentials, ITPA can:

  • Visually construct groups of actions called flows
  • Integrate with other systems directly or using OS commands via the shell
  • Invoke flows via an API or some other commonly used mechanism
  • Be used by both Citizen Integrators and developers alike

If this sounds familiar, don’t be surprised — these capabilities are what you would also expect to find in an iPaaS platform such as MuleSoft’s Anypoint Platform.  The differences between an ITPA solution and an iPaaS platform, however, go deeper than that.  While ITPA solutions are strictly about executing a process much like Unix shell scripts or Windows CMD files, an iPaaS provides this capability and a lot more:

  • Flexible execution: Rather than limiting execution to times when the flow has been explicitly invoked by another application calling an API, iPaaS flows can also use pub/sub mechanisms, schedule-based execution, and event-based execution.
  • Reusable design: ITPAs position themselves as a means of creating tactical solutions to use case-specific problems: your server is down?  Design a flow for that.  Do you need to provision a server? Design a flow for that. In contrast, an iPaaS adopts the philosophy that assets created within it should be reusable to the greatest extent possible to avoid having to “reinvent the wheel” if a similar process requirement exists in the future.
  • Focused on integration: All ITPA solutions provide ways to integrate with other solutions. The breadth of systems with which they can integrate, however, is not as broad as an iPaaS, for which this is a core competency.
  • Built with governance in mind: ITPA solutions were not meant to provide robust capabilities in the area of governance (i.e. controlling who should be able to execute a process). This isn’t to say that RBAC (Role-Based Access Control) doesn’t exist, but ITPA solutions don’t typically go deeper than this when it comes to controlling access or requiring authentication/authorization (using OAuth2 or something similar) in order to execute a flow.

Conclusion

The question that immediately comes to mind is this: can an iPaaS be used in place of an ITPA solution? The answer is yes! As we’ve discussed, an iPaaS provides a superset of what an ITPA solution offers — in addition to having several other capabilities that the latter does not.

Interested in learning more? Learn more about our latest product offering — MuleSoft Composer for Salesforce — which makes it easy to connect any apps and data to Salesforce, in a manner similar to ITPA solutions. More of a visual learner? Watch a demo of MuleSoft Composer for Salesforce in action.