The process automation Center of Excellence playbook

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.

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 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.

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.

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.

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.

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.

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." 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.

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. The CoE can take over the part of being both the Platform and Enabling team for process orchestration.

One CIO we spoke with summarized this concisely: "We centralize infrastructure and governance but federate delivery."

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.
• Potential bottleneck.
• 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).

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.
• 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."
• 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.

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!

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.

Disadvantages:

• The CoE quickly becomes a bottleneck.
• 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. That said, there are exceptions when a CoE should actually do the development themselves: Early maturity stages (the first 1-5 projects), Strategic key projects, Lighthouse projects when a new domain begins using process orchestration, and Regular re-assessment of practices to avoid living in the ivory tower.

Real-life examples

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

• NatWest: A major retail and commercial bank in the United Kingdom, has built a CoE that successfully scaled across the enterprise with more than 4000 Camunda users as of today.
• National Bank of Canada: The sixth-largest bank in Canada, with approximately 25,000 employees. With a CoE of only two people, they have built and shared process automation expertise, set up a community of automation experts, and created standardization around the adoption of Camunda.
• Provinzial: Successfully adopted Camunda for end-to-end process orchestration across all domains, with over 220 processes and 270 decision tables in production. With their CoE, they are now advancing towards hyperautomation with AI integration.
• Desjardins: A Canadian financial service cooperative, set up a Center of Excellence to provide Governance, Enablement, and Accelerators to use Camunda in their hyperautomation toolkit.
• Goldman Sachs: The multinational investment bank and financial services company, built an enterprise process automation platform on top of Camunda to enable automation at scale.
• Landeshauptstadt München (City of Munich): Enables citizen development empowered by a Camunda-based workflow platform and a Center of Excellence in the IT department in order to boost the digital transformation of the administration in a scalable way.
• Norddeutsche Landesbank (NORD/LB): One of the largest commercial banks in Germany, set up a CoE to drive the adoption of process orchestration at the enterprise level.

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?
• 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 tracking: 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?
• 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?
• 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?

Based on these dimensions, you can make key decisions to start building your CoE: Vision and mission statement, Roadmap, Staffing (how many people are in your CoE, and what are their roles and responsibilities?), Operating model (central, federated, or hybrid?), and Naming.

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 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.
• 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.
• 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.

The start: Pre-CoE

Oftentimes, organizations have different teams using Camunda already, but they operate in fragmented silos without central ownership. In such a situation, two activities can work: Defining a central Camunda owner or champion, and Building a Community of Practice.

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.

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. Deepak Tiwari (Managing Director at EY) has summarized on how to get management buy-in: Think big (show the big picture of the strategic benefits). Start small (ask for small funding in the beginning; a 90-day go-live plan is a good idea). Finish strong (maintain executive sponsorship and commitment throughout by focusing on benefits realization).

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.
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.

In the forming stage, the CoE consists of two to four persons (depending on funding). Typical roles: CoE Lead, Developer, Architect, BPMN & DMN Expert (note that one person can encompass multiple roles).

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.

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, 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.

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.

Level 1: You don't need a CoE yet, as you only have a single project; the expertise should sit in that project team.

Level 2: Organizations at this level of maturity have experienced some level of success with process orchestration. This is a good time to think about what your CoE should look like. There might not yet be a formal CoE, but individuals in the organization understand the strategic relevance of process orchestration. This typically kicks off planning around forming a CoE.

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. 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.

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). A typical ivory tower example.

To avoid this situation: CoEs need to establish a continuous feedback loop with all delivery initiatives to continuously evolve the CoE's offering and align it with project needs. The CoE model needs to evolve according to the needs of the organization.

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 CoE should incrementally deliver value right away and adjust the plan to any learnings along the way.

Doing too much too early is also dangerous. The CoE should harvest real learnings, distill best practices, and derive feature requests with their priorities for possible own software artifacts. 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. 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.

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 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.

Best Practices: Successful CoEs document their best practices at least minimalistically. 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.

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.

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.

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. Typically, the CoE also has knowledge on how to combine those different tools.

Accelerators: If the tool stack is standardized, the CoE can provide resources to make delivery teams more productive. Good examples are: Project templates, Frameworks that help harmonization or standardization, Installation scripts, Camunda Connectors including company-specific connectors for common systems, Security configuration, Plugins, and BPMN Patterns for typical problems.

Solution lifecycle: Many CoEs define what a solution lifecycle should look like. This typically aligns process development with the general software development lifecycle (SDLC). The CoE recommends how to version control sources, what stages deployments should go through, how to deploy process models to production, and what the CI/CD pipeline should look like.

KPI tracking: The CoE can support projects to look into typical key performance indicators (KPI). Many projects fall short of knowing which KPI they should track and how to connect those to business goals. 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.

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.

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. Also, hackathons are a great way to spread the word in a very fun and engaging way.

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.

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. 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.

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.

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.

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.

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.

Skills and requirements:

• Software engineering background
• Understands how Camunda fits into the organization's IT architecture
• Embrace visual methods like BPMN

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.

Skills:

• BPMN
• Low code platform

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.

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
• 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.