Can Charis Moutafidis work on an existing Camunda 7 or BPMN system?
Yes. Reading what already exists is where the work starts: process applications, BPMN and DMN models, Java delegates, listeners, external workers and custom plugins written years ago and still carrying the business. I read the process inventory before I say anything about a plan, because an honest number only exists once somebody has looked.
Contact Peak Code ConsultingContact Fiji Solutions
Last updated:
What an existing estate holds
A Camunda 7 system that has run for some years is made of parts that grew up together. The BPMN and DMN models sit alongside Java code written for the engine, as delegates and as listeners. Workers outside the engine pick up tasks of their own, and some are written in .NET or Node. Plugins extend Cockpit, Tasklist or Admin, and forms collect what people enter along the way.
Some of those parts were written by people who have since left, and some forms have not been opened since the person who built them moved on. That is why the reading comes first.
What I read first
I start with every repository and every business unit that still runs on Camunda 7. For each one I write down the version, the database, the application server, the Java version, the workers and the plugins.
Hard limits show up in that first reading. A database such as IBM DB2 on z/OS, for example, rules out one destination before any work begins.
I look hardest at the parts the migration tooling leaves alone. The tooling rewrites build coordinates and Java package names. It does not touch the .bpmn, .dmn or .cmmn files, the database, or the plugins for Cockpit, Tasklist and Admin, and workers written in other languages are missing from the migration documentation. Each of those is found by reading your code.
The work an existing system can take
Any work on an existing system starts with a written inventory of each process, repository and business unit, with what would move and in what order. It is dated.
For companies in Switzerland, there is the Camunda 7 migration, one of Peak Code Consulting’s offers. I own Peak Code Consulting, and I carry out the migration myself. It runs from reading the estate to a production rollout the people responsible have signed off, with a test suite you sign off before anything moves.
The same habits hold for any change to an existing system. Tests come before changes, so a broken approval rule fails the suite. Library and package changes are kept separate from runtime and database changes, so a failure points to one cause. The data is checked after the move. Everything that matters is written down: the plan, the tests and the way back live as documents and code in your repositories, so the business can carry on without me.
Which company takes the work
A company in Switzerland writes to Peak Code Consulting, at info@peakcodeconsulting.ch. The Camunda 7 migration page on its site describes the offer in full.
If your business is outside Switzerland, write to Fiji Solutions at info@fijisolutions.net. Both addresses reach me, and if the work belongs to the other company, I will tell you so and forward you there.