One of the most used and abused buzzwords in the IT industry these days is “automation” (often associated with another popular buzzword: digital transformation). 

More and more user organizations are setting automation initiatives in motion, and a growing number of providers are describing themselves as automation vendors (whatever that might mean). But “automation” is increasingly associated with “integration”. For example, several vendors, traditionally established in the integration technology market, are repositioning themselves as integration + automation providers—typically because they recently added an RPA tool to their product portfolio. 

So, how should you think of automation and integration? And how do these two disciplines relate to each other? In this blog post, I’ll answer these questions and discuss how automation and integration are, in my opinion, just two sides of the same coin: there is no automation without integration and automation is a key use case for integration.

What is “automation”?

According to the Oxford Learner’s Dictionary, “automation” means: “the use of machines and computers to do work that was previously done by people”. From that perspective, therefore, most IT applications are indeed about “automation”. For example a finance application essentially provides a collection of functionalities aimed at automating tasks and business processes in areas like general ledger, accounts receivable, accounts payable, and financial closure. Hence, it is legitimate to say that organizations have been automating since they bought their first computer system (or their first SaaS, if they are a start-up).

This classic form of automation is typically siloed within individual organizational units (finance, HR, sales, procurement, supply chain, manufacturing, etc.). However, for many years now, organizations have been using integration technology, such as ESBs or ETL tools, to synchronize data across different applications, thus implementing a rudimentary form of cross-unit process automation.

Integration technology to ensure data synchronization across siloed applications

Packaged application vendors tried to overcome the automation organizational boundaries by developing broad suites of functionality (for example, ERP or CRM suites) that cover cross-unit process automation requirements. However, it is notoriously difficult and costly to automate processes by adopting these suites. Implementing them takes quite a long time, especially if you have to reshape their cast-in-code processes to meet your specific requirements. This mandates you to modify the relevant applications, which is hard, expensive and, at times, close to impossible. 

In the old days of packaged application software, if you had deep enough pockets, you could hire an army of consultants and “customize” the application so that it adjusts certain processes to your specific needs. Everybody who tried to do that can tell you how difficult, expensive, and time consuming the approach was. But it was, at least, doable. With SaaS, not even this is possible, as you cannot modify a SaaS application’s code. In truth, SaaS providers allow some degree of customization, but—in most cases—within well-defined and often quiet stringent constraints. In any case, modifying the application code is forbidden. SaaS providers cannot afford to have as many versions of their application as the number of customers they work with (which can be in the tens or even hundreds of thousands). The running costs would be astronomical, and the change management process would be an intractable nightmare. The SaaS business model mandates a single version of the application for all the customers.

Moreover, realistically, no single suite can actually support the full set of requirements of a real-life organization. Therefore, user organizations often buy or build “satellite” applications to fill the functional gaps of these mega-suites. This, and the suites’ limited flexibility, has led to a new, end-to-end model of automation. 

According to this model, you shouldn’t look at applications—packaged, SaaS, and homemade—as purely set-in-stone collections of business process silos.You should now consider your application portfolio as a portfolio of business capabilities, exposing APIs that can be orchestrated via an external automation layer (for example, implemented via a BPM tool, a low-code application platform, or an iPaaS). And, in the event that an application doesn’t have APIs, you can use an RPA tool or another “screen-scraping” technology to expose APIs out of your non-API enabled system. 

Via the end-to-end model of automation, you can orchestrate a best-of-breed set of business capabilities provided by different applications and systems, thus defining and implementing more effective, impactful, and differentiated processes. These processes are often cross-functional, for example, spanning across your finance, HR, and customer service or procurement, supply chain, and manufacturing functional units.

In short, as a progressive CIO or IT leader, not only do you wish to buy siloed applications that automate certain aspects of your organization’s processes. You also, and most importantly, want to rapidly automate complex—often interfunctional—end-to-end processes by orchestrating the business capabilities of multiple systems. You also want to be able to easily and quickly reshape, extend, or modify these processes in an agile way, as new requirements emerge. This quest for short time to value and business agility is the reason why the use of low-code orchestration tools in the automation layer is crucial. 

To favor business agility, your automation strategy must enable your business users, but also potentially business partners and communities, to engage with these processes via a variety of channels (web, mobile, bots). 

Finally, to complete the automation picture, in an increasing number of cases, these business processes will also involve “machines” (e.g., 3D printers, drones, industrial robots, etc.) to perform certain activities that deal with the “physical” world. For example, this can be a drone that delivers your company’s products to customers in rural areas as part of your “order-to-cash” process.

What is integration and what is its relationship with automation?

The modern, end-to-end model of automation described above requires independently-designed systems (including software applications and machines) to work together in order to automate (that is, “remove manual activity from”) a process. For example, by using the output data of a system (say, sales data in a CRM application) as input data for the next step in a process (for example, an ERP system), employees can avoid manually re-keying data from system to system (half jokingly, at times I state that the most commonly used automation tools are cut-and-paste and the swivel chair). 

However, independently-designed systems participating in a process are, more often than not, inconsistent in terms of their data models, external interfaces (APIs, events, etc.), formats, communication protocols, technology platforms, and even data semantics.

This is where integration technology plays a critical role. 

Integration technology, according to its widely-adopted definition, is used to ”make independently designed systems work together.” In other words, it acts as a bridge between different communication protocols, and validates, maps, and transforms data in transit from one system to another. Moreover, integration technology can route messages and data to the appropriate destination. For example, if the value of a purchase order is lower than $100,000, it is sent to the order fulfillment system; otherwise, it must be routed to the application where a designated human approver can review, approve, or reject it. The consequence is quite obvious: protocol bridging, routing, as well as data validation, mapping, and transformation are integration functionalities you must use when automating a process that involves multiple, “independently designed systems”. 

Modern, end-to-end, multichannel automation enabled by integration technology

The bottom line is that the modern, end-to-end model of automation requires integration. Automation is the goal, integration is the means. 

It doesn’t make a lot of sense to have an automation strategy without a closely aligned and coherent integration strategy. Vice versa, an integration strategy that’s not designed to support automation needs is poor and incomplete—as every organization in the world wants, and needs, to automate at least some of its processes.

Consequently, your automation and integration strategies should be designed together as two sides of the same coin. I refer to this coin as “enterprise automation”, that is, a unified strategy that puts integration technologies and methods at the foundation, and automation as one of the enabled use cases (along with the other key use cases: ensuring data synchronization and supporting API-based composition). 

The business value of an enterprise automation strategy vs. two distinct strategies is well understood when measured in terms of reduced costs, greater efficiency and effectiveness, and business agility (see: The strategic benefits of integration and automation). But an enterprise automation strategy also offers IT-related benefits: 

• Clear set of goals: distinct strategies may potentially entail conflicting goals (for example, cost reduction in the automation strategy and business agility in the integration strategy), which may create friction and lead to a fight over resources. A unified strategy is, at least in principle, guided by a common and well-defined set of goals (for example, boosting efficiency and increasing business agility).

• Synergies: you can use your integration technologies and skills to also support automation—saving your organization money and time.

• Optimization: when addressing a new challenge, you can use the right technology and associated skills (as opposed to using a potentially wrong tool because it’s the only one you know about). 

• Greater ability to tackle complex scenarios: these scenarios may require a combination of the automation and integration technologies (for example, RPA, iPaaS, and MFT) that your enterprise automation strategy supports. Doing this is much more difficult if you have distinct responsibilities for the two disciplines.

• Holistic perspective of business and technology issues: an enterprise automation strategy, including an enterprise automation team owning and implementing the strategy itself, gives your organization a holistic view of the challenges you face and the solutions in place. Conversely, having distinct strategies and support teams will provide you with siloed, incomplete perspectives, thus making the planning, management, monitoring, and governance of integration and automation initiatives much harder. 

Tips for implementing a single, unified enterprise automation strategy

Aligning your integration and automation strategies may not be easy, especially in organizations that already have disjointed approaches established, maybe implemented by different units. In fact, the integration strategy is typically IT-owned, whereas the automation strategy may be a responsibility of a business team, for example, finance. 

This usually leads to the establishment of different support teams, often referred to as “centers of excellence” (CoEs). Therefore, to develop an enterprise automation strategy, it may make sense to progressively unify your integration and automation CoEs into an enterprise automation team (see: How many “centers of excellence” do you need to carry out enterprise automation?).

Furthermore, organizational, political, and technological factors can significantly hinder, if not completely prevent, the establishment of a unified enterprise automation strategy. However, depending on your situation, there are steps you can take to help your organization overcome these obstacles and adopt such a strategy successfully: 

• If you are in a green field situation, that is, you do not have a formalized integration and/or automation strategy, but you feel you are not yet ready for a holistic enterprise automation approach, you should consider:
  
  • Designing your automation strategy in such a way that it can take advantage of integration technology.  For example, by selecting automation tools that can:
    • also address integration needs (e.g., an iPaaS)
    • consume APIs and events exposed by third-party integration tools
      
  • Designing your integration strategy in such a way that it enables automation (along with assisting the other fundamental integration use cases: ensuring data synchronization and supporting composition). For example, by adopting integration tools, like iPaaS, that can also be used to orchestrate processes.

By applying the simple principles illustrated above, you will likely end up with maybe separately defined automation and integration strategies that, however, won’t be too difficult to align, combine, or even merge at some point. That is, if you start by defining an integration-aware automation strategy, it won’t be difficult to extend it also to address additional integration requirements. For example, if you have initially adopted an iPaaS as an automation enabler, you can also later use it for ensuring data synchronization and enabling API-based composition as you develop your integration strategy. Of course a symmetrical scenario holds true if you first establish an automation-aware integration strategy. 

• If you have already established distinct integration and automation approaches, consider the following:
  
  • Educate IT and business leaders on the notion that automation and integration are two sides of the same coin.
    
  • Show, through exemplary, real-life projects, how combining integration and automation skills and technologies lets you achieve better results in terms of efficacy, costs, and time to value.
    
  • Look for economies of scale by reducing technology and skill redundancies across the two disciplines (for example, the integration and automation teams may have adopted different low-code application platforms or API management platforms).

If you succeed in these three efforts, you will most likely be able to build consensus around kicking off an initiative that aims to combine the two distinct disciplines into an overarching enterprise automation strategy. And this, in my view, will help your organization address a wide range of end-to-end process automation and integration needs effectively and efficiently over the next several years.