In the “Are integration and automation two distinct IT disciplines?” article, we discussed how integration and automation are fundamentally two sides of the same coin. A coin that is called enterprise automation: a unified strategy that puts integration technologies and methods at the foundation, and automation as one of the key, integration-enabled use cases.
To implement an enterprise automation strategy at your organization, you’ll need to deploy a set of technologies capable of supporting the scenarios that are relevant to the business side of the house. We call this combination of technologies the Enterprise Automation Platform (EAP), which can be implemented by a single product, for example, an iPaaS, or, more often than not, by a combination or products, possibly from different providers (for example, an iPaaS, an RPA tool, and a managed file transfer suite).
However, selecting the right “building blocks” for your EAP requires you to respond to a number of questions:
1. What are the use cases you must support (application integration, data integration, process automation, B2B integration, IoT, mobile apps integration, API and events enablement, etc.)?
2. What are your non-functional requirements (in terms of performance, throughput, availability, security, compliance, etc.)?
3. What is the operating model you want to support? That is, who is expected to perform the enterprise automation work?
Answering the third question is critical as the technology platforms that compose your EAP must be aligned with the skills of the people who will actually do the work. For example, tools that are perfectly fine for highly-skilled IT engineers are probably not suitable for business technologists. You can select the best tool on the planet, but if it doesn’t fit with your team’s skillset, it’s not very useful. For example, I have seen many organizations adopt sophisticated enterprise service buses, maybe just because they were pushed by their business application vendor or system integrator partner, which proved to be overkill because of their excessively demanding skill requirements.
Deciding on the operating model you want to empower, therefore, is not a trivial issue and cannot be an afterthought. In fact, it should be one of the factors driving the selection of your EAP building blocks.
Having said that, what are the operating models you can choose from? Broadly speaking, there are three different options: federated (half-jokingly also referred to as “wild-west”), centralized, and democratized.
In a nutshell:
- Federated: delivery is directly performed by semi-independent local units (that is, functional teams, application teams, LoBs, subsidiaries, or departments) that use whatever enterprise automation tools they wish. There is some lightweight, central, organization-wide responsibility for an enterprise automation strategy.
- Centralized: an Enterprise Automation Team (EAT) is in charge of the strategy, selects the tools, and performs the necessary enterprise automation work on behalf of the local units.
- Democratized: delivery is carried out by the local units and, in the most extreme examples, even by individuals. The EAT is in charge of “empowering” these entities by providing them with technologies, training, support, and by enforcing governance “guardrails”
In a series of three articles (which we linked to above), we define these models a bit more precisely and discuss their pros and cons. However, let me anticipate the key takeaways:
- The model you decide to implement is not only a matter of organizational taste. It also depends on your organization’s business priorities and attitude to change, the skills at your disposal, and the perceived value of enterprise automation by your C-suite.
- If, taking into consideration these factors, you decide to adopt the federated or centralized model, you should still plan to transition to the democratized model as soon as possible to maximize agility—whilst minimizing compliance, security, and QoS risks.
One warning: In real-life scenarios, multiple operating models often coexist within the same organization for organizational or technical reasons. For example, a highly-dynamic, innovative, and fast-growing business unit may leverage the federated model, whereas other, more conservative business units prefer a centralized approach. In addition, small, low-skilled subsidiaries may want the EAT to centrally deliver enterprise automation processes for them, whereas the rest of the organization has fully embraced the EAT-enabled democratized model.
Such a plurality of models has costs and implications, but no model is necessarily “wrong” as long as it is motivated by solid business reasons and is properly managed.
Want to learn more?
This topic was covered extensively during one of our “Coffee with Massimo” monthly webinars. You can watch the session’s full recording to catch everything Massimo shared.
