The centralized model is probably the most popular, especially by midsize and “buy oriented” large organizations. The basic principles are quite simple: Recognizing the complexity of the challenge, organizations decide to centralize the responsibility of enterprise automation in order to optimize the technology portfolio and build up critical mass in terms of skills.
In essence, enterprise automation is centrally delivered by an Enterprise Automation Team (EAT) that’s fully in charge of the strategy, which includes selecting the appropriate set of tools. The EAT also acts as an “enterprise automation factory” (the strategy and factory aspects are at times the responsibilities of two distinct, albeit related, teams). When local teams have an enterprise automation issue to tackle, they “outsource” the implementation of the needed capabilities to the EAT. The local teams define what they need and the EAT provides the solutions.
In real life though, organizations often have more than one CoE, typically specialized by use case. For example, they might have a process automation CoE, an application integration CoE, a data integration CoE, and an API CoE, which of course complicates the matter (see: “How Many ‘Centers of Excellence’ Do You Need To Carry Out Enterprise Automation?”).
The pros of the centralized model
The centralized model is attractive to many CIOs and IT Leaders because of its benefits:
- Efficiency: A centralized “enterprise automation factory” can, overtime, become quite efficient. Enterprise automation is what they do day in/day out. Therefore, they get more and more familiar with the tools at their disposal, develop their own approaches and methodologies, learn a growing number of best practices, and develop reusable templates. Anecdotally, I have seen EATs improve their productivity quite significantly, in some cases up to 50%—just in their first year of operation.
- Economies of scale in technology and skills: An EAT will naturally try to avoid duplicate and overlapping technologies whenever possible. Although adopting a single enterprise automation tool would be unrealistic in most cases, the EAT can at least reduce the number of different products to what is strictly needed. This can help reduce, or at least keep under control, the EAT’s costs in terms of software licenses, maintenance, and cloud subscriptions, which in turn helps to contain the spread of skills. Moreover, by making those skills a shared resource, the chances of them sitting on their hands because of a lack of demand is minimized.
- Strong focus on governance and control: The EAT is the only enterprise automation factory in the organization. Therefore, they can apply consistent security, compliance, and quality of service policies across all the processes they implement. Similarly, they can adopt naming conventions, standardized patterns, reusable templates, and other mechanisms aimed to enforce development process and data governance policies. Moreover, the EAT can keep track of all the processes they implement, manage their life cycle, monitor their execution, and maintain and support them, thus having full control of the overall enterprise automation environment.
The cons of the centralized model
Although quite rational and optimized, the centralized mode isn’t immune to issues:
- Organizational bottlenecks: If the EAT is perceived as a capable and reliable factory, chances are that the demand for its services will grow to the point that it cannot respond to all the incoming requirements in a timely way. Thus, it has to set up bureaucratic processes and procedures to manage and prioritize the inflow of requests. In other words, at least in peak times, the EAT may become an organizational bottleneck, which would be the antithesis of the much-coveted business agility.
- Long time to value: No matter how efficient and large the EAT is, it will inevitably prioritize the most critical, impactful, or strongly-sponsored requirements, whilst second-tier needs will be postponed, perhaps indefinitely. This may lead to a long time-to-value for business initiatives that are associated with these second-tier requirements, which, in turn, generates frustration in the business side of the house and a no-holds barred fight over access to the EAT’s resources across different local units.
- Mostly targeting “enterprise” needs: The inevitable focus on the most critical requirements will imply that the EAT tends to target the most advanced “enterprise” class requirements, both in their tools selection and in the skills they’re building and hiring for. Therefore, the risk is that “local” requirements will be considered “second class” citizens that the EAT only addresses in their spare time. Moreover, since the EAT’s toolset is focused on the most demanding scenarios, it may prove to be “overkill” for these local, (often) less complex requirements. For example, this is what many RPA or classic ESB users are experiencing in situations where a low-code application platform or an iPaaS would be more suitable.
In the end, the main issue of the centralized model is its intrinsic lack of agility. It works fine when it comes to addressing end-to-end, enterprise-wide, enterprise automation requirements, but it’s not the ideal approach to support local, let alone individual, needs, which are often time-constrained and aren’t necessarily hyper complex.
When should you adopt the centralized model?
There are a couple of situations where the centralized model is a good fit, at least as a starting point:
- If your application portfolio mostly consists of packaged business/SaaS applications, you may have a significant number of application specialists, but a limited amount of enterprise automation skills scattered across different application teams. Therefore, it is more efficient to make these skills a shared resource.
- If your organization is concerned about costs, governance, and compliance, a centralized setup allows you to exert maximum control.
The federated model, discussed in a separate article, and the centralized models represent radically diverging ways of addressing enterprise automation requirements and needs, which reflect the different culture, skills, and business priorities of the organizations adopting them.
However, in real life, many organizations, even if they are formally committed to the centralized model, end up implementing a model somewhere in between the two extremes. In effect, very few, if any, large organizations are fully centralized. For example, the most technically astute local units may decide to bypass the EAT to speed up time to value or because they have very specific needs that the EAT cannot address. Even in the most tightly-controlled scenarios, the centralized model coexists with pockets of the federated approach.
This means that, in many cases, the theoretical centralized setup is a temporary state, because the only way for the EAT to regain some form of control over these pockets of the federated model is to move toward a democratized approach (local units perform the work, which is enabled and supported by a central team).
