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.

  • Automation Reinvented

    How Deutsche Telekom scaled automation fast – using RPA and Camunda  Deutsche Telekom, one of the world’s leading integrated telecommunications companies, manages one of Europe’s largest Robotic Process Automation (RPA) implementations, automating more than 450 processes managed by 3000 unattended bots. Despite achieving savings of more than EUR 93 million last year through RPA, Deutsche Telekom’s Service division, which takes care of 100 million customer requests each year, has embarked on a mission-critical journey to gradually transition from frontend to backend automation, replacing bots with APIs. Significant Scale Deutsche Telekom’s digital transformation journey began in 2015 as the business sought to tackle pain points in manual customer service processes, according to Vice President Service IT  Marco Einacker. However, with underlying...

    Read more
  • RPA and Enabling End-to-end Process Automation

    The Case for End-to-end Process Automation Processes are the algorithms that determine how an organization runs. Successful businesses grow from proven, effective processes. At Camunda, we have made it our mission to enable organizations to design, automate and improve these processes — no matter where they are and what they entail. Our ambition is to “automate any process, anywhere”.  Automation is not new, it is basically the core value of any software product. And if there was one single software product that could successfully run the entire operations of a company, there might not even be a need for Camunda. In fact, SAP tried to become that product in the 1990s. But although there are thousands of companies running SAP,...

    Read more
  • Three hidden threats of RPA technical debt...

    If you’re looking to selectively automate the work of individual components in legacy systems, and help automate processes without a significant time investment — RPA should be on your radar.  Global companies like Deutsche Telekom have already introduced and automated 2,500 individual bots, resulting in savings of more than 100 million Euros. However, relying too heavily on RPA can land you in hot water. Paul Jones, Business Automation Services at NatWest even classifies RPA as technical debt.  So what can you do to avoid this debt? Prevention is the best cure and before jumping on the RPA bandwagon, think carefully about whether you need an RPA solution, or a workflow engine. Losing control of long-running processes The ability to automate...

    Read more