How to implement enterprise automation through incremental approaches

An effective enterprise automation strategy can play a critical role in differentiating your organization from competitors. 

However, the process of executing such a strategy isn’t so simple and it can’t happen overnight.

You’ll need to review the two components that make up your strategy (your enterprise automation platform and your enterprise automation team), and you’ll need to take incremental steps in implementing each—in parallel. 

I’ll help you navigate this exercise by reviewing the makeup of an enterprise automation platform and an enterprise automation team as well as covering the steps involved in executing both via stepwise approaches.

Establishing your enterprise automation platform

An enterprise automation platform (EAP) is a combination of integration, automation, and governance technologies designed to address a number of integration and automation use cases, whether that’s application integration, data integration, process automation, API publishing, B2B integration, event brokering, etc. Moreover, your EAP must be able to support multiple “personas”: professional integration specialists, application developers, SaaS administrators and, in some cases, business technologists (that is, business users with some IT skills).

Depending on your requirements and use cases, your EAP could be implemented with one platform (typically an iPaaS) or through a combination of tools (e.g. iPaaS, API management, and managed file transfer), possibly from different vendors.

The figure below illustrates what an ideal, comprehensive EAP looks like.

Even if you may not need all the capabilities illustrated in the figure above, providing such an extended technology architecture necessitates taking the following steps: 

1. Identify your needs 

Start by reviewing your existing integration and automation technologies with an eye on determining those that are still useful, others that are obsolete (or soon to be obsolete), and any that can be deemed as redundant. Then, identify your business priorities, the new initiatives you must support, and emerging requirements that are likely to manifest over the next 18-24 months. From there, you can use the figure above as a reference in deriving a list of the EAP capabilities you need (and don’t need), and you can perform a gap analysis to determine the incumbent tools you’ll continue to leverage and the ones you’ll have to acquire to support the new requirements. 

2. Fill the gaps

At this stage you can go ahead and try to eliminate all of the redundant and obsolete technologies you identified. This may not be possible right away, perhaps because you have dozens of legacy integration processes running on them, but it’s important that you avoid adding new processes— assuming they’re not absolutely needed—and define a sunsetting strategy.

At the same time, you can start to pragmatically select the integration and automation tools you need to fill the functional gaps. For example, if you’re running a lot of your applications on the cloud (i.e. SaaS applications) and your incumbent integration platform fails to integrate them effectively because it runs on-premises, you may look to buy an iPaaS; or perhaps you’re looking to venture into the API economy and expose APIs that your business partners can consume, in which case you may choose to invest in an API management platform.

3. Deploy

Finally, you can go ahead and assemble your enterprise automation platform by both reusing the tools you already have and that are still relevant and by incorporating the ones you’ve just acquired, possibly in a gradual, initiative-by-initiative fashion.

Note: This series of steps will have to be repeated periodically in order to progressively extend your EAP with the technologies that are required to address new enterprise automation use cases (e.g. IoT integration or event brokering).

Developing your enterprise automation team

The enterprise automation team (EAT) is not only tasked with designing, implementing and providing the enterprise automation platform—they also strive to enable functional teams, line of businesses, departments, subsidiaries, and individuals to build integrations and automations themselves*. The EAT can achieve this by providing best practices, guidance, support, and by enforcing  appropriate guardrails and governance policies so that data and processes remain secure, compliant, and high quality.

Note: Even when the democratized approach has been enabled and widely adopted, there are a few circumstances whereby it makes sense for the EAT to continue delivering enterprise automation projects. This includes scenarios such as an enterprise automation project extending across lines of business and a specific business unit lacking the skills or the capacity to build enterprise automation processes by themselves (and therefore needing support).

As more and more functional units, LoBs, departments, subsidiaries, and individuals implement enterprise automations by themselves, the need to have them collaborating grows. In response, your EAT should foster a “community of practice”, where enterprise automation “builders” from different units and with different skills can share best (and worst) practices, outline specific success stories, and discuss ideas for improving their methodologies and the enterprise automation platform itself. This ultimately benefits all parties: The EAT can iterate and improve upon the methods and the platform, while the community of practice members can become more efficient and deliver more impactful enterprise automations over time.

The EAT and community of practice stand in stark contrast to the classic integration and automation center of excellence (CoE) approach. In the latter, the CoE owns both the strategy and the delivery of integrations and automations—inevitably leading to organizational bottlenecks, long delivery timelines, and frustration, both from the CoE and the CoE’s “clients”.

So, how do you go about creating an enterprise automation team? It also involves a series of steps:

1. Centralize

Centralize all of your integration and automation solution architects, technology specialists, and developers so that they’re working together. From there, you can task them with developing and refining their skills and best practices, and have them take on projects “on-demand”, whereby anyone within the organization can reach out and request integrations and automations. In other words, in this phase, your EAT acts as a classic CoE, or an integration and automation factory. At the same time, however, the team should start to design their EAP, crystallize and document their best practices, and set up the enablement services.

Only once the EAT has developed the EAP, honed their skills, and implemented the enablement services, you’re ready to move on to the next step.

2. Distribute

The EAT is now conceptually divided into two parts: One focuses on the strategy, while the other provides centralized delivery (the “factory”). All the while, the team is now proactively reaching out to functional teams, LoBs, application teams, departments, and subsidiaries to offer enablement services. Any entity that takes up the offer can be enabled to design and deliver enterprise  automations autonomously, while still being supported by the EAT.

At this stage, the EAT is also focused on collecting, consolidating, formalizing, and sharing best practices, as well as defining and enforcing governance policies—with an eye towards facilitating distributed delivery. Moreover, the EAT is starting to aggregate the community of practice, collecting their feedback and requirements, and discussing future plans with them. 

However, at this stage, business technologists are—in general—not supported.

3. Self-service

The enterprise automation team is now fully enabling integration developers/specialists within LoBs and business technologists via training, documented best practices, support, and a self-service EAP. The EAT is also institutionalizing and running the community of practice so that builders can share experiences and learn from one another as soon as possible. 

This third step is probably the most complex to implement, given the problem of dealing with non-IT people who may enthusiastically embrace the technology but require extensive support and extra attention.

Why going through these incremental steps is critical

I like to think of an enterprise automation strategy as falling into one of five buckets: no strategy, opportunistic, centralization, distribution, or self-service.

The first two buckets (no strategy and opportunistic) prevents your organization from reaping the benefits of integration and automation. In other words, you won’t be able to innovate and transform your business processes, leverage real-time insights to make timely, business-critical operational decisions, and provide improved customer or employee experiences. The clear victim of the No Strategy and Opportunistic approaches is definitely business agility. Changing business processes, for example, can be very, very complicated if you have to untangle a massive integration “spaghetti”. Therefore, you should plan to at least move to the third bucket, which would safely align your organization with the industry average.

That said, it’s when you reach the distribution and self-service stages that your organization can truly set itself apart and build a long-lasting competitive advantage, as those stages enable superior business agility and the ability to innovate across the entire organization.

Now it’s your turn: See where your organization currently stands within the five buckets above, and, using the steps outlined throughout this article, see if you can advance your enterprise automation platform and your enterprise automation team.