Bizagi system architecture: recommended best practices

<< Click to Display Table of Contents >>

Navigation:  Bizagi Engine > Bizagi system administration >

Bizagi system architecture: recommended best practices


The information presented here points out the most critical technical aspects that you should consider in your corporate infrastructure, in order to set up a Bizagi system architecture that performs under optimal conditions and according to official Bizagi Ltd recommendations.





Before you start

This information presented here is complementary to the sizing analysis you should carry out for your specific project (hardware sizing), and detailed documentation about specific system requirements (supported software configuration and versions).

For more information about system requirements, refer either links according to your platform:

High availability .NET system requirements.


The information presented here will not provide a guide to install or configure Bizagi Engine or any of its required components.




The best practices and requirements presented in this section consider a corporate Bizagi system architecture with the following concepts.


High availability

A high availability architecture is designed to support best system reliability (enhanced service uptime), while implying the use of redundant IT assets that avoid single points of failure (i.e, typically for mission critical business processes).

Therefore, common recommendations such as using redundant power supply for your servers, or maintaining an identical server configuration across nodes in clusters, apply for a Bizagi system architecture (along with any other similar measures).




Bizagi supports high availability by supporting cluster configuration across its different tiers, while allowing you to further scale-out the solution at anytime.




Bizagi product architecture

Bizagi is an intensive data-access application, which runs a light-weight application server given that it does not generate intermediate code.

Therefore and by being model-driven, it is critical that you ensure that the underlying infrastructure for Bizagi when accessing data is providing an optimal performance (avoiding data-access bottlenecks in general).




Regarding this architecture design, it becomes very important that your DBA performs continuous monitoring and tuning tasks, such as: Verifying the database integrity, updating database statistics, reorganizing and maintaining indexes, performing appropriate shrinks, or looking after the database growth behavior (i.e. filegroups, tablespaces).  

Common recommendations regarding database maintenance and tuning, as issued by your database engine vendor, apply to your Bizagi database.





Reference system architecture

The following diagram illustrates a general Bizagi system architecture for a corporate setup.

The sub-sections below will elaborate on best practices and requirements to consider for the different assets in each tier.



Database tier

The database tier (data access layer) is where the database engine is installed (i.e, SQL Server, Oracle).

For high availability, use 2 or more nodes in a database cluster configuration (mainly for fail-over capabilities, or to use an active-active distribution when using Oracle RAC).


The following diagram highlights the database tier configuration, and which aspects are critical for best performance with Bizagi:




As pin-pointed above, consider:



It is strongly recommended to use a dedicated database server to host exclusively Bizagi database.

This is so, in order to avoid having other databases take up the host resources and end up affecting Bizagi (or vice versa).

Assign the most RAM possible to database servers, and according to your project's sizing estimation and keep in mind that you may scale-up the database server in terms of RAM allocation.



Ensure an optimal network configuration for your cluster setup.

Optimal network characteristics must consider especially a low latency (e.g, usually accomplished by having the nodes of a database cluster in a same network segment or connected directly).

Rely on your database engine vendor's official guidelines and recommendations when setting up the cluster.

Common recommendations such as using redundant NICs for cluster synchronization will apply.



Optimal performance of the physical data repository includes following best practices when setting up a SAN, and also providing a low latency between the database nodes and the shared storage, as well as ensuring you use high-speed disks for the underlying storage (e.g, using solid state drives), so that the I/O processes do not become a bottleneck.

Regarding database files, it is very important that anti-virus software do not scan or interfere with them.



The use of Bizagi ODS configuration allows you to use BI features without affecting assigned resources for transactional operations.

Through this option, BI features (those which are not usually part of critical daily work, such as process analytics or reports) are run in separate database which is set up by means of replication technologies of the database engine per se.

This way, executing queries that typically involve large volumes of information will not impact your processes operations, especially if your system is highly concurrent.



Network between database and Bizagi

The network between the database and Bizagi servers play an important role in Bizagi system architecture.

The following diagram highlights this part and the aspect which is critical for best performance with Bizagi:




As pin-pointed above, consider:



Optimal network characteristics between the database and Bizagi servers, must consider especially a low latency (e.g, usually accomplished by having these servers in a same network segment, usually with a switch between).

It is important that an average latency of 0,15 ms is met.

A suggested bandwidth considers at least 10,000 kb in 64ms.


Digital process tier

The Digital process tier is where Bizagi Engine runs.

For high availability, use 2 or more nodes in a Bizagi cluster configuration with load balancing capabilities.


The following diagram highlights this tier's configuration, and which aspects are critical for best performance with Bizagi:




As pin-pointed above, consider:



Use a hardware-based load balancer such as f5.

Hardware appliances providing load balancing capabilities are known to support higher concurrency and overall perform better than software-based load balancers.

While using a load balancer, ensure that you configure session affinity regardless of the employed algorithm (e.g, in a .NET-based environment, this concept is known as sticky sessions).



Follow best practices for a cluster setup, and as issued by your database engine vendor.

Common recommendations such as using an identical server configuration for all nodes in a cluster, or disabling the operating system's automatic upgrades, will apply to Bizagi servers.

While maintaining an identical server configuration for all nodes, ensure that these use the same service account to access the database engine, the same service account for application start-up (and further access to attachment's file server), and the same configuration to connect to the SMTP service.

For a best reliability on your hardware sizing analysis and the load balancing algorithms, use a dedicated server to host Bizagi Engine.


Network for end users

The network used by end users to access Bizagi is not demanding in terms of bandwidth, though it should implement significant security measures.

The following diagram highlights this part and the aspect which is critical for a secure access to Bizagi:




As pin-pointed above, consider:



Security access to Bizagi is promoted by setting HTTPS support.

No special or further considerations are required in terms of the network connectivity offered to end users for access to Bizagi (Bizagi Engine is optimized and designed to support end users connecting from the internet or working on overall slow networks).

Bandwidth specification is mainly bound to the expected file size of documents attached to your business processes.

Rely on a robust firewall appliance as well for hardened security measures (e.g, Barracuda).


Other aspects

Regarding integration with your corporate systems, rely on your ESB when applicable (for business continuity support) while ensuring that network connectivity to the ESB or other systems is optimal as well.

An optimal network connectivity should consider adequate bandwidth according to the expected volume of information to be transmitted (i.e, consider the size of documents attached to the process when sending them over to another system, or the total amount of information exchanged when invoking external web services or in B2B integration scenarios in general).