From Project to Program: Establishing a Center of Excellence

How can you move beyond your first Camunda project and automate hundreds of processes successfully using an agile step-by-step approach? For the last 10 years we’ve been helping businesses to automate workflow processes, migrating from monolithic systems into agile, scalable ways of working. And we’ve discovered that you don’t have to start with a big bang approach – in fact, starting small is the fastest and most effective route to digital transformation.

You can catch up on the previous blogs in the series, if you’d like more background before diving straight into this blog, where we’ll look at how to establish and run a Center of Excellence, manage architectural decisions and manage perceptions around your projects.

Establish a Center of Excellence

So your first Camunda project is up and running? Great! If you had one team working on the pilot, and probably also the lighthouse project, they will not only become very familiar with the technology and architecture, but will have learned a couple of valuable lessons the hard way. These are incredibly valuable experiences and you should make sure they can be leveraged in future projects.

One option is that these people will simply continue building workflow solutions in a team. This is definitely super efficient, but does not scale. You could also split up the team to send the people to different projects, which I have seen working very well, but means you need to have some flexibility in team assignments. The third possibility: transform the project team into a center of excellence (COE).

The COE can be set up as dedicated Camunda COE, but more often it is a general process automation COE. Then its job is extended to evaluate workflow technology and to help decide the right tool for the job at hand. Typically these COEs also manage technologies around robotic process automation (RPA) or skill-based routing for human tasks.

The COE creates and maintains internal best practices. You can basically lean on the Camunda Docs and Camunda Best Practices as a basis. You should further document decisions, constraints or additions that apply to your company. For example you might want projects to always use the standalone Camunda Run distro, do external tasks via REST and add forms as HTML snippets. You can describe how Camunda is easily hooked into your central Active Directory. You can further link a couple of internal projects that provide integration into RabbitMQ, SOAP Web Services and FTP.

One customer (a big bank) told me how they developed a “self-service portal” within the COE over the course of two years. This portal contains getting started guides, Maven project templates and some reusable components as maintained libraries. This setup allows most projects to get going on their own, including projects staffed by big offshore IT integrators. In the beginning they had to develop the first six workflow solutions themselves, but now have seven additional projects already completed via self-service, which proves the direction they are heading.

The COE can also foster a community, simply by being available to talk to. Additionally you can add a forum, a Slack channel or regular face-to-face or web meetings. The right tool choice depends heavily on your company’s culture.

It is also worth investing in internal marketing as it is important that other projects know about the COE. You might even want to talk publicly about your use case and serve as a reference for Camunda, as I often hear of customers googling for Camunda, only to find a use case within their own company.

Manage Architecture Decisions

I am not a fan of rigid standardization. Project teams need some freedom to choose the right tools. In many situations it is best if the team can, for example, decide if they need a workflow engine at all. Your COE and lighthouse projects might have generated enough internal marketing for people to know the benefits of such a tool, so they should be enabled to decide.

But, of course, it is risky to let every team choose whatever they fancy in that moment, as this quickly becomes backed by trends, hypes, personal preferences or simply people that “wanted to try this out for ages”. It is important for everybody to understand that certain technology decisions are a commitment for years and sometimes even decades. So these decisions and the resulting maintenance affect more than just the current team.

What works well is to combine the freedom of choice with the reliability to operate and support the software solution in production, which is known as “you build it, you run it”. This important primitive makes the team aware that they are held accountable for their decisions. Whenever this is truly in place, teams make more sensible decisions and are more likely to choose boring technology.

Another common approach is to establish an architecture board that defines some guarding rails. Ideally, this does not dictate arbitrary standards, but maintains a list of approved tools and frameworks. Whenever a team wants to use something that is not (yet) on the list, they have to discuss it with that board. Teams need to present the framework and the reasons why they need exactly this tool. This can even lead to a fruitful sparring around the tool. Teams might learn about alternatives that are better suited or they might get questions around maintenance they have not thought of. But of course they can also convince the board and get a green light.

I have also seen more rigid gatekeeping at customers, especially around bridge technologies that can easily be abused. For example when a team wants to use RPA, they need to build a case for it, because this will increase technical debt.

Perception Management: What Is a Camunda Solution?

Customers use Camunda for very different use cases. One theme is to build solutions that are essentially Java applications, but with some workflow embedded. Internally, these applications might be seen as “Camunda projects”, even if the workflow part of the application is relatively small.

While this is not a problem, it comes with a risk. There might be huge bespoke applications being built. That means, it can take a lot of time before they are actually put into production. Or the projects might get very expensive, or even cancelled due to problems while building the applications. All these factors are not at all related to the Camunda workflow engine, but because the projects are connected to the Camunda ‘brand’, this might damage workflow automation as a topic and make it harder for your team to get the green light for future projects. This applies to any new technology you are introducing, not just to Camunda.

Keep an eye on this risk, even though we like that you talk about Camunda internally 🙂

The good news is: With a lot of customers moving more towards using Camunda as a standalone workflow engine (e.g. with Camunda Cloud or Camunda Run + External Tasks), this risk is reduced.

Ready for more?

In our next blog — the final in this series — we’ll dive into how you can create a rockstar project team by playing to individual strengths, and foster internal collaboration.

If you’re interested in more insights, have a look at the Camunda Consulting team’s Customer Success Path, which steps through the most effective way of introducing Camunda as a new BPM platform inside any company.

  • Publishing “Practical Process Automation”

    A Book about Orchestration and Integration in Microservices and Cloud-Native Architectures I am happy to share that my new book called “Practical Process Automation” is officially published by O’Reilly today. In this book, I distilled my practical experience implementing process automation solutions from the last two decades. What You Will Find In The Book A general introduction to process automation and the different forms of automation An explanation of how developer-friendly process automation can be applied in modern system architectures and software development practices A hands-on guide to lightweight workflow engines and BPMN as the core elements to make this happen Architecture guidelines and best practices to implement your own process solutions A discussion of typical misconceptions around process automation...

    Read more
  • Camunda Closes $100 Million Series B Funding...

    I am excited to share that we just completed a €82 million (approximately $100 million) funding round led by Insight Partners. The round also included our existing investor Highland Europe from the Series A. You can find the official press release here. In this blog post I want to comment on this funding round in my own words and briefly walk you through the story of Camunda. But first things first: Who is Camunda and what do we do? Who is Camunda and what do we do? Camunda provides process automation software that is used by our customers, such as Allianz, ING, Vodafone, or Atlassian, to automate processes they need tailor-made for their business. In essence, Camunda provides software to build software. For example...

    Read more
  • Communication Between Loosely Coupled Microservices

    In our recent webinar titled “Communication Between Loosely Coupled Microservices” we got a lot of great questions and because of the limited time some were left unanswered. As community questions are really important to me I want to follow my tradition to answer remaining questions in a blog post (as I have for example also done roughly a year ago in “Webinar FAQ for Monitoring & Orchestrating Your Microservices Landscape using Workflow Automation”). What Was The Webinar About? You can find the slides (here) and recording (here) online. The webinar covered different styles of communication. This was explained by looking at how ordering food works: Synchronous blocking: A call uses a synchronous protocol, like HTTP, and blocks for the result. This is you, calling a pizza...

    Read more