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.
- Scaling Camunda Adoption in Your Company
- Phases of Adoption
- Managing, Monitoring and Leveraging the Cloud
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.
Start the discussion at forum.camunda.io