Development environment comparison

The figure above shows an overview of the BAMOE version 8.0.x development environment. Business Central was deployed alongside a KIE Server both for development and production execution. Executable KJARs were uploaded, running on JBoss EAP or WildFly. Business Central also hosted an internal Git repository (.niogit) and a Maven repository, making it the single point of control for source code, builds, and deployments.

In BAMOE version 8.0.x, development was managed in Business Central, which served as the central UI for authoring, testing, and deploying business assets. Building the project resulted in a KJAR (KIE JAR, a specialized JAR for KIE projects).

BAMOE BAMOE Canvas is a web-based modeling environment designed for business users and analysts. Unlike Business Central, which bundles all functionality into a single interface, BAMOE Canvas offers a clean and focused interface for authoring and reviewing business assets. It supports both BPMN and DMN modeling, and provides a streamlined experience for non-technical users.

BAMOE Canvas includes in-browser Git and file system capabilities, removing the need for an internal storage layer and enabling seamless integration with standard Git workflows. To support communication with external Git providers such as GitHub, GitLab, and Bitbucket, BAMOE Canvas uses the BAMOE CORS Proxy. Users can deploy development versions of their projects to Kubernetes or OpenShift environments using the BAMOE Canvas Dev Deployments feature.

BAMOE Canvas also includes BAMOE Extended Services, which enables the DMN Runner, a live feedback tool that allows you to evaluate DMN models directly within the browser.

For detailed setup instructions, refer to the Installing Dev Environment Helm Chart.

BAMOE Developer Tools for VS Code is a Visual Studio Code extension designed for developers who need to author, test, and maintain business automation assets. This extension includes graphical editors for BPMN models, DMN models, and Test Scenarios files. It also supports the generation of User Task forms, providing a comprehensive toolset for building Business Service projects.

Because it runs within VS Code, the extension stores files locally on your file system. This allows full integration with Git for version control and with Maven for building, testing, and packaging projects. Unlike Business Central, the BAMOE Developer Tools for VS Code do not include a built-in Maven or Git repository. Instead, all required libraries are retrieved from the BAMOE Maven Repository, which can be deployed as a standalone container or installed locally in the .m2 directory.

To get started with the BAMOE Developer Tools for VS Code, follow the setup instructions in the Installing BAMOE Developer Tools for VS Code. For information on configuring the Maven repository, refer to the Installing Dev Environment.

Unlike Business Central, BAMOE version 9.5 does not use the concept of Spaces. Projects are now organized using Git repositories and follow standard Maven structures. A BAMOE project can be implemented with Quarkus, Spring Boot, or plain Java with Drools or jBPM.

In the BAMOE Canvas welcome screen, you can initialize a new workspace by creating a new file, trying a sample, or cloning a repository. A workspace is a lightweight environment where users can immediately begin modeling assets. If you just start working on DMN or BPMN artifacts, you can apply an Accelerator to expand your workspace into a full Maven project structure. BAMOE Accelerators are project templates that include the necessary folder structure, configuration files, and dependencies, see BAMOE Canvas → Using Accelerators.

For developers using the BAMOE Developer Tools for VS Code, Accelerators are also the recommended way to start a new project. They provide a ready-to-use project structure with all required dependencies and configurations for building and testing Business Service projects.

You can also manually create the folder structure and configure the project using standard Maven conventions, see Getting Started → Initial project setup.

In both cases, the project is managed as a standard Maven project, with all assets stored as plain text files. This makes it easy to integrate with Git for version control and to use Maven for building, testing, and packaging.

BAMOE Canvas offers a streamlined, browser-based environment for modeling and reviewing business assets. It supports both BPMN and DMN modeling through intuitive graphical editors. You can start your workflow or decision model from scratch, import an existing file, or explore sample projects from the BAMOE Canvas welcome screen, for more information see BAMOE Canvas → Creating Models

The Problems tab offers real-time validation, and the DMN Runner enables users to test decision models directly in the browser using sample input data, making it easy to iterate and validate logic.

The BAMOE Developer Tools for VS Code offer a full-featured environment for developers to author and manage BPMN, DMN, and SCESIM assets. The extension leverages the built-in VS Code Problems tab to provide real-time validation. It also supports generating user task forms and integrates with Maven for validation, testing, and packaging. This setup gives developers full control over the development lifecycle using familiar IDE workflows.

In BAMOE version 8.0.x, Business Central managed source code through an internal Git server. Projects were stored in a hidden .niogit directory on the server’s file system, and access was limited to the Business Central interface.

In BAMOE version 9.5, integration with Git is a core part of the development workflow, but the approach is different.

While BAMOE Canvas simplifies Git for business users, the BAMOE Developer Tools for VS Code provide a more powerful and customizable Git experience for developers working in a traditional IDE environment.

BAMOE Canvas includes built-in Git capabilities in the browser. Users can initialize a Git repository from a workspace, clone existing repositories from platforms such as GitHub, GitLab, or Bitbucket, and perform common Git operations such as commit, push, and pull.

BAMOE Canvas uses the BAMOE CORS Proxy to enable communication with external Git providers, and it must be configured in the BAMOE Canvas settings. Users also need to provide Git credentials or personal access tokens to authenticate with their chosen Git provider. Once configured, business users can collaborate on shared repositories with developers, without needing to understand Git internals or use a command-line interface.

BAMOE Developer Tools for VS Code rely on your local Git installation. Git operations are performed using the built-in Git support in VS Code or through the command line, offering full control and flexibility for experienced users.

This setup also allows for advanced Git features such as branching strategies, submodules, and integration with CI/CD pipelines.

For more information on connecting BAMOE Canvas to your git provider see Installing Canvas and Canvas → Connecting to AI, Git, and Cloud Providers

In BAMOE version 8.0.x, Maven builds were triggered internally by Business Central. When a project was built through the UI, Business Central used an embedded Maven engine to compile the assets into a KJAR (KIE JAR), which was then deployed to a KIE Server. The internal Maven repository was also managed by Business Central, and users had limited visibility or control over the build process.

In BAMOE version 9.5, projects are built using standard Maven tools, and the build process is fully externalized. The BAMOE Maven repository provides all required dependencies and can be deployed as a standalone container or installed locally.

BAMOE Canvas does not perform builds directly, but when a workspace is initialized with an Accelerator, it includes Maven configuration files that reference the BAMOE Maven repository. Projects can then be exported and built externally.

For developers using the BAMOE Developer Tools for VS Code, the BAMOE Maven repository is a core part of the development workflow. Projects are built and tested locally using Maven, and the repository ensures that all required libraries are available during the build process. This setup supports full automation and integration with CI/CD tools, making it suitable for enterprise-grade development.

For more information see Installing → BAMOE Maven repository.

In BAMOE version 8.0.x, user authentication was handled through a centralized login screen provided by Business Central. Authentication and user management were typically delegated to the application server, such as JBoss EAP or WildFly, using standard Java EE security mechanisms. This setup was tightly coupled to the deployment environment and often required administrative configuration on the server side.

In BAMOE version 9.5, authentication is decentralized and aligned with modern cloud-native practices. BAMOE Canvas and the BAMOE Developer Tools for VS Codehandle authentication differently, based on their integration with Git.

In BAMOE Canvas, authentication is handled externally by the Git repository, which means that BAMOE Canvas does not maintain its own user directory. When connecting to a Git repository, users must authenticate using credentials or a personal access token associated with their Git provider (e.g., GitHub, GitLab, or Bitbucket). For more information see Canvas → Connecting to AI, Git, and Cloud Providers.

The BAMOE Developer Tools for VS Code rely on your local Git configuration for authentication. When interacting with remote repositories, authentication is handled by the Git client, which may prompt for credentials, use SSH keys, or access stored tokens depending on your setup. This approach gives developers full control over how they authenticate and manage access to repositories, integrating with enterprise Git workflows and credential managers.

By shifting authentication to Git, BAMOE version 9.5 eliminates the need for centralized user management within the platform itself, offering a more flexible and secure model that aligns with modern development environments.

In BAMOE version 8.0.x, builds were often triggered through the Business Central UI, which provided an integrated authoring and deployment experience with a connected KIE Server. However, alternative approaches were also supported, such as building with Maven and deploying through CI/CD pipelines, depending on the project setup and environment.

BAMOE version 9.5 adopts a more open and developer-friendly model. Projects are structured as standard Maven applications, allowing developers to build using the Maven CLI, integrate with IDEs, and automate deployments through CI/CD pipelines. Deployment targets include Kubernetes-native solutions.

While BAMOE Canvas itself does not perform builds, it supports development deployments through the Dev Deployments feature. This allows business users to validate their models by deploying to a live Kubernetes or OpenShift environment, see BAMOE Canvas Dev Deployments

This feature is especially useful for business users who want to validate their models in a live environment without needing to understand the full build and deployment pipeline. It bridges the gap between modeling and runtime testing, enabling faster feedback loops.

For developers, the BAMOE Developer Tools for VS Code provide full control over the build and deployment process. Projects can be built using standard Maven commands, and the resulting artifacts can be deployed to any supported runtime, including Kubernetes, or OpenShift.

Developers can also configure local or remote development environments, use containerization tools like Docker, and integrate with CI/CD systems. This flexibility allows teams to adopt modern cloud practices and tailor their deployment workflows to their specific needs.

The Standard Operating Environment (SOE) for BAMOE has evolved significantly between version 8.0.x and version 9.5. These changes reflect the shift toward a more cloud-native, containerized architecture in BAMOE version 9.5, which impacts supported platforms, middleware, and system requirements.

To understand the specific differences in supported environments, refer to the official IBM compatibility reports: