by Mariano Benitez
Building BPM solutions is very different from building traditional applications. Consequently, defining the architecture for such solutions requires a different approach.
In this brief article I describe the concepts around BPM solutions and the major architectural blocks that define a software solution built using BPM. In future articles I will provide ideas and tips on how to make a proper assessment of the requirements and turn them into a suitable solution architecture.
This article is for people responsible for defining architectures or people trying to understand how BPM is implemented in the real world. I assume you have read about the AquaLogic™ BPM Suite, or you have read my previous article that describes the concepts of BPM.
I hope you find this analogy interesting: If you just need to drive a car, you don’t need to know how the engine and the transmission works. These two aspects of cars focus on different things. On one side, you learn about changing gears, making turns, looking through the mirrors, and speeds. On the other side, you learn combustion, transmission, and electronics.
In this article, the architect is the car’s driver, end-users are your passengers, and BPM is the car. Let’s take a drive!
Let’s walk through the components of a BPM solution. The first step is to define a BPM solution, the top of the pyramid.
A BPM solution is a business process running inside the infrastructure of an organization.
A BPM solution is a “live” business process doing the real work. The solution is everything you need to “execute” a business process, interacting with people and systems. The architect needs to make sure the proposed solution fulfills all the requirements, by defining module specifications and layout. We are positioned here at a high-level view, focused on the major conceptual blocks. We don’t worry how the pieces are implemented or about the complexity of each one; we are laying out the components.
This formal definition helps us define the internal blocks of the solution.
A business process is a set of activities arranged in a flow that reflects a real work process to achieve a business goal.
Here, the business process can be thought of as the process-driven application, with the model and all the integration, presentation, and logic.
Business processes are written using AquaLogic BPM Studio, and they take the form of a BPM project. Pieces of your business processes will be implemented separately, but they will be integrated in Studio and used in your BPM projects. At this point, the business process is just a definition. It is a source, it is not alive, and it needs a container to run, plus all the external dependencies, online and available for use. You need an infrastructure to host your business process.
The infrastructure of a solution is the set of services and applications that allow business processes to execute.
To execute a business process you require a BPM execution engine, along with client applications, management tools, and more, to interact with it. All these modules are included in the AquaLogic BPM Suite. This is not all you typically need. If a business process invokes Web services, reads from a custom database, or uses Enterprise JavaBeans, then you will have to make sure those services are available, otherwise the process will not be able to work as expected.
Those services become part of your infrastructure, because your business processes need them. All these dependencies are as important in the infrastructure as the BPM server itself.
The infrastructure defines how all these components communicate, where they are located, and how they are configured. It is the highest-level view of BPM: From here you can drill down into any of the components to see the details on each one. This view is important because it shows the big moving parts of the solution; both the business processes and the organization are hosted here by the infrastructure. An infrastructure normally hosts many business processes, so your infrastructure is now part of many BPM solutions. This is important because you have to plan your infrastructure to properly handle all the solutions that will run inside it. The upside of this is that you do not need to create a completely new infrastructure, so you are saving a lot of resources and management of many infrastructures.
So now, when you start to work on defining an architecture, two issues come up pretty quickly:
What defines the requirements for the infrastructure?
The business processes define many of the requirements for the infrastructure, like the external systems they depend on, and, in turn, the external systems define how to connect to them.
Business processes have an expected usage, which defines the load it is expected to receive. Within that expected usage, you also have an idea of the usage profile for the participants using the business processes. Understanding how to gather the load requirements and what the impact is on the infrastructure is very important, because it gives you the right information to properly size your infrastructure.
But IT, business owners, and regulations can also impose requirements, mostly around security, SLAs, and platforms to run the servers. All of these requirements must be considered when you design the infrastructure, since they surely affect the way the architectural components interact.
Now I will cover a very important step in the development lifecycle, where many architectural decisions must be enforced.
How is a business process installed in the infrastructure?
The action of deploying a business process includes a mapping to the organization and infrastructure. This is called deployment topology.
The deployment defines in what enterprise server the process will be hosted. This means that instances of this process will be kept in this server, clients using the process will connect to this server, and the automatic executions will also happen here. Consequently, you need to carefully plan the deployment topology of your business processes to make good use of the infrastructure you have. The deployment topology allows you to distribute processes across servers, giving you some horizontal scalability. For example, you can deploy the most user-intensive processes on one engine and the batch processes on another, configuring each one to better suit the needs of each piece.
The deployment also defines in what organizational units (OU) the process will be located. This means that you can deploy the same process in many OUs, providing additional flexibility, since each OU can have different versions of the same process.
Your infrastructure also provides the means to incorporate the people into the business process by providing end-user tools like the Workspace, but you need to define what is visible to each user and what permissions they have over the business process. You need to map your organization.
The organization is the reflection of the real people of the enterprise who will interact with the business processes.
The organization reflects the way people are grouped and the permissions for each group and individual; it also defines a hierarchical structure for the organization. Simply put: You need to define who can do what for each of your business processes. To do this, you have two different aspects: visibility and permissions.
Visibility defines the process you can see, and the permissions define what you can do inside the process. You need both visibility and permissions to work on a process. These are important tools when planning the deployment topology of your process, since they define how your organization will work with processes.
Let’s look at these definitions in a little more detail:
Visibility is defined by how your people and processes are hierarchically arranged in the organization.
Participants are always assigned to an organizational unit (OU). OUs are defined in a tree structure, with the organization as root. Processes are also deployed in OUs, so participants can view processes based on the OU they are assigned to and the OU the processes are deployed to. This is what defines the visibility of a process to the participants.
Permission is defined by the roles assigned to the participants and the roles defined in the business processes.
Participants have organizational roles assigned to them, either directly or by the groups they belong to. In the business process definitions, you also define process (abstract) roles that, when the process is published, are mapped to organizational roles. For users to be able to work on a process, they first need visibility to it, but then they must be assigned some role from the ones mapped to the process. Participants are entitled operations on the processes based on the roles and permissions they have.
Now that I have defined the concepts, it is time to link them to the real world. It is critical to properly understand the requirements of the business and the organization, and transform them into an architecture that can fulfill the requirements, making the best use of resources. The output of this exercise is not a detailed list of items or roles or participants; it is more a set of rules, guidelines, or policies that have to be used when building the infrastructure, the organization, and the processes.
So what definitions do you need to build an architecture?
The rules for mapping your organization into the BPM space
Criteria must be in place to translate the real organization into BPM, which includes defining the following things:
The infrastructure components
The distribution of applications and services and the way they communicate is a critical part of the architecture. Actually, this is the technical architecture of the solution. Here is a basic list of applications you need to include and the type of configuration needed.
The process deployment topology
Business processes have to be inserted in the infrastructure and the organization: This is the deployment topology. The topology has a direct impact on the infrastructure and on the way people use the processes. The definitions are simple, but they need to be carefully defined based on the organization and the infrastructure.
From an architect’s point of view it is very important to understand what defines a BPM solution, to properly lay out the infrastructure and define the rules for business processes to follow. This definition does not need to be complete before starting; furthermore, it will evolve as your business processes are built and you receive more requirements from the organization. The process of defining all these aspects is a long negotiation between business users, developers, and IT to reach an architecture that suits all needs.
The role of the architect is to mediate between all these people and understand the impact of a requirement on the various areas.
My role here is to give BPM architects the tools to better fulfill their jobs. I hope you find this introduction useful. I would like to hear your opinions—feel free to leave them in the comments below.
Mariano Benitez is the Integration Architect for the AquaLogic BPM Suite. He is responsible for the technical architecture of the integration of the product with other BEA and 3rd party products.