{"id":2250,"date":"2026-03-17T17:01:53","date_gmt":"2026-03-17T21:01:53","guid":{"rendered":"https:\/\/blog2wrkdev.wpenginepowered.com\/are-integration-and-automation-two-it-disciplines\/"},"modified":"2026-09-30T08:21:52","modified_gmt":"2026-09-30T12:21:52","slug":"are-integration-and-automation-two-it-disciplines","status":"publish","type":"post","link":"https:\/\/blog2workato.wpengine.com\/are-integration-and-automation-two-it-disciplines\/","title":{"rendered":"Are integration and automation two distinct IT disciplines?"},"content":{"rendered":"\n

One of the most used and abused buzzwords in the IT industry these days is \u201cautomation\u201d (often associated with another popular buzzword: digital transformation). <\/p>\n\n\n\n

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 \u201cautomation\u201d is increasingly associated with \u201cintegration\u201d. <\/p>\n\n\n\n

For example, several vendors, traditionally established in the integration technology market, are repositioning themselves as integration + automation providers\u2014typically because they recently added an RPA tool to their product portfolio.\u00a0<\/p>\n\n\n\n

So, how should you think of automation and integration? And how do these two disciplines relate to each other? <\/p>\n\n\n\n

In this blog post, I\u2019ll 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.<\/p>\n\n\n\r\n

\r\n\t\t
\r\n \"\"\r\n
\r\n

Want to learn more from Massimo?<\/h4>\r\n

You can watch his webinar, Automation vs. Integration OR Automation + Integration. for additional insights on the relationship between integration and automation.<\/p>\r\n <\/div>\r\n\t\t\t\t Watch webinar recording<\/a>\r\n\t\t\t\t <\/div>\r\n\t\t <\/div>\r\n\n\n\n

What is \u201cautomation\u201d?<\/h2>\n\n\n\n

According to the Oxford Learner\u2019s Dictionary<\/a>, \u201cautomation\u201d means: \u201cthe use of machines and computers to do work that was previously done by people<\/strong>\u201d. From that perspective, therefore, most IT applications are indeed about \u201cautomation\u201d. <\/p>\n\n\n\n

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. <\/p>\n\n\n\n

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).<\/p>\n\n\n\n

This classic form of automation is typically siloed within individual organizational units (finance, HR, sales, procurement, supply chain, manufacturing, etc.). <\/p>\n\n\n\n

However, for many years now, organizations have been using integration technology, such as ESBs or ETL<\/a> tools, to synchronize data across different applications, thus implementing a rudimentary form of cross-unit process automation.<\/p>\n\n\n\n

Integration technology to ensure data synchronization across siloed applications<\/strong><\/p>\n\n\n

\n
\"Integration<\/a><\/figure>\n<\/div>\n\n\n

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. <\/p>\n\n\n\n

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. <\/p>\n\n\n\n

This mandates you to modify the relevant applications, which is hard, expensive and, at times, close to impossible.\u00a0<\/p>\n\n\n\n

In the old days of packaged application software, if you had deep enough pockets, you could hire an army of consultants and \u201ccustomize\u201d the application so that it adjusts certain processes to your specific needs. <\/p>\n\n\n\n

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<\/a> application\u2019s code. <\/p>\n\n\n\n

In truth, SaaS providers allow some degree of customization, but\u2014in most cases\u2014within well-defined and often quiet stringent constraints. In any case, modifying the application code is forbidden. <\/p>\n\n\n\n

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). <\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Moreover, realistically, no single suite can actually support the full set of requirements of a real-life organization. <\/p>\n\n\n\n

Therefore, user organizations often buy or build \u201csatellite\u201d applications to fill the functional gaps of these mega-suites. This, and the suites\u2019 limited flexibility, has led to a new, end-to-end model of automation.\u00a0<\/p>\n\n\n

\n
\"<\/a><\/figure>\n<\/div>\n\n\n

According to this model, you shouldn\u2019t look at applications\u2014packaged, SaaS, and homemade\u2014as purely set-in-stone collections of business process silos.<\/p>\n\n\n\n

You should now consider your application portfolio as a portfolio of business capabilities, exposing APIs<\/a> that can be orchestrated via an external automation layer (for example, implemented via a BPM tool, a low-code application platform, or an iPaaS). <\/p>\n\n\n\n

And, in the event that an application doesn\u2019t have APIs, you can use an RPA tool or another \u201cscreen-scraping\u201d technology to expose APIs out of your non-API enabled system.\u00a0<\/p>\n\n\n\n

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. <\/p>\n\n\n\n

These processes are often cross-functional, for example, spanning across your finance, HR, and customer service or procurement, supply chain, and manufacturing functional units.<\/p>\n\n\n\n

In short, as a progressive CIO or IT leader, you wish to buy siloed applications that automate certain aspects of your organization\u2019s processes. <\/p>\n\n\n\n

You also, and most importantly, want to rapidly automate complex\u2014often interfunctional\u2014end-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. <\/p>\n\n\n\n

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.\u00a0<\/p>\n\n\n\n

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). <\/p>\n\n\n\n

Finally, to complete the automation picture, in an increasing number of cases, these business processes will also involve \u201cmachines\u201d (e.g., 3D printers, drones, industrial robots, etc.) to perform certain activities that deal with the \u201cphysical\u201d world. For example, this can be a drone that delivers your company\u2019s products to customers in rural areas as part of your \u201corder-to-cash\u201d process.<\/p>\n\n\n\n

What is integration and what is its relationship with automation?<\/h2>\n\n\n\n

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, \u201cremove manual activity from\u201d) a process.<\/p>\n\n\n\n

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).\u00a0<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

This is where integration technology plays a critical role. <\/p>\n\n\n\n

Integration technology, according to its widely adopted definition, is used to \u201dmake independently designed systems work together.\u201d <\/strong><\/p>\n\n\n

\n
\"it<\/a><\/figure>\n<\/div>\n\n\n

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. <\/p>\n\n\n\n

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. <\/p>\n\n\n\n

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, \u201cindependently designed systems”.\u00a0<\/p>\n\n\n\n\n\n

Modern, end-to-end, multichannel automation enabled by integration technology<\/strong><\/p>\n\n\n

\n
\"Modern,<\/a><\/figure>\n<\/div>\n\n\n

The bottom line is that the modern, end-to-end model of automation requires integration. Automation is the goal, integration is the means. <\/p>\n\n\n\n

It doesn\u2019t make a lot of sense to have an automation strategy without a closely aligned and coherent integration strategy. <\/p>\n\n\n\n

Vice versa, an integration strategy that\u2019s not designed to support automation needs is poor and incomplete\u2014as every organization in the world wants, and needs, to automate at least some of its processes.<\/p>\n\n\n\n

Consequently, your automation and integration strategies should be designed together as two sides of the same coin. <\/p>\n\n\n\n

I refer to this coin as \u201centerprise automation\u201d, 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).\u00a0<\/p>\n\n\n\n

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<\/em><\/a>). <\/p>\n\n\n\n

But an enterprise automation strategy also offers IT-related benefits:\u00a0<\/p>\n\n\n\n

Clear set of goals<\/strong><\/h3>\n\n\n\n

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. <\/p>\n\n\n\n

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).<\/p>\n\n\n\n

1. Synergies<\/strong><\/h3>\n\n\n\n

You can use your integration technologies and skills to also support automation\u2014saving your organization money and time.<\/p>\n\n\n\n

2. Optimization<\/strong><\/h3>\n\n\n\n

When addressing a new challenge, you can use the right technology and associated skills (as opposed to using a potentially wrong tool because it\u2019s the only one you know about).\u00a0<\/p>\n\n\n\n

3. Greater ability to tackle complex scenarios<\/strong><\/h3>\n\n\n\n

These scenarios may require a combination of automation and integration technologies (for example, RPA, iPaaS, and MFT<\/a>) that your enterprise automation strategy supports. Doing this is much more difficult if you have distinct responsibilities for the two disciplines.<\/p>\n\n\n\n

4. Holistic perspective of business and technology issues<\/strong><\/h3>\n\n\n\n

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. <\/p>\n\n\n\n

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.\u00a0<\/p>\n\n\n\n

Tips for implementing a single, unified enterprise automation strategy<\/h1>\n\n\n\n

Aligning your integration and automation strategies may not be easy, especially in organizations that already have disjointed approaches established, maybe implemented by different units. <\/p>\n\n\n\n

In fact, the integration strategy is typically IT-owned, whereas the automation strategy may be a responsibility of a business team, for example, finance.\u00a0<\/p>\n\n\n\n

This usually leads to the establishment of different support teams, often referred to as \u201ccenters of excellence\u201d (CoEs). <\/p>\n\n\n\n

Therefore, to develop an enterprise automation strategy, <\/em>it may make sense to progressively unify your integration and automation CoEs into an enterprise automation team (see: How many \u201ccenters of excellence\u201d do you need to carry out enterprise automation?<\/a>).<\/p>\n\n\n\n

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: <\/p>\n\n\n\n

If you are in a green field situation<\/strong><\/h3>\n\n\n\n

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:<\/p>\n\n\n\n

    \n
  1. Designing your automation strategy in such a way that it can take advantage of integration technology.\u00a0 For example, by selecting automation tools that can:\n