In my experience, the federated and centralized enterprise automation delivery models are the most popular. Neither is intrinsically right or wrong: The benefits of one model are compelling for certain organizations, but not for others (and vice-versa).
However, when CIOs and IT Leaders adopt either of these models, they must be fully aware of their fundamental issues:
- Lack of (or, at least very hard to enforce) governance for the federated model
- Lack of agility (at a reasonable cost) for the centralized model
The democratized model is probably less common, but it is definitely the one that is—based on my experience—growing faster in adoption because it tries to overcome the issues of the other models. The basic tenets are that local units or, in the most extreme examples, individuals, carry out delivery, while a central enterprise automation team (EAT) is in charge of “empowering” these entities. The EAT can do so by providing them with technologies, training, support, and by enforcing some form of lightweight development process and data governance “guardrails”.
Although the first examples of democratized enterprise automation delivery date back to the early 2010s (or even earlier), it was approximately in 2016-2017 that adoption started to gain momentum. Large organizations, such as Adobe, Heineken, Marks & Spencer, P&G, Roche, and Unilever, and midsize companies, such as FreeNow, Sunpower and Workato, have successfully implemented this model. Many more “democratization” initiatives are well underway at both large and midsize organizations across the globe. In many cases, organizations are moving to the democratized model from a centralized approach, but at times they are also coming from some form of federated model.
The reason CIOs and IT leaders are moving towards the democratized approach is that they can leverage the agility benefits of the federated approach, whilst reducing the associated risks by injecting some of the centralized model’s principles.
We can think about democratized delivery as “governed federated model”: enterprise automation delivery is carried out by local units and individuals by leveraging the enablement capabilities provided by a central EAT, which include:
- An enterprise automation platform (EAP), that is, an integrated set of tools capable of supporting multiple scenarios and personas (hardcore specialists, application developers, SaaS administrators, and business technologists). The EAT usually provides the EAP as an infrastructure that’s shared across all the local units and entitled individuals. The EAT is also in charge of managing the platform’s life cycle.
- Enablement services, such as advocacy, training, mentoring, consulting and support
- Appropriate governance “guardrails” to preserve security, compliance, and QoS
- “Best practices”, which the EAT collects, engineers, and shares in the form of documents, videos, training courses, and pre-packaged templates.
Ultimately, the EAT is positioned as a “service provider” for local teams and individuals. As such, it is constantly sharing new EAP features and bug fixes with “clients” in the local units, as well as new services, plans, and best practices. At the same time, the EAT collects feedback, requirements, complaints, and success stories. At times, the organizational vehicle leveraged to maintain bi-directional communication is an enterprise automation community of practice (that is, a forum where the EAP’s users and the EAT meet regularly to network and learn from each other).
The pros of the democratized model
If implemented and supported properly (admittedly a big if) the democratized model can really be the best of both worlds as it enables agility (as in the federated approach), but minimizes the risks of compromising compliance, security and quality of service (like in the centralized approach).
Let’s take a closer look at it benefits:
- Agility is supported because, like in the federated model, the local units (and even the individuals) can freely use the EAP to address their specific enterprise automation issues when they wish, and without needing to wait for EAT resources to be available to them.
- Governance can be enforced because the EAP, if correctly designed and engineered, can give the EAT full visibility on the processes that the local units and individuals design, deploy, and run on the platform. Moreover, the EAT can enforce the desired governance guardrails by properly configuring the EAP (for example, by only allowing selected users or roles to access certain critical capabilities of the platform), and by educating users about these guardrails via the shared best practices, training sessions, mentoring programs, and consulting services.
Moreover, the EAT can facilitate cross-functional enterprise automation implementations, which is very hard to achieve in a federated model. As a neutral support function, the EAT can also help get buy-in from all the interested parties, govern the change management processes, and help resolve conflicts and trade-offs.
- Technology investments can be optimized. Given that the EAP is designed, engineered, and deployed by the EAT, they have the opportunity to incorporate an optimized set of technologies into the platform, which avoids, as much as reasonable, duplicated products and redundant functionality. Thus, they’re able to minimize costs and support skills, while maximizing functional coverage.
The cons of the democratized model
Alas, implementing a democratized enterprise automation model is not a walk in the park. This complexity is exacerbated by the fact that only a few IT consulting firms and service providers have portfolio services that can help you. This is, expectedly, a temporary issue that will be sorted over time as demand grows and service providers gather knowledge and experience. However, a few other obstacles will prove harder to overcome:
- Learning curve: It takes time to transition from a federated or centralized model to the democratized approach. For example, if you are in a federated scenario, you have to create the EAT almost from scratch, and they will have to work hard to build up the necessary skills and credibility, which takes time. If you have been following a centralized approach, then you can spring your EAT out of your established “integration factory”. However, this requires some serious change management, as they must transform themselves from a “development team” to an “empowerment service”, which is hard. For example, some of your EAT developers may not be willing to turn into “support people”.
- Organizational resistance: No matter how good your EAP and how effective your EAT are, the units will inevitably look at the new approach with skeptical eyes. In my experience, it is much more difficult for organizations starting from the federated approach to accept and endorse the new model, as they may perceive it as red tape. Usually, organizations in a centralized situation are more positive, because the new approach gives them more freedom of action. However, some units may feel they do not have the needed skills or not enough enterprise automation requirements to justify the investment to build their own delivery capability. The need to support these laggard units is one of the reasons why most democratized model implementations are forced to continue to provide a relatively small centralized “factory” service.
- Inefficient allocation of skills: In the democratized model, the assumption is that the units have the skills needed to use the EAP themselves. Most likely the EAT has included technologies in the platform that do not require a PhD in computer science, but the local units must still invest some time and effort into building these skills through the training and mentoring services provided by the EAT. Chances are that, at a certain moment in time, a local unit’s enterprise automation skills are very busy or even overloaded, whereas in other units they are sitting idle. Of course, with a bit of goodwill and coordination—through the EAT—, these resources can be moved around, but this non-optimized allocation of skills is yet another issue the EAT must tackle.
When should you adopt the democratized model?
In general, I’m a fan of the democratized model, which, I believe, all organizations should eventually adopt, or at least discard only after carefully evaluating its pros and cons. In my view, by implementing this model, you can achieve the combination of agility and lightweight control that’s needed to support ambitious IT strategies, such as digital transformation, hyper automation, application modernization, API economy, and the composable enterprise.
You may even, legitimately, ask yourself whether it’s realistic to implement the democratized model in a large and complex organization. There are many positive examples and case studies that show it is indeed possible. However, to a certain extent, the democratized model has analogies with how lean manufacturing and Six Sigma skills were spread across enterprises in the 80s and 90s. Quality improvement was successfully democratized at that time by the creation of standardized tools (Six Sigma, Lean, Theory of Constraints), a democratized approach to develop “black-belt” skills across the organization, and a mandate to move the projects close to the business instead of being run by a centralized QA function. This created rapid scale while ensuring there were standards that could be governed centrally.
Admittedly, however, implementing the democratized model requires a high level of technical knowledge and organizational maturity. Therefore, it is totally understandable if you find it more comfortable to start your enterprise automation effort by implementing a centralized model.
You may have ended up in a de facto “chaotic wild-west” situation, not because somebody actually decided to go down that path. It just happened since nobody at your organization has ever looked at enterprise automation strategically. Local units needed to sort out enterprise automation issues urgently, and so they just did it by using the skills and technologies they had available or could easily have access to (for example, open source or cloud-based integration or BPM tools).
However, if your wild-west setup is spinning out of control, or if your centralized approach is hampering your organization’ business agility, then you should start planning the transition to the democratized model. To facilitate this effort, you can begin speaking with the business leaders, educating the C-suite, taking inventory of your technologies and skills, and deciding on the steps that you need to take to get to a democratized model (see: “How to implement enterprise automation through incremental approaches”).
Even if your current set up seems “good enough” for the next two or three years, it’s not a valid reason to rest on your laurels. Adopting the democratized approach is an incremental journey. It can take you months or even years to complete the transition. Don’t waste precious time and risk missing the boat. Just kick it off sooner rather than later!
