JamOps: not a tool, but a conviction about quality

How an internal script grew into a philosophy about quality, control and DevOps in Mendix

Anyone who knows JAM-IT knows that we believe strongly in structure, quality and ownership. Not as buzzwords, but as a foundation. What fewer people know is that our biggest product, JamOps, did not start as a product but as a necessity.

Talking to Armando and Martijn, one thing quickly becomes clear: JamOps was not thought up because "yet another tool" was needed. It came about because they were missing something fundamental.

The limits of manual control

Before JamOps existed, the way of working within JAM-IT was guarded manually. Conventions, security agreements and quality rules were checked between colleagues. In a small team that worked well.

But as projects grew and more developers became involved, that control became less self-evident. Reports gave insight, but did not always lead to action. Deviations were left unaddressed and some mistakes only came to light later. The dependence on manual discipline started to chafe.

Martijn had experienced this before in the Java world. Tools that analyse code and check quality have existed there for years. But there too he saw the same pattern: things were reported, but not always acted on; warnings without consequences.

That did not feel right. "If quality is optional, it gets postponed. And what you postpone piles up."

When he saw at JAM-IT once again that developers were building without direct checks on whether agreements were being followed, it became clear: we have to automate this. Not to police people, but to guard the standard. Within the Mendix world such a solution simply did not exist. So we built it ourselves.

From script to platform

The first version of JamOps was not yet a platform as it is today. There was no dashboard and no visual environment, just a collection of internal scripts that we used to guard our own way of working. Those scripts did what they had to do and helped us keep control of quality and agreements within projects.

Even so, this approach had its limits. The solution was technically effective, but not scalable and not transparent to others. That changed when a client asked how competitors had set up their DevOps structure. In that conversation it became clear that in essence we had already developed something that went beyond an internal aid, it just was not visible or accessible as a product yet.

The need for a visual layer grew, both internally and with clients who valued transparency and traceability. What began as a practical internal solution thereby took on a broader meaning. Out of that development came JamOps as it exists today.

Not warnings, but clarity

If you had to describe JamOps in one sentence without naming features, then according to Armando it is a Swiss army knife for Mendix development. Everything we were missing, we added. But what really characterises JamOps is the philosophy behind it. We do not believe in warnings you can ignore. We believe in clarity. It is either good or it is not good. No grey area. That sounds strict, but in practice it turns out to be liberating.

When a developer commits, they get feedback immediately. Within a minute it is clear whether the change meets the agreed standards. Is there a security risk in it? A pattern that is prone to errors? A dependency that is vulnerable? Then the pipeline stops. Not to block, but to protect.

"Immediate feedback works, because the developer is still in the context of the work. The problem is small, manageable and solvable. Not hidden in a report that gets read weeks later."

Why quality is not optional

For JAM-IT, quality is not only about tidy code, but about being future-proof. Working to clear standards from the start prevents projects getting stuck in technical debt later on. A solid foundation gives room to keep developing without having to go back to the drawing board every time. That is why quality is not a preference, but the starting point.

What changes in practice?

In day-to-day practice, JamOps mainly means that safeguarding quality is no longer a separate step, but an integrated part of the development process. For developers the system acts as a continuous layer of checks that watches as changes are made. For less experienced developers in particular that offers something to hold on to: patterns are guarded, deviations become visible immediately and the chance of small mistakes piling up becomes considerably smaller.

Because checks happen automatically before a change moves further down the pipeline, the process becomes calmer. Deployments follow from a validated build and not from manual checks afterwards. That reduces the dependence on individual discipline and makes the process more predictable.

At team level this creates consistency. Conventions are not only agreed, but also enforced. New colleagues can step into an environment in which structure has already been captured in tooling. Quality thereby becomes less dependent on individuals and more a part of the system itself.

That way of working has an impact on security as well. Think of spotting expired certificates, unwanted anonymous access, vulnerable dependencies or patterns that are prone to errors. Such points of attention are often small in the moment, but they can have major consequences when they are only discovered late. By catching them early in the process, projects stay manageable.

More than just DevOps

Functionally, JamOps supports Continuous Integration and Continuous Delivery, runs static code analyses, automates unit tests and checks dependencies within Mendix and Java components, among other things. It also provides insight into applications, modules and configurations.

Yet the value does not lie only in the individual parts, but in how they fit together. Within traditional programming languages it is common to use tooling that enforces quality and security. In low-code environments that was much less self-evident for a long time. JamOps brings that level of control to the Mendix world and makes DevOps structural there instead of incidental.

For organisations working with certifications such as ISO 27001 that plays an important part. Not only because processes are recorded demonstrably, but because compliance is supported technically. Traceability and transparency thereby become part of the development process itself, instead of a separate administrative layer.

Further development without losing the core

Since the first version, JamOps has developed further. Where it was initially aimed mainly at strictly blocking deviations, it has been extended with reports, statistics and overviews that help organisations gain insight into trends and quality developments. An API has also been added, so data from JamOps can be integrated into existing dashboards and internal systems.

Those extensions respond to different ways of working at clients, without the core changing. The underlying idea remains that quality must be safeguarded in the process itself.

Technically, JamOps runs on the Mendix platform, with the in-depth analyses and integrations largely built in Java. Automation has been the basis from the start. New technological developments, including AI, are used to strengthen the underlying technology further, but not to take human responsibility out of the process.

What JamOps ultimately represents

JamOps is therefore not a standalone tool alongside development projects, but an extension of a particular way of working. It came about from an internal need for grip and consistency and grew into a platform that makes that way of working available to other organisations as well.

The essence is not that everything is checked, but that agreements are binding. Quality and security are not assessed afterwards, but safeguarded up front.

In that sense JamOps reflects how JAM-IT looks at software development: structured, transparent and with an eye on the long term.