In a federated scenario, the local units perform the enterprise automation work they need by leveraging their developers, or by hiring external consultants or system integrators.
These teams typically use whatever tools they deem most appropriate to meet the desired outcome. A classic example could be the team in charge of implementing a new cloud ERP application deciding to leverage the iPaaS provided by the ERP vendor in order to address the associated integration challenges.
Generally, there is no central responsibility for enterprise automation, although the enterprise architecture team, or some equivalent entity (for example, a proto-Enterprise Automation Team), provides recommendations in terms of “approved” tools and technologies. At times, the central IT department implements some sort of “support team” that can provide assistance for the approved tools and/or vendor management help. However, in general, the teams performing enterprise automation are very autonomous as far as the tools, technologies, and methodologies are concerned.
The pros of the federated model
This approach has its benefits:
- Agility and flexibility: Assuming a local team has the appropriate skills and budget readily available, they can start to engage in enterprise automation whenever they want. They don’t need to wait for some central resource to be available. Moreover, by having some freedom to choose their technologies, they can select the best-fit tool for the task.
- Short time to value: This is a direct consequence of the previous point. Application teams or LoBs often prefer to operate autonomously because of the stringent deadlines that come with delivering new systems. Therefore, they try to cut as many corners as they can. They perceive any tool that’s readily available and that they can use themselves to rapidly solve their enterprise automation challenges as a time-to-value accelerator for their initiative. For example, many SaaS applications provide pre-canned integration processes with popular third-party systems, which enables the implementation team to quickly, although not necessarily optimally, solve the problem.
- A focus on business outcomes: A local team’s effort is focused exclusively on delivering the new system—whether that’s a SaaS application, a data lake, or an end-to-end process automation—on schedule and on budget. No time is “wasted” on discussing alternatives with other teams that have little knowledge of the business issue or on sorting out political or organizational issues (such as, “Who does what?” or “Who is responsible for what?”). Every decision is made with a single goal in mind: the business outcome.
The cons of the federated model
While the federated approach has, as we have seen, notable benefits at the local level (that is, for the teams who need to address enterprise automation issues), it may also give rise to a number of organization-wide issues:
- Miopic focus on “local” needs: A local team’s total focus on their specific challenges prevents them from systematically learning from others—for example, in terms of best practices—, although this can still happen by word of mouth or through goodwill. This means the local teams risk duplicating efforts and rising costs.
- Rapidly escalating technical debt: If not properly managed, the federated model can turn into a chaotic wild-west. The local teams (or the consultants they outsource to) may build enterprise automation processes in a hurry, without a methodical approach, and by using whatever technology they are familiar with. Consequently, there’s often little-to-no documentation, whilst the person who originally developed these processes may have left the company or is working on other projects, perhaps at another part of the organization. Therefore, when it comes to updating or extending these processes, somebody else will have to figure out how they work and maybe re-implement them altogether. The ultimate outcome of such a chaotic model is a lot of rapidly-growing technical debt, which somebody (usually central IT) will have to pay for in the future.
- Duplication of technology and skills: Since individual local teams are given freedom to choose the tools they use, it’s almost certain that different teams will choose tools from different vendors. For example, different teams implementing SaaS applications may each adopt the iPaaS provided or recommended by the related SaaS providers, which inevitably necessitates building or hiring for the relevant skills. Hence, the organization ends up using three or four different iPaaS offerings that, most likely, overlap in functionality. Moreover, they must build three or four different sets of skills, which are not easily interchangeable.
- “Know how” development: In the federated scenario, it’s easy to underestimate the fundamental competencies needed to develop reliable, scalable, performant, secure, and compliant integration processes. A deep understanding of the intricacies and best practices of enterprise integration (patterns, error handling, recovery, data transformation, etc.) is difficult to develop if there’s no central coordination and orchestration.
Ultimately, in this scenario, enforcing the development process and data governance is very difficult, in many cases almost impossible. Development process governance is about deciding which enterprise automation issues to tackle, when, and how. Data governance has to do with how to manage the “systems of record” (that is, which system holds the customer, product, employee, etc. master data) and the propagation of sensitive, confidential, and invaluable data across multiple systems. Dealing with these issues requires a level of commitment and discipline, which is hard to achieve in a federated set up.
When should you adopt the federated model?
If your organization is growing quickly, and you have a significant number of developers available and spread across multiple semi-independent units, then a federated approach—despite all its drawbacks—may be suitable. This is especially true if time-to-value and business agility are critical for the business.
However, you should put measures in place that minimize technical debt build up, keep costs under control, and enforce development process and data governance. To this end, I would highly recommend that you plan to migrate to the democratized model (local units perform the work, but they are enabled and supported by a central team) after no more than a few years of the federated approach. If you stick with this model for a longer stretch of time, you risk ending up with thousands of costly enterprise automation processes that your teams have little understanding of, and which are, therefore, difficult to manage and change. As a result, the much-coveted business agility goes down the drain and your costs go up.
