What is a Center of Excellence (CoE) for process orchestration?

A Center of Excellence for process orchestration is a dedicated team of experts that drives a strategic, scaled adoption of process orchestration across their enterprise. This definition is deliberately open because the exact setup of a CoE wildly varies depending on the goals, enterprise architecture, and culture of the respective organizations. Generally, we can say that the goal is to make the adoption of process orchestration as frictionless as possible by providing the necessary tools, building the corresponding automation skills, delivering value through automation initiatives, and creating awareness for the topic.

The CoE does not have to be named “Center of Excellence”; we have seen many different names for it: “competence center,” “capability center,” “digital enablers,” “process automation guild,” etc., but essentially they all share the goal to accelerate the successful use of process orchestration across the organization.

The CoE achieves that through activities within the following categories:

• Enablement
• Communication
• Providing Tools
• Solution Delivery

We will dive into the details behind those activities throughout this article, but first, we want to look at the business case of a CoE and sketch a framework that will help you scope your own CoE.

The case for the CoE

In our experience, the higher up a CoE reports in an organization, the more effective it can be. In that sense, it’s mandatory to get management buy-in and sufficient funding for your CoE initiative. That’s why articulating the associated business impact is crucial. The value builds upon two dimensions:

1. Why process automation and process orchestration?
2. Why a Center of Excellence?

In other words, you have to make a case for what you want to do (process orchestration) first and then argue why the CoE will make you more successful in adopting it. For customers that already have adopted process automation technology, the first step can sometimes be skipped.

The business case for process orchestration

So, as a first step, you need to really understand how process automation and process orchestration help your business, which basically means understanding how it’s improving the main strategic drivers: customer experience, operational excellence, or risk and compliance.

The challenge is that the very clear technical advantages of process orchestration (reducing time to value, saving time and effort, unlocking continuous improvement, improving resilience, scalability, and performance) are not easy to translate into those strategic drivers. In general, this is a two-step exercise:

• First, an automation solution unlocks strategic advantages, for example, because automation speeds up cycle times making customers happy, meaning the customer experience is improved, leading to less customer churn, leading to more revenue directly affecting the bottom line.
• Second, because you use process orchestration technology, you can build that automation solution quicker, align with the real business requirements better, operate it more reliably, and be able to continuously improve the underlying business process. This makes the lever for the improvements of the automation solution bigger.

The following picture shows examples of how to map technical advantages to strategic drivers using concrete business case examples.

You might also want to look into the article series around unlocking the business value of process orchestration.

The business case for the CoE

Now, the CoE will help you harvest the value proposition of process orchestration at scale in your organization. This is true not only for WHAT you achieve through successful orchestration initiatives (for example, the improved process cycle time from above) but also regarding HOW those initiatives are being delivered. A CoE will help teams to become more efficient and agile, while also improving the (internal) customer experience for your developer community (e.g., by helping them reduce their mental load through technical advantages provided by the CoE).

The strategic impact on the business is, unfortunately, often tough to quantify, as there are a lot of factors building into it. On the other hand, simple metrics around the number of people enabled around process orchestration, or the level of adoption within the organization, hint at the value a CoE is delivering but are not directly connected to business impact. This tradeoff is illustrated by the CoE value pyramid:

In general, successful CoEs are better at communicating their value on higher levels of the pyramid.

Now let’s dive into the concrete advantages that CoEs provide:

Increased developer productivity: Having a CoE that takes care of best practices, project templates, getting started guides, governance, and other material will drastically improve the productivity of delivery teams. Just think of the time and effort required to start an automation initiative from scratch: evaluate a tool, decide on an architecture and approach, burn your fingers with the first mistakes you make, etc. In our experience, this can take teams 2-6 months to go through, which you can significantly accelerate. As Deepak Tiwari, Managing Director at EY, has put in one of our blog posts: “CoEs usually have visibility across other projects across the organization. They may have seen pitfalls the project team may not have been exposed to (better to learn from others’ mistakes than your own).” Beyond knowledge sharing, CoEs might also provide technical accelerators such as connectors or an internally managed platform to reduce the cognitive load for delivery teams. We will discuss this later on in more detail.

Efficiency and cost savings: Of course, increased efficiency of your development teams will save effort and thus make projects cheaper. While this will typically not lead to a reduced headcount (after all, we’re still facing a talent shortage), you will enable more things to be automated at the same time instead. But a CoE can, for example, also make sure that licenses for tools are efficiently used and centrally negotiated, helping you in the process of vendor rationalization.

Improved quality and reduced complexity: Making sure there is knowledge exchange between teams and best practices being documented will result in teams consistently producing higher quality (for example, more maintainable) solutions and delivering results on budget and on time. A CoE will also help provide the right technology, thereby allowing a best-of-breed approach and reducing complexity for agile delivery teams. Just looking at the sheer size of the CNCF Cloud Native Landscape illustrates the challenges that delivery teams face here—how are they supposed to keep track of all the different tools? Hence, a CoE helps to improve time to value significantly since the evaluation time is shaved off for the respective teams. Additionally, the CoE can help avoid obscure technology choices made by inexperienced teams or playful individuals that will cause maintenance efforts later on (as also discussed in boring technology).

Process mindset and stakeholder enablement: Typically, the adoption of process orchestration at scale corresponds with a wider transformation of how an organization thinks about processes and how business and IT collaborate. As a survey by McKinsey pointed out in 2022, the more parts of the organization are involved, the more automation initiatives are likely to succeed. CoEs can help build this process mindset by providing the right tools and frameworks to enable every stakeholder, including citizen developers, to take part in process orchestration—from modeling to development, operation, analysis, and continuous improvement. It can also create stakeholder buy-in and provide strategic alignment across domains and hierarchies by building a mutual vision of what to achieve through process orchestration.

In summary, we can paraphrase an IT executive of a customer: Process orchestration allows us to create solutions more quickly, making the resulting systems more reliable, and the CoE ensures the organization is leveraging all of that in the best way possible.”

Aren’t CoEs too centralized for state-of-the-art software delivery?

Let us tackle the elephant in the room: There has been a lot of hype around decentralization in software engineering, most prominently driven by Microservices, Domain Driven Design, and related methods. So often, when we propose a CoE, the objection is: “But we’ve just untangled our monolith and went for independent microservices and value streams so that we can speed up development by having fewer dependencies between teams. And now you tell us to centralize things again? We don’t want to do this, we don’t want to have this bottleneck!”

To be honest, it’s more than fair to think that because of how CoEs might have been set up in the past. But done right, a CoE blends in seamlessly into state of the art software delivery paradigms, becoming an accelerator instead of a bottleneck. Let’s dive into this in more detail through the lens of overall market trends.

Looking at autonomous microservice teams (or whatever the architectural style is in your organization), the core problem without a CoE is that they must figure out many things themselves. The more freedom they have, the more of a burden it can become. Teams have to evaluate their own tool stack, define their own solution architecture and approach, and, in essence, do a lot of technical work that does not yet implement any business logic. So the value proposition of the CoE  is actually pretty logical: If solution teams get an architecture blueprint on how to design their solution, they simply don’t have to think about those fundamentals and can dive into delivering business value right away (of course, the blueprint needs to provide value for the teams. We’ll talk about this later).

Just look at Spotify and their blog post “How We Use Golden Paths to Solve Fragmentation in Our Software Ecosystem,” in which they describe why “rumor-driven development simply wasn’t scalable.” Spotify gives quite some more good insights on their Backstage open-source project. In essence, too much decentralization started to slow things down because of the resulting complexity. By centralizing services again, they reduce complexity and provide standardization, allowing delivery teams to dive into delivering business logic much faster—without sacrificing their autonomy (see image below). A similar approach is being taken at Twilio: “At Twilio, we do it by offering what we call the paved path. These are mature services that you can just pull off the shelf, adopt, and get up and running super quickly.”

Spotify gives a great summary of why some standardization is necessary to scale

This trend is excellently summarized in the book Team Topologies. A key learning of that book is that productive “stream aligned teams” (= autonomous delivery teams maintaining their value streams) require “enabling teams” as well as “platform teams” to make their lives easier. This happens through reducing the cognitive load (e.g., setting up infrastructure, building up knowledge on a specific system, etc.), allowing “stream-aligned teams” to deliver business value much quicker.

The CoE can take over the part of being both the Platform and Enabling team for process orchestration

What you can draw from this is: Yes, you should have autonomous delivery teams, and they should work on business logic, which we can also call domain logic. You should try to find boundaries between those domains that make sense. But you should still define golden paths (architecture blueprints), central enabling teams, and platforms; otherwise, those teams will drown in technology evaluations and infrastructure tasks. CoEs are crucial to achieving that balance.

One CIO we spoke with summarized this concisely: “We centralize infrastructure and governance but federate delivery.” Well said.

How to operate a CoE in your organization

Having said this, let’s dive into this model of a central CoE that enables federated solution delivery first. We see this setup as our greenfield choice, which means that if there are no good reasons against it, we would try to set it up this way. It is a model that typically balances the advantages of centralization with the advantages of federation well. But of course, reality is complex, so there might be very good reasons that you set it up differently in your organization. So we will also look at more centralized and more federated options afterwards.

CoE as an accelerator for federated solution delivery

Let’s briefly dive a bit into this model, which is the sweet spot from our perspective: Having a CoE that does not implement solutions themselves but enables the teams within different business units or domains.

Advantages:

• Building and sharing experience and know-how across the whole enterprise.
• Efficiency, as the CoE is building more expertise based on successful projects, helping others avoid pitfalls.
• Economy of scale through reusability, as assets and knowledge built by the CoE can be leveraged across the different initiatives of the organization, allowing for exponential growth (CoE doesn’t become a bottleneck for solution delivery).
• Governance: As one central team can influence many projects, you can avoid a wild-west setting where every project reinvents the wheel around process orchestration differently. Instead, the best approaches can be reused, thereby reducing cognitive load again.

Disadvantages:

• Centralized authorities might have a bad reputation in your organization, so you might need to overcome that historical impediment (as discussed above).
• Potential bottleneck.
• Differences between business units are not adequately respected (but given that process orchestration technology is horizontal technology, there are typically no big differences in process orchestration in the different organizational units anyway).
• Business domains typically need to have IT expertise in-house (or need to rely on external partners, which might generate problems with knowledge flowing out of the domain again once the partner leaves).
• Sometimes, it is challenging to “make” the domains collaborate with the CoE.
• CoE must be obsessed with delivering value to the domains (pull principle). This is obviously not a disadvantage but of course, a challenge.

Fully decentralized delivery

Let’s quickly contrast this with a completely decentralized delivery approach without any CoE element. Worst case, you have silos where domains don’t share knowledge with each other. Best case, this boils down to a Community of Practice (CoP), which is typically a bottom-up approach where people from different business units regularly meet to exchange experiences.

Advantages:

• No central team is required, and no separate costs are involved.
• Very flexible.

Disadvantages:

• Low or no governance, as business units often end up with different approaches, which leads to a lot of challenges during the lifetime of solutions. This can become a severe obstacle to increasing automation in highly regulated environments such as banking and insurance.
• There is no ownership of the process automation topic, which means there is no single responsible person for questions, managing vendor relationships, or taking part in industry circles.
• It is very dependent on the individuals and their desire to exchange ideas. Often, it boils down to motivated individuals who drive the community in their “free time,” which can potentially conflict with their daily responsibilities. You can address this by sponsoring a specific amount of time to dedicate to the community. In this model, individuals are not eager to take responsibility, as the risk of losing something outweighs their personal benefits.
• This might lead to a lack of focus and commitment around the topic since this is pretty much a bottom-up affair.
• It is hard to establish reuse, as nobody is responsible for providing reusable artifacts or investing the effort to make the project work reusable, independent of whether it is code or knowledge.

In essence, such a completely decentralized approach typically does not scale well. Still, it can be a good starting point to get a conversation about a CoE going.

However, it is important to note that a Center of Excellence and a Community of Practice are not mutually exclusive. Best-of-breed organizations have both! See, for instance, the National Bank of Canada, where the CoE has built an internal community to share knowledge (see video here):

Early days of National Bank of Canada’s CoE (from this video)

Fully centralized delivery (and operations)

Let’s also look at the other side of the spectrum, where you can find more centralization if the Center of Excellence also implements and operates solutions themselves. This means the business unit is “only” required to capture the requirements, but the CoE organizes everything else. It is almost like an internal solution integrator.

Advantages:

• The Center of Excellence is deep enough in the weeds to fully understand solution delivery and thus can give better recommendations.
• The CoE can not only control governance, but also the quality of the solutions.
• The CoE can make sure solutions are built in a way they can be easily operated.

Con:

• The CoE quickly becomes a bottleneck. 
• The need for automation solutions in most organizations is so big that the CoE would need to grow into kind of its own software engineering unit, probably losing its focus.
• CoE lacks business domain expertise.
• The approach doesn’t comply with state-of-the-art software development paradigms.

In general, we advise against CoE doing implementation work on a broad base, as this simply conflicts too much with a software engineering function you might already have. We prefer to keep a sharp focus in the CoE on enablement, letting business units do the implementation themselves or connect them to partners (internally or externally) that can do it for them.

That said, there are exceptions when a CoE should actually do the development themselves:

1. Early maturity stages: When you start your process orchestration endeavors (you want to get to level 1 of the process orchestration maturity model), you simply don’t have the know-how yet to enable anybody. Also, you will not yet have staffed a CoE anyway. So, in the first 1-5 projects, it makes sense to have one team of people looking for the whole implementation, including go-live (relating to maturity level 2). This team of people might then also become your CoE when you move on to maturity levels 3 or 4. This is a pattern we have seen very successfully in the past.
2. Strategic key projects: Your organization might want to implement important core processes with high complexity and significant top-management attention. It may be strategically wise to be part of the implementation project yourself as a CoE to ensure things don’t go south, which could damage the whole reputation of process orchestration and thus put your CoE in trouble.
3. Lighthouse projects: If a new domain begins to use process orchestration, it might make sense that the CoE is more closely involved in the first processes. That way, they can make sure the initiative is delivered on time and on budget, as well as showcasing the potential value, which is very important for stakeholder acceptance. That way, the CoE can facilitate a knowledge transfer and gradually shift responsibility towards the domain.
4. Regular (re-)assessment of practices: A CoE always bears the risk of living too much in the ivory tower. Therefore it is vital to keep grounded in real-life implementation projects. While you can do this in a consulting role, it really helps to go into the trenches yourself, at least occasionally.

Real-life examples

The following table lists some publicly disclosed examples of CoEs advising on Camunda.

The CoE framework

Working with customers on their CoEs and based on the introductory thoughts above, we defined the Camunda CoE framework, which can be used to guide you through various

decisions about the scope and layout of your own CoE.

CoE tasks and roles

Let’s start with a recap of the typical tasks that a CoE is responsible for, as well as the corresponding roles that cover them.

The size, setup, and structure of your CoE will vary based on to what extent you want to execute those tasks. This is what the CoE framework will help you define.

Dimensions of the CoE framework

CoEs can differ in many ways. They can be sizable teams with more than ten people, but we also see CoEs with only two people being successful. It all boils down to your strategy and what will help your enterprise architecture. From there on, you can determine the CoE’s size, staffing, and activities.

The important dimensions to consider are:

• • Scope: Is your CoE looking for one tool only (e.g., Camunda), for a specific category (e.g., process orchestration), or some broader category (like digital transformation in general)?
  • Solution Delivery: To which degree is the CoE enabling other teams to build solutions, versus building those solutions itself?
  • Infrastructure: Does the CoE provide infrastructure instead of simply recommending a tool? For example, add-ons or Camunda Connectors? Does it operate software and offer it in an internal SaaS model? Maybe it even provides the infrastructure to build, deploy, and run complete solutions.
  • Governance: Is the CoE seen as an enabler that helps projects or as a police force that mostly enforces guardrails? Are stacks standardized and obligatory, or documented as best practices you can or cannot follow?
  • Process overview and value tacking: Will your CoE be the go-to place in the organization to gather an overview of business processes, probably providing some kind of process architecture or process landscape? Will it manage the automation backlog and proactively measure the value of automated processes within the business domains? Or is it better to keep having this responsibility in the business domains or another centralized unit?

• Supported use case complexity: Does the CoE focus on your core business processes that typically have a high complexity criticality and deliver high value? Does it focus on the long tail of simpler processes that can potentially be done by citizen developers? Or does it cover the whole diverse set of processes to be able to also oversee the sweet spots of the different tools being used?

• Depth of enablement: How far does your CoE offer best practices, workshops, and training? Do you offer a specific learning and upskilling path for your organization?
• Communication: How much does your CoE invest in communication to create awareness for process orchestration? For example, building an internal community, doing internal case studies, and presentations, or even creating sophisticated marketing materials?

The following illustration gives an overview of these dimensions (you can access this graphic as Google Slide to visualize your own CoE design easily):

Based on these dimensions, you can make key decisions to start building your CoE:

• Vision and mission statement: Paint a target picture of your CoE to get internal buy-in.
• Roadmap: Build an action plan to bring the vision to life.
• Staffing: How many people are in your CoE, and what are their roles and responsibilities? (The more centralized activities you have, the more personnel you need in your CoE).
• Operating model: Is the CoE run central for the whole organization, federated within business units or domains, or some hybrid in between?
• Naming: A lot of centers of excellence are not named CoE but “digital enablers,” “capability center,” “competence center,” or whatever works well in your environment.

Independent of where on those dimensions your CoE will end up, one pattern emerged clearly across all customers that got the biggest value out of process orchestration in their organization: They do have a CoE. In the State of Process Automation 2020, 90% of participants indicated that they already had a CoE, were actively working on implementing one or had it on their roadmap. The number of active CoEs has likely grown even higher today, given that in our State of Process Orchestration 2023 report, 96% of respondents stated they believe that process automation is critical to achieving their digital transformation goals.

So, let’s first understand what a mature CoE will look like before diving into the journey to build it. The setup that our customers with the highest process orchestration maturity deploy looks like this:

• A centralized team with a size of 2-8 people that helps teams with all things process orchestration.
• The CoE sees themselves as enablers, leveraging the pull principle to provide value to the organization (people love to use their help because it makes their lives easier and projects more successful).
• They provide a basic set of artifacts (best practices, reusable components, and some templates), a Camunda 8 infrastructure (either self-managed Camunda, provided via self-service to the organization, or simply relaying the Camunda 8 SaaS offering) and collaborate with Camunda to build the automation skills in their organization.

This is visualized in the following diagram:

The best CoEs we have seen have a product mindset. They view themselves as building an internal product, like a framework, tooling, or platform. They see developers, operation teams, SecOps, and other stakeholders as customers. So just like product design software vendors do, they always source and validate their decisions with those customers. They make it easy for the customers of the CoE to provide feedback or request functionality and know they will be listened to. Remember: You’re building it FOR those folks and not because you know better. A good reference is the article What I Talk About When I Talk About Platforms on Martin Fowler’s blog.

We see this setup pictured above as our greenfield choice (remember: if there are no good reasons against it, we would try to set it up this way). But of course, reality is complex, so there might be very good reasons that you set it up differently in your organization. For example, some company cultures are built upon strong rules and enforcement, so it would alienate employees if the CoE expects a pull principle for their help. Still, it will be helpful to understand our greenfield recommendation and make deliberate choices where to deviate from it.

This greenfield CoE can be sketched within the CoE dimensions:

Looking a bit deeper in the individual dimensions, the CoE:

• Provides a wide array of process automation tools including Camunda, testing tools, RPA and more.
• Proactively guides delivery teams along their adoption of process orchestration (depending on the needs and skills of the delivery teams).
• Hosts a centralized Camunda platform as an internal SaaS offering, which is augmented by accelerators (e.g. integrations into the data warehouse, user task management, SSO, etc.).
• Provides sensible governance through a helpful reference architecture which matches the requirements of the internal teams.
• Encourages process remodeling and value tracking to improve and measure the achieved value.
• Enables low-code developers to implement the long tail of use cases with low or medium complexity.
• Provides a training curriculum that is tailored to the organization’s needs, thereby leveraging internal and external resources.
• Has built a strong internal Community from which it learns and evolves while also continuously showcasing successes to the wider organization (business and management stakeholders).

It has 2 to 8 people filling the following roles:

• CoE Lead
• Software Developer
• IT/Solution Architects
• DevOps Engineers
• Business Analysts (BPMN & DMN experts)

Your CoE should at least own the process orchestration topics with all its related facets, for example also advising on how integration is typically done, how humans are pulled into processes, and how executable processes can be automatically tested. For instance, see how the CoE at Provinzial, Germany’s second-biggest public insurance company, defined the typical specifications of a process model (e.g., service task, user task, and data warehouse integrations as well as DMN, modeling conventions) in the slide below.

How to design an executable process at Provinzial – as defined by their CoE (taken from this talk)

Ideally, your CoE will look after all process automation technologies holistically, so in addition to process orchestration it will also look after Robotic Process Automation (RPA), Business Process Management Suites or low-code tools. So, for example, we saw one “Process Automation CoE” at a bigger customer looking after Camunda, Pega, UIPath, and Mendix. The big benefit of this layout is that you have one place in your organization that will also understand the differences between those tools, as well as their respective sweet spots, and can recommend the best-of-breed tool for the specific use cases. The CoE will be able to consult projects on which technology to choose, which is much more beneficial than having two different competence centers being at war with each other. This way, the CoE can also effectively drive vendor rationalization efforts. However, we have also seen customers benefit from having different CoEs for different tools, typically because it drove innovation due to a healthy friction between the approaches.

Watch out not to widen the scope too much beyond process automation, as, for example, a “Digital transformation CoE” can very much end up with too many topics and tools to look after to work effectively.

The journey to build your CoE

Having discussed the goal, it is important to keep in mind this is still a goal and needs to get there step by step, keeping an eye on incrementally delivering value, ideally from day one.

The typical blueprint for this journey has four phases:

• Pre-CoE: Organizations want to start adopting process orchestration or have one or more different teams using Camunda, but they operate in fragmented silos without central ownership. In the best case, a Community of Practice can be established to facilitate knowledge sharing and start a journey towards a CoE; in the worst case, those projects are completely isolated silos.
• Forming: Your CoE starts to exist as a dedicated team within the organization and starts to develop guidelines and infrastructure. The CoE either focuses on enabling from the beginning or is deeply involved in the first solution delivery projects themselves.
• Scaling:  Now it’s time to scale the adoption across your enterprise and evolve your CoE accordingly.  Experience from more and more projects improves the maturity and credibility of the CoE. The CoE needs to improve in capturing metrics and communicate the business value of process automation and the CoE itself to secure funding. Typically, we will see a stronger centralization of governance, enablement, and infrastructure and an increasingly federated delivery in the business domains.
• Maturing: The CoE is established and helps the organization to strategically apply process automation and orchestration across the organization. The CoE is continuously improving its offering across the board.

Let’s go over these phases one by one.

The start: Pre-CoE

Oftentimes, organizations have different teams using Camunda already, but they operate in fragmented silos without central ownership (we described the specific challenges of this situation when we talked about the community of practice). In such a situation, two activities can work:

• Defining a central Camunda owner or champion, which is normally one person who has been involved in prior Camunda projects and is widely regarded as an expert and informally consulted with technical questions. Often, this person doesn’t have a formal mandate yet and is driven by personal motivation, so the champion is actually not formally designated but informally grows into that role. This is not a CoE yet but can be a great incubator.
• Building a Community of Practice, which can be driven by the Camunda champion or from other motivated people within the community.

Building a Community of Practice will help you bring together the users in the organization so they can learn from each other’s projects. It will also help generate visibility within the organization to showcase successes and generate a snowball effect where success generates success. That way, you can start to have a first impact on the enterprise level of your organization without having a formal mandate or budget for a CoE.

We often see the Community of Practice as an interim solution for organizations where a CoE does not have funding yet but motivated individuals who want to push process orchestration forward, probably working towards making the case for a CoE.

However, to formally set up a CoE and increase the impact on your organization, you will need management buy-in and sufficient funding. This either happens through enough bottom-up pressure (i.e., more and more teams articulating the desire to use Camunda) or through a strategic top-down initiative to drive process orchestration at scale.

In one of our blog posts, Deepak Tiwari (Managing Director at EY) has excellently summarized on how to get management buy-in for funding a CoE:

1. Think big (and make the stakeholders think big). Show the big picture of the strategic benefits, visualize your target operating model, and paint a clear picture of the future state and an implementation roadmap to get there.
2. Start small. Ask for small funding in the beginning. A 90-day go-live plan is a good idea. Pick a high-value but low-effort use case for a pilot lighthouse project. Get a meaningful win that will help consolidate business sponsorship and build momentum.
3. Finish strong. Maintain executive sponsorship and commitment throughout the duration of the program by focusing on benefits realization.

After those phases, Deepak also suggests building, scaling, and continuously improving your CoE. So let’s take a look at how this could look in the next phase: forming.

Going step by step: Forming

We see two typical patterns within our customer base:

1. The organization has existing bottom-up initiatives that leverage process automation technology and start to see the need for knowledge exchange and harmonization, bringing a CoE into the discussion. The CoE will start by distilling best practices from those projects and building governance guidelines and infrastructure. It will not be part of the solution delivery.
2. The vision of a process automation CoE is shaped out of strategic thoughts and developed purposefully with the first project(s). The CoE will be closely involved in delivering the initial solutions to build up the experience for the later CoE.

So, depending on the motivation and setup, the forming phase will look different. Let’s explore both variants.

1. A) Strategic introduction of your CoE

In this scenario, a CoE is starting with a lighthouse project they’re delivering (or supporting) to quickly deliver initial value and build up learnings. See, for instance, the case of Axa Germany, which started with two processes (travel health insurance and supplement proposals) before scaling further.

Slide from this this talk, where Axa explains how they started their process orchestration journey with two processes before scaling out

Accordingly, in the forming stage, such a CoE:

• Focuses on the solution delivery to showcase initial value.
• Builds up learnings on how to implement Camunda.
• Leverages those learnings for the “scaling phase” to build a governance, architecture and which Infrastructure components are helpful to accelerate time to value.

Plotted in our CoE dimensions, the formation stage looks like this:

The CoE consists of two to four persons (depending on funding) and is augmented by additional resources (partners or business domain). Typical roles (note that one person can encompass multiple roles):

• CoE Lead
• Developer
• Architect
• BPMN & DMN Expert

After delivering your first success, it’s crucial to celebrate this success widely in the organization, e.g., through an internal event, showcase it in your community and create a dedicated blog post. Success will generate visibility in your organization and will attract more initiatives and funding.

1. B) Harmonizing bottom-up initiatives

The alternative forming scenario is an organization that already has a couple of isolated projects in production but now wants to harmonize their usage of process orchestration or to harvest experiences that help accelerate further projects. The advantages of process orchestration are typically proven with those first projects, but new projects cannot benefit from earlier experiences.

In this scenario, the CoE is often formed from people who were part of the former solution delivery teams. The CoE directly concentrates on enablement and governance and will probably not be part of new solution-delivery projects. We see typical team sizes of 2 to 8 people.

Plotted in our CoE dimensions, the formation stage in this scenario looks like this:

Going broad: Scaling

Now it’s time to scale the adoption across your enterprise and evolve your CoE accordingly. Typically, we will see a stronger centralization of governance, enablement, and infrastructure and an increasingly federated delivery in the business domains.

The activities include:

• Supporting delivery teams through consulting or proactive guidance as a sparring partner (depending on the maturity of the internal customers), but doing less implementation work.
• Establishing a helpful governance and reference architecture around process automation applications that teams are happy to use.
• Defining internal workshops and training to bring new users up to speed.
• Advising teams on process refactoring and starting to track the business impact of the initiatives.
• Growing the community and leveraging it as a feedback instrument for the CoE.
• Opening the scope towards wider automation tools or joining forces with existing other CoEs to better serve the evolving needs in the organization.

The roles are similar to the mature CoE with the size ranging between 4-8 people:

• CoE Lead
• Software Developer
• IT/Solution Architects
• DevOps Engineers
• Business Analysts (BPMN & DMN experts)

Aligning your journey with the process orchestration maturity model

The journey to build your CoE is also closely aligned with the process orchestration maturity stages, as the CoE is an important strategic driver of increasing process orchestration maturity.

So you can also look at the CoE creation through the lens of the maturity phases:

Level 1: You don’t need a CoE yet, as you only have a single project; the expertise should sit in that project team. Of course, you can plan ahead to make this project team, or dedicated individuals from it, the CoE later. Or maybe you also do it the other way around: Form your CoE, but let it develop a single project from start to finish.

Level 2: Organizations at this level of maturity have experienced some level of success with process orchestration, although this success may not have been measurable or easily repeatable. They are beginning to question how to initiate broader process orchestration initiatives to bring more tangible value to the organization. This is a good time to think about what your CoE should look like, especially in the next maturity phases. So, for example, there might not yet be a formal role or CoE being created, still there are individuals in the existing projects or somewhere else in the organization (e.g., CIO, Enterprise Architect, program manager) that understand the strategic relevance of process orchestration, or simply the value of sharing experiences and artifacts.

This typically kicks off planning around forming a CoE and leads to first steps, like having a part-time CoE lead, starting a Wiki space or Slack channel around the topic, or doing first meetings to facilitate collaboration.

This prepares you for achieving the next maturity levels.

Level 3 and 4: Getting to Level 3 and beyond is not possible without any form of CoE; at least, we have not seen it in real life so far. Very often, people involved in early projects are now part of the CoE, and it has grown into its own organizational unit with its own people. The CoE becomes the go-to place for enabling the whole organization to benefit from process orchestration.

CoE anti-patterns

As we all know, failure is the best teacher, so we also want to describe typical problems we saw from customers. Unfortunately, those stories are seldom shared openly.

For instance, we saw an organization where the delivery teams tried to avoid working with the CoE. They developed autonomously and even procured their own licenses. The main reason was that the CoE significantly slowed down delivery work by adding bureaucracy and applying too restrictive guidelines (e.g., mandatory quality checks, which weren’t helpful for the teams). In this case, the CoE was detached from the real challenges of delivery teams “on the ground” and created governance guidelines that were not only unhelpful but actually an obstacle. A typical ivory tower example.

To avoid this situation:

• CoEs need to establish a continuous feedback loop with all delivery initiatives (and a potential Community of Practice) to continuously evolve the CoEs offering and align it with project needs. This is all about mindset. As mentioned, the CoE needs a product mindset and also be obsessed with providing value for the stakeholders in their organization.
• The CoE model needs to evolve according to the needs of the organization. While it might make sense to have stricter governance guidelines in the beginning, it might also make sense to provide more autonomy to enable scaling in later maturity stages (our customer Provinzial called this “managed autonomy” in their CamundaCon 2023 presentation).

Another anti-pattern we see is spending too much time on activities that don’t have an impact on the organization. This often comes up in a pair with “planning over doing” or paralysis by analysis. The effect is that CoEs jeopardize their credibility, and people will not perceive them as valuable.

Instead, the CoE should:

• Incrementally deliver value right away. Of course, with a goal in mind, but focus on going step-by-step and not getting bogged down by initiatives that only provide value after a significant amount of time has passed, with the risk of not being helpful at all in real life.
• Adjust the plan to any learnings along the way.

This plays into the next anti-pattern: Doing too much too early. This can also be dangerous. For example, we have seen customers who wanted to build their own platform, provide a lot of best practices around its usage, share reusable patterns, and so on. Sounds all good—the problem was only that they started when they did not have any experience yet. Solution delivery teams, detached from the CoE, adopted the best practices early on, which did not work very well and led to a lot of work within the CoE to fix problems or develop important features, very often in a firefighting manner, especially with the first project going live. After only a handful of projects the team was completely blocked, ending up with a half-baked, relatively unstable platform and not enough capacity to enable projects.

Instead, the CoE should

• Harvest real learnings, distill best practices, and derive feature requests with their priorities for possible own software artifacts. The real-life context will help to better judge what a realistic scope for own software artifacts is.
• Develop internal platforms incrementally together with real-life projects.

Last but not least, we see CoEs struggle because of a missing mandate within the organization. This can lead to too little capacity to do impactful work and a lack of credibility within the organization.

Instead, it is crucial to have sufficient authority and funding in the organization—the higher up the CoE reports in the organization, the more impactful it can become. This is achieved by creating and sustaining stakeholder buy-in, especially with your internal sponsors. In that sense it is crucial to monitor and report the business impact to your internal sponsors, but also across the business to generate interest in new initiatives.

See below the typical CoE anti-patterns and how to address them.

Tasks and roles explained

CoE tasks

Now let’s dive a bit deeper into how a CoE provides value: What activities does a CoE normally perform? And what would be better to avoid? Let’s go over the core activities of a CoE, including typical resources a CoE provides.

We grouped tasks into four main groups:

• Enablement
• Communication
• Tools
• Solution Delivery

Let’s go over those groups one by one.

Enablement

The main goal is to enable others in the organization to successfully implement process orchestration solutions. This can happen on many levels.

Consulting: The CoE can be the go-to place to ask any question about process automation in general, methods like BPMN or DMN, but also tools like Camunda. In a minimal form, the CoE is just approachable for questions. In a more structured way, this could also include defined consulting packages, e.g., a virtual coffee for projects thinking about using process orchestration or a half-day orientation workshop, up to a 5 day POC support. Many CoEs also stay close to projects, e.g., by regular, proactive check-ins or reviews.  In mature organizations we often see a quite broad offering, which to some extent reminds us of our consulting offerings, including out-of-the-box training courses.

Instead of relying on rigid rules that people have to attend mandatory training courses, try to build a learning culture, where learning and training is not only valuable and helpful, but can also be fun.

Note, that it might also make sense to include vendor offerings, e.g., free e-learning courses from the Camunda Academy, into your own offering. In this case, the added value of the CoE is often a curation of the important content and establishing the link between the generic vendor’s world and the organization’s specifics. This also results in a much more realistic workload, as it is simply hard for a CoE to develop and maintain too much material on their own.

Best Practices: Successful CoEs document their best practices at least minimalistically. You might find some inspiration in the Camunda Best Practices, but the advantage a CoE has is that it can tailor the best practices to the organization, which might eliminate choices that can confuse projects. One good example is the solution architecture for automation projects, where it might be sufficient to define one common architecture for pro code, and one other for low code environments. This architecture then can also go into the company specifics, like which version control is used, how such a project can be hooked into CI/CD, and so on. You do not need to call this best practices, it can simply also be your process orchestration documentation.

CoEs might share those best practices in a knowledge base, capturing frequently answered questions (FAQ). This might simply happen in your company’s wiki (e.g., Confluence), but of course, you can also use an internal forum or specific tools if there is enough internal traffic.

Demand management: One big challenge in organizations is around finding the projects that benefit from process orchestration. This includes identifying those projects, describing the role process orchestration plays, budgeting those projects, including a business case presentation, and finally prioritizing and planning those projects. The CoE can play an instrumental role in the whole process to support business initiatives with the insights required. Many CoEs have a low touch entry point for projects to get in touch (one customer names it “Front Door”). Projects are then quickly assessed (for example, by a virtual coffee and templates to capture the important information), and recommendations can be given. The CoE could flag if process orchestration is not helpful in this project, but also help show the value it brings if applicable. The CoE then helps to define the required roles to develop a solution and might also help recommend development partners—internally and externally.

CoEs in more mature organizations even start one step earlier and sit down with leaders of their business domains to proactively think about the potential of process orchestration for various use cases. Done well, this can reveal big strategic opportunities to either save money, earn more money, or reduce risk by the benefits process orchestration brings to solution delivery.

Tools and infrastructure

As part of the enablement practice, or on top of it, many CoEs provide more guidance on the tool stack or additional reusable artifacts. Some even operate software. Let’s also untangle this a bit more.

Defining the hyperautomation stack: If the CoE is an automation CoE, it typically owns the full hyperautomation technology stack. This means, the CoE knows a variety of tools from different categories and can give recommendations on which tool to use for what use case. We sometimes even see very sophisticated decision trees that, for example, lead a project to either use a process orchestration platform like Camunda or an RPA tool (you could also leverage Bernd’s process automation map for this). Typically, the CoE also has knowledge on how to combine those different tools because, for example, you might want to orchestrate the overall end-to-end process with Camunda but integrate certain legacy systems via RPA within single tasks.

In the weakest form, a CoE might consult on the differences between tools. But in most organizations, CoEs actually recommend and provide specific tools to be used. Depending on your organization’s culture, this recommendation means more of a help that can be ignored, or it is set as the standard everybody has to follow.

When a CoE, for example, recommends Camunda, it can further recommend the way it shall be used in projects, for example:

• SaaS vs. self-managed
• The programming language used (e.g., Java and Spring Boot)
• How are tests supposed to be done (e.g., Unit tests with JUnit, behavior-driven testing with Cucumber, Integration testing with Selenium, etc.)
• Continuous Integration Pipeline (CI/CD, for example with Jenkins or GitHub Actions)

This can go further. For example, we see CoEs that run architecture workshops and architecture reviews and others that help projects that need high-scale to do load tests, benchmarks, or performance tunings. Especially those activities that require deep expertise around the tool but are often very unrelated to the business problem, can be best supported by a CoE.

Accelerators: If the tool stack is standardized, the CoE can provide resources to make delivery teams more productive. There are many things that are quite similar in various projects, and it is simply easier to reuse the know-how and code. Good examples are:

• Project templates (e.g., a Maven Archetype or simply a template project to be copied)
• Frameworks that help harmonization or standardization (e.g., Maven parent POMs, Maven BOMs, Build Tools, etc.)
• Installation scripts
• Camunda Connectors, including company-specific connectors for common systems (e.g., Mainframe, or some bespoke core business system). Sometimes just reusable job workers and element templates
• Security configuration (e.g., SSO or LDAP integration and configuration)
• Plugins (e.g., pushing Camunda’s audit data into the data warehouse)
• BPMN Patterns for typical problems (e.g. Maker-Checker)

One specific form around acceleration are internal marketplaces or portals, which can be used as catalogs to find and leverage reusable artifacts, as this tends to become a big problem once adoption is scaled. While many CoEs in the past organized this via Wikis, some also have their own portal software, e.g., API portals. As of 2023, Camunda also provides a marketplace component that can be leveraged for this, as well as  for sharing artifacts only internally. Such an internal Camunda marketplace would most likely be curated by the CoE and augmented by the contributions of the internal community.

Solution lifecycle: Many CoEs define what a solution lifecycle should look like. This might depend a bit on the type of solution (pro code vs. low code), but typically, this aligns process development with the general software development lifecycle (SDLC). So, for example, the CoE recommends how to version control your sources (e.g., GitHub), what stages deployments should go through (e.g., DEV, INT, PRE-PROD, and PROD), how to deploy process models to production (e.g., the BPMN being part of the deployment artifact deploying during startup), and what the CI/CD pipeline should look like (e.g. pre-defined GitHub actions).

As part of the solution lifecycle, some organizations also establish quality gates or approvals. For example, a BPMN process model requires a review by the CoE before it can go live. Or there is a definition of done (DoD) which includes specific process related checkpoints (e.g., there is a basic test coverage).

KPI tracking: The CoE can support projects to look into typical key performance indicators (KPI). Based on our experience, many projects fall short of knowing which KPI they should track and how to connect those to business goals. However, this is essential to prove the business value of process orchestration, find bottlenecks and improvement opportunities, and track continuous improvements over time. The experts within the CoE can provide KPI examples and hints to other business cases in the organization.

Solution delivery

Evaluate the automation pipeline: Organizations need to decide which projects process orchestration is beneficial for, and how to assign typically rare resources properly, leading to a prioritization of projects. The CoE can consult projects on process orchestration benefits and help with early effort estimations to calculate the business case, but often also see opportunities others have missed because they are not so deep in process orchestration. For example, the CoE knows that you can much more easily change processes running on the orchestration platform later and that this will enable experiments with new technologies like AI.

Consult and accompany delivery teams: As described within the enablement and tools section, the CoE helps the team with their initial setup. Furthermore, it is typically always there for questions and can give feedback.

Orchestrate partners: The CoE can coordinate with external partners (software integrators, consulting companies, training providers) to staff projects or to find enablement support. Many CoEs work with a curated set of people at dedicated partners, where they know that those folks know not only process orchestration and the tool, but are already introduced to all specific needs of the organization. Of course, this can also work the same way with internal people, especially in bigger organizations.

Implement automation projects: Some CoEs also do real implementation work themselves. As discussed earlier, we generally advise against CoE doing implementation work on a broad base, but there are good exceptions (early maturity stages, strategic key projects, assessment of practices).

Communication

A CoE needs to evangelize process automation. This can be done in many ways. You can do internal events like lunch and learn meetings, tech days, success story presentations, vendor pitches, or roadmap discussions, many of which Camunda could also support. Also, hackathons are a great way to spread the word in a very fun and engaging way. And don’t forget about the power of good branding that might be a bit more fun than a “Process Orchestration CoE.” At one customer, we saw “YourCompany’s Process Samurai” stickers on various laptops throughout the firm, and others had their own great T-shirts. Keep in mind it should fit your company’s culture (this is why humorous things work well at Camunda ;-)).

Additionally, you can leverage external events like industry conferences, CamundaCon, Camunda days, or regional meetups. Surprisingly enough, good external presentations often get more internal attention than internal events. We actually connect different business units of one customer that do not yet know each other through Camunda events really often.

Apart from events, you can also write. Case studies are a good way to communicate value, and many CoEs write extensive internal case studies for all projects. Emphasize the benefits and point to quick wins. You can also participate in Camunda case studies, typically revealing a bit fewer details but getting more exposure. Also, most CoEs run a regular newsletter or maintain a news section in their wiki that people can subscribe to.

The CoE should also try to foster internal communication. By doing regular coffee meetings, reviews, open spaces, or other kinds of workshops, the CoE should try to be seen as approachable and caring.

Part of this is also to make sure the right technical foundation is in place to form and manage a Community of Practice, where all professionals around process automation can easily meet and exchange ideas. Typically, companies have a forum or Slack channel, a blog or Wiki section, or regular speaking slots at company-wide meetings.

CoEs typically also hold the contact to the vendors and do respective license management. Having this in a central place not only makes collaboration with the vendor more efficient, but can also make sure the right configuration of the tool is applied and licensing is optimized for all use cases. For example, you can make sure to not overpay by having one single license agreement instead of multiple separate small contracts. Camunda also allows licenses to grow without going through a complete sales and legal cycle every time, e.g., with agreed adoption paths or frame agreements.

We want to emphasize that good vendor support is vital for organizations to succeed, so vendor management is actually a more essential activity than most anticipate. Knowing the vendor’s offering, not only by features, but also by customer success, support, and enabling services, as well as understanding the vision and roadmap, is crucial for effectively improving your process orchestration maturity.

CoE roles

Most CoEs have similar roles with the same requirements and learning paths, even if the exact names of the job profile might differ. We list the most common ones here.

Note that people working in a CoE should generally have an appetite for innovating the company. This does not necessarily mean they always want to use the latest and greatest technologies, but much more that they want the organization to embrace change towards a better future. People must be willing to take some risk, and embrace failure as an opportunity to learn and improve.

CoE leader

The CoE leader manages the CoE, typically reporting to the CIO or a senior manager within the IT department. Sometimes, the CoE leader is also reporting to a senior program manager, e.g., around digital transformation. Ideally, there is C-level attention and clear communication to foster a recognition of the process automation CoE impact on the overall goals of the organization.

A good CoE leader is enthusiastic about the opportunities of process orchestration and can help challenge the status quo in different parts of the organization by envisioning a better world with process orchestration. Therefore, this person should be pretty convincing, especially when talking to senior managers or conservative parts of the organization.

Goals:

• Enable the organization to successfully conduct all process automation initiatives
• Support the overarching digital transformation process with adequate process automation technology
• Demonstrate the success of these initiatives, mostly by looking at specific projects and their business outcomes

Skills and requirements:

• Technical background, understanding of technology and security
• Strategic thinking
• Communication and presentation skills
• Enthusiasm about process automation and the benefits it brings to the table, as this can be an uphill battle in some organizations

Software developer

Surprisingly enough, software developers develop software. They typically code to produce software according to business requirements that is well tested and maintainable. As part of this, they leverage different frameworks and libraries, like an orchestration platform. Regarding process orchestration, software developers can sit within the CoE or the solution teams.

Within the CoE, software developers typically concentrate on helping out with projects, consulting other developers, or developing reusable artifacts and documenting them. Those developers should have enthusiasm for process orchestration.

Within the solution teams, software developers make process models executable, connect them to your endpoints, and write proper tests. In order to be productive with an orchestration platform, they need to learn the basics of the process modeling language (e.g., BPMN) as well as get a solid foundation in core workflow engine concepts and APIs.

In Practical Process Automation, we differentiated rockstar and professional software developers. While rockstars can perform miracles, you typically don’t have many of them in the organization, and these people also bear the risk of overengineering or applying the latest and greatest technologies just to avoid getting bored. Rockstars can be a help in your CoE, but pay attention that they don’t push the CoE towards over-engineering. Also, rockstars are sometimes not good at dealing with “normal” developers, meaning that coaching is not their strong skill.

Skills and requirements:

• Software engineering background
• Understands how Camunda fits into the organization’s IT architecture
• Embrace visual methods like BPMN (surprisingly enough, some developers are scared of visual models for different reasons)

Low-code developer

Within the process automation space, you often hear about low-code developers. Low-code developers can be trained software engineers who prefer to work in a low-code environment to simplify integration tasks and streamline the work. Or they have a business background and slipped into development using tools like Microsoft Office, macros, or RPA.

Low-code developers often spend their time developing solutions in a dedicated low-code environment. Low-code developers need a very constrained environment and a highly customized training course in the exact environment they will be working in.

For many companies, the key to scaling their process automation efforts is enabling these developers to model executable workflows. Low-code developers are typically within the solution delivery teams and not part of the CoE itself.

Low-code developers can also be named business technologists, as this name reflects that they might work outside of IT departments.

Skills:

• BPMN
• Low code platform

Note that low code developers are not citizen developers. Citizen developers, in contrast, are not developers working on solutions all the time but typically end users with some IT affinity. They want to solve an active pain with a technology they can master. Solutions of citizen developers are often outside the scope of the process automation CoE, but of course, there is a gray area in between.

Business analyst

The analyst typically bridges the gap between non-technical stakeholders and IT people and translates the desired business logic of an application from “business” to technical language. Business analysis is important at any stage of the software systems development life cycle. Responsibilities and tasks vary widely depending on the organization.

Business analysts should be involved in any process orchestration project. As business analysts are typically not required full time on a project, they often look after multiple projects (or products) at the same time. Many CoEs also have their own business analysts on their team who then either enable other business analysts on the specifics of processes and BPMN or hop in and out of delivery projects to focus on business analysis there.

Skills:

• Being able to communicate well with a variety of people while also being able to structure and prioritize very strictly (which is a combination many people struggle with)
• Analyzing, documenting, and managing requirements
• Converting vague bits and pieces into structured information
• Ability to communicate between business and IT
• Understanding processes and being able to use the modeling standards BPMN and DMN
• Tracking value and KPIs, e.g. in Camunda Optimize

Solution or IT architect

Solution or IT architects typically design the general architecture of a solution, which also involves defining the tool stack and procedures being used (e.g. Camunda SaaS, CI/CD pipeline, issue tracking, etc.) and respective best practices. Oftentimes, solution architects are instrumental in the beginning of a project to write the first lines of code, but they get less important once the focus shifts to implementing more of the same.

The solution architect role is often played by senior developers or the solution delivery team as a whole. The more standardized your development approach is, the more solution architecture is pre-defined by the CoE. In those cases, solution architects might also sit within the CoE.

Having a good solution architect is vital for organizations to succeed, but it does not have to be a dedicated person.

Skills:

• Good overview of technological possibilities and their impact
• Good strategic overview of the lifetime for solutions
• Experience with different technical architectural styles in the past

Operations engineer

This is an individual that looks at running process solutions (or generally applications) in production environments from a technical point of view. Some operations engineers understand how to provision machines (e.g., Terraform, Kubernetes, etc.) and how to run software on them (e.g,. Docker, Kubernetes, etc.). Others focus on technical operations, meaning they can monitor applications and resolve issues when they occur. They can work in the front row of support, relying on developers whenever a problem goes deeper into process or application specifics. Very often, operations engineers work on call to provide 24/7 support for critical applications. This also gives you a good hint that those engineers look more for stability than fancy features and are often a good balance in any delivery team.

If your CoE operates software, you will need at least two or three operations engineers. Working on call and providing sufficient support coverage is not feasible with fewer people, unless you weaken the business requirements around incident resolve times.

The CoE might also have at least one operations engineer to consult delivery teams and make sure that best practices do not forget about operations.

Skills:

• Knows how to run software applications reliably
• Read and understand technical logs
• Knows BPMN and Camunda basics

Enterprise architect

Enterprise architects are not just looking at IT architectures, but they understand the company’s mission in sufficient detail to make informed purchases or architecture decisions across the enterprise. Very often, enterprise architects make high-level design choices on all things IT and propose technical standards, including coding standards, tools, or platforms.

For CoEs, it is important to keep in close touch with enterprise architects, as they typically follow similar goals and have a similarly central role.

A well-respected enterprise architect could also be a great CoE leader.