In conversations with CIOs and other IT leaders, I often find that they are supporting their enterprise automation needs via a plurality of centers of excellence (CoEs), each typically focused on specific use cases or technology platforms. While this set up makes sense in terms of organizing resources and skills, a more cohesive approach is more effective and provides greater long-term benefits.
In this blog post, I’ll explain why having multiple CoEs can be harmful and why a single enterprise automation CoE is, in fact, often the best approach. But first, let’s take a step back and discuss the role of a CoE and explore why many organizations have ended up with multiple CoEs.
The changing role of an integration and automation CoE
In many organizations, a CoE is essentially an integration or automation “factory”, that is, a team of analysts, architects, and software engineers who are totally focused on addressing specific integration issues on behalf of the entire organization. Its primary role is to help other IT teams or business teams deliver integration processes. For example, the application leader in charge of a new digital commerce initiative would “outsource” the design, development, delivery, and on-going maintenance of the necessary integration processes to the CoE. Or the leader of an ERP modernization initiative would “hire” CoE integration architects and engineers to help tackle the associated automation challenges. This approach, which I call the “centralized model”, can be highly efficient, but it inevitably becomes an organizational bottleneck, as multiple teams compete for the—by definition—scarce resources of the CoE. This may lead to frustration, project delays, and attempts to cut corners, to the point that in some organizations, “integration CoE” has become a bad word.
More recently, a different perspective of the CoE role has emerged, which positions it as a “facilitator”. In other words, rather than a factory providing skills and ready-to-deploy integration processes, the CoE is established as a product team delivering an integration and automation platform consisting in technologies and a set of empowerment services (training, consulting, support, best practices, governance, etc.). The mission is to enable application teams, LoBs, departments, subsidiaries, and even individual “business technologists” to perform integration and automation work by themselves without necessarily needing to wait for the CoE’s resources to become available. This approach, which I qualify as “democratized”, is increasingly gaining traction because it offers an intrinsically more agile and business outcomes-oriented attitude than the centralized model. In fact, a “democratized CoE” is often not called a “CoE” at all; instead, it often takes the form of other names that attempt to capture its new role, such as an “empowerment team”, “center for enablement”, “business integration team”, among other imaginative names.
The democratized model is what I recommend to user organizations, but I also recognize that many of them are still adopting the centralized approach. Therefore, I tried to keep this article as neutral as possible with regards to the actual role of the CoE (factory or enabler).
Related: How to design an integration and automation strategy
For historical reasons, having multiple integration and automation-related CoEs was just a fact of life
Integrating applications and data, as well as automating business processes, dates back to the early days of the computing era. However, it was only in the late 1990s/early 2000s that I started to observe the first efforts to systematically address integration and automation challenges, typically in the wake of major enterprise-wide initiatives such as B2B/EDI, ERP, and data warehouse/master data management. This often led to the establishment of B2B, application, and data integration CoEs—see Note 1.
In most cases, the B2B integration team, the application integration team, and the data integration team remained separate and independent organizational entities within the central IT department. Since the technology they leveraged and the use cases they addressed were apparently so different, looking for synergies between them seemed like a futile exercise.
Over time, the number of CoEs has kept increasing, driven by new technology requirements (e.g. business process management, cloud, mobile, API, IoT, events), organizational inertia, and business factors, such as mergers and acquisitions.
These CoEs typically implemented the centralized model and reported to the central IT organization, which at least provided some, if minimal, consistency in governance and vendor management. Exceptions to this rule, however, were not uncommon (for example, the B2B integration team and the API CoE often reported to business leaders), thus undermining even such a minimal consistency. The proverbial straw that broke the camel’s back were RPA initiatives, where CIO involvement was often limited. Unsurprisingly, RPA led to the establishment of dedicated CoEs, often reporting to a business leader, for example the CFO.
The obvious consequence is that many organizations now find themselves entangled in a cobweb of integration and automation “CoEs”, maybe some centralized and some at least partially democratized. Moreover, they are in some way related, but scarcely coordinated, and, needless to say, often competing for recognition, project ownership, and budget.
The three issues stemming from multiple CoEs
Alas, in most cases, the proliferation of CoEs has created a number of issues.
Don’t get me wrong. I’m not saying that having multiple CoEs is “bad” per se and should be avoided at all costs. There are situations where it makes sense, especially in the early stages of adopting a new technology (for example, RPA). However, I want to draw your attention to the potentially negative implications of multiple CoEs, as they—in most cases—outweigh the benefits.
Broadly speaking, there are three main issues associated with multiple CoEs:
- Efficiency: As more organizations adopt digital strategies, they find that in the context of individual projects, they face a mix of integration and automation challenges. For example, a customer experience modernization initiative implies sorting out a complex combination of application, data, process, API, and possibly even IoT integration issues. Coordinating the work of three or four CoEs that have no common methodology, approach, and architectural tenets is highly inefficient and may lead to suboptimal outcomes as nobody owns and understands the integration and automation “big picture”.
- Effectiveness issues: In some cases, it’s not totally obvious whether a certain integration issue belongs to an application, data, process, or API domain. Because of this uncertainty, the task of addressing the issue may be assigned to the “wrong” CoE, which, for example, happens to have more available budget or skills than others, perhaps momentarily. Such an opportunistic approach often leads to an ineffective use of the technology mastered by that particular CoE. For example, I have seen RPA tools used to screen scrape applications instead of leveraging their rich set of APIs. I’ve also stumbled upon data integration tools being used to enable real-time application-to-application integration.
- Cost issues: The proliferation of CoEs inevitably entails duplicate skills (team managers, solution architects, integration and automation developers, testing engineers, etc.) and significant organizational overhead (decision management, escalation and conflict resolution processes; budgeting and cost allocation, etc.). Moreover, there’s often unnecessary, undesirable, and costly duplicates of technologies and platforms (see Note 2).
However, as mentioned earlier, the multiple CoEs approach is not all bad as it also has benefits. It allows each COE to become real experts on their technology and to have full accountability for project success or failure. Furthermore, over time, each CoE develops a set of fine-tuned best practices that make them very efficient.
Related: A look at different types of integration and automation platforms
Is a single enterprise automation CoE the way to go?
In my opinion (and, I repeat, this is just my opinion), the simple answer is yes.
Let me clarify one point: when I say a single CoE, I don’t necessarily mean a single team providing any kind of integration and automation work to the entire enterprise. The organizational model could be more sophisticated than this. For example, a central CoE can enable and support multiple integration and automation delivery teams at the LoB level according to the democratized model. What’s really important is that there’s a single responsibility in terms of strategy, architecture, governance, operations, and delivery model. This is what I really mean when I talk about “single enterprise automation CoE” in this post.
Let’s assume you have a single “enterprise automation CoE” that’s in charge of (and enabled to support) the full spectrum of integration and automation needs (application, data, process, mobile and IoT integration, APIs, events, etc.). As said above, this CoE is responsible for strategy and governance, includes solution architects and project managers, and makes sure all the technologies used can work together and are monitored, managed, operated, and secured in an integrated way. The CoE also includes developers and technology specialists who can participate in enterprise automation projects and/or empower, train, and assist developers in other teams to enable the democratized model.
Using this model, your organization can benefit in the following ways:
- Efficiency: When a new use case comes up, the enterprise automation CoE can immediately take ownership. They can decide on the most effective approach, figure out the best way to implement it (maybe by using multiple technology platforms), and marshal the appropriate skills and resources to deliver the end-to-end solution.
- Effectiveness: The enterprise automation CoE has at its disposal a rich enterprise automation technology toolset. Therefore, the solution architects can pick the most appropriate tool for a given project in terms of functionality, time to value, and cost. They may even find out that, for a particularly complex project, a combination of platforms (for example, iPaaS, API management, and RPA) is what’s really needed. Siloed CoEs could hardly design, implement, manage, and maintain such a multi-platform solution.
- Cost: A single CoE offers numerous opportunities for cost optimization. For example, they can minimize the number and nature of technology platforms they use without sacrificing functionality, thus avoiding technology duplications as much as possible (although, some redundancies are probably inevitable).
To some extent, skills can also be optimized. For example, the CoE will have to include developers and technology experts for the platforms in use, but at least some of them could be trained to use more than one platform. This allows you to have fewer integration developers and, possibly, fewer solution architects, thus saving headcount.
In general, a single CoE also gives you a more holistic view on what your enterprise automation costs are, which is a good starting point for any cost-optimization initiative. Having such a perspective when you have multiple siloed CoEs is a lot harder, and as a result, cost-optimization initiatives are a lot more difficult to execute.
It would be naive for me to say that an enterprise automation CoE is the panacea. For example, it takes time to set up as the learning curve is steep. Moreover, by having such a rich portfolio of technology at their disposal, solution architects may be tempted to choose the most “elegant” rather than the most “effective” solution. Finally, a single CoE requires experienced—and therefore, elusive and expensive— solution architects and project leaders.
To help you compare and contrast the two approaches, the following table summarizes the main pros and cons of having multiple siloed CoEs vs. a single enterprise automation CoE.
A four-step approach to implementing your enterprise automation CoE
Assuming you decide that, all considered, the single enterprise automation CoE is the right approach for you, you have to keep in mind that establishing yours can be a journey. In my experience, it requires taking a number of steps:
1. Assess how many CoEs are already in place, their technology portfolios, capabilities, skill levels, and maturity.
2. Look for low-hanging fruits in terms of consolidation. Here are a few examples:
a. A small, low maturity data integration CoE in a peripheral unit may be merged into a larger one.
b. It may make sense to combine an application integration and an API CoE when they use the same technology platform.
3. Select the candidate for your enterprise automation CoE. This often means identifying the CoE that has the best level of maturity, experience, and skills. In particular, scrutinize the extent that its solution architects have an open, architectural (as opposed to product-specific) perspective. Another aspect to consider, if you have multiple potential candidates, is whether they have the change mindset needed to get out of their comfort zone and address new challenges (e.g. supporting a democratized enterprise automation delivery model). If you want to lessen your risk, you can even pick two candidates, track their progress, and choose the “winner” after some time (for example, six months to a year)
4. Consolidate incrementally instead of using a big bang approach. A scenario where all the CoEs are put under a single responsibility overnight is likely to create friction, resistance, and rebuttal, which is not a desirable outcome. Instead, the candidate should consolidate the CoEs one by one so that they can progressively learn, build consensus, and establish and adjust best practices and governance policies. For example, I’ve seen a global CPG company initially implement an application and data integration CoE focused on ERP integration. After a while, the CIO assigned them the additional responsibility of supporting cloud and API integration while moving toward the democratized model. Eventually, they were also given responsibility for B2B integration.
I fully recognize that, especially in large organizations, a single enterprise automation CoE can be very hard to implement for a number of good (and, frankly, also bad) reasons: budget allocation, organizational barriers, balance of powers, political struggles, and so forth. As said above, in those cases, you may need to look for more sophisticated models, such as the federated or virtual enterprise CoE model (see note 3).
But, generally speaking, adopting a single enterprise automation CoE—via the steps outlined above—can drive tremendous efficiency improvements, greater effectiveness, and notable cost savings, making it well worth pursuing.
Note 1: The birth of the integration centers of excellence
For a long time, manufacturing companies, retailers, banks, and other organizations had implemented “B2B integration teams” (often called “EDI teams”) that focused on exchanging business transactions (purchase orders, invoices, payments, etc.) with trading partners in a more timely and accurate way than phone calls, faxes, or emails. For many organizations, this B2B integration team was the first manifestation of an “integration CoE”.
The wave of ERP projects that started in the second half of the 1990s also led many organizations to establish “application integration competency centers.” These concentrated on addressing the myriad of integration issues associated with implementing major ERP packages, such as SAP ERP or Oracle eBusiness Suite. For example, a global CPG company had to implement over 7,000 integration processes to connect their regional SAP ERP instances with other enterprise or regional systems.
To address this challenge, an organization would typically use an application integration platform, such as TIBCO BusinessWorks, Microsoft BizTalk Server, Software AG webMethods Integration Platform, IBM Integration Bus, or a platform provided by the ERP vendor (for example, SAP Process Orchestration or Oracle SOA Suite).
More or less at the same time, the advent of data-centric architectures, such as data warehouse and master data management, inevitably led to the establishment of data integration teams who were dedicated to developing “interfaces” (as they used to be called at the time) that extracted data from a variety of sources and pushed them into large data stores. Technologies such as ETL tools, change data capture, and database replication were providing these data integration teams the technology platforms they needed. This was, for example, how a company like Informatica was able to establish a strong and durable presence in the market.
Note 2: How organizations end up with duplicate integration and automation platforms
- Different API CoEs may choose API management platforms from different providers.
- As they move to cloud-centric use cases, the application integration and the data integration CoEs may end up selecting two different iPaaS offerings, each super-fit with their own respective needs; whereas if they had coordinated, they could have selected a single platform that was “good enough” for both CoEs.
- Different CoEs wish to pursue a democratization strategy to enable LoBs, or even business users, to perform some integration and automation work by themselves, but the CoEs end up selecting different “citizen integrator-oriented” platforms. The net result is that LoBs and business users have to deal with maybe three or four tools, which they would have to “digest” in order to use them productively. Mission very close to impossible.
Note 3: Federated and virtual enterprise automation CoE
- Federated enterprise automation CoE: According to this model, an organization has multiple “local” enterprise automation CoEs, possibly at different stages of maturity, each supporting a specific LoB, subsidiary, or brand. These CoEs work semi-autonomously, maybe using different technology platforms, but under the (lightweight or heavyweight, depending on a number of factors) supervision, governance, and architectural principles and guidelines defined and enforced by a “central” enterprise automation CoE. In turn, each of the local CoEs may enforce a centralized or democratized delivery model.
- Virtual enterprise automation CoE: If implementing a single or federated “physical” enterprise automation CoE proves too hard, you should at least try to implement a “virtual” one. The idea is to proactively work to open the silos and make the individual specialized CoEs work together in a more cohesive way by sharing architectural principles and models, solution patterns, best practices, and skills. Typically, such an approach can be pursued in organizations with a strong enterprise architecture strategy and can be the first step toward a “physical” enterprise automation CoE.
