BPM y Arquitecturas de Software

These aspects are relevant when implementing and executing a solution based on BPM tools, a philosophy that allows specifying each of the steps involved in a business process: its identification, modeling, development, implementation and administration. In this way, there are concepts of software architecture that can be extrapolated when carrying out process management according to BPM. In [1] these concepts are focused from three points of view: Production or deployment, architectural styles and hardware estimates .

Deployment

From a deployment perspective, it is important to think about the configuration that the BPM architecture will have when managing the organization’s business processes. A correct configuration will explore 4 different angles: the development environment , which includes configuration, testing, and bug correction that arise from the application of BPM tools; the testing environment , which, like the traditional stage of software development, will be focused on corroborating that the different acceptance criteria are met; the «staging» environment, which essentially functions as a secure virtual environment to run products in production (often optional depending on the scale of the project); and the production environment , where the different processes will be applied.

Architectural Styles

The application of an architectural style will depend on the BPM toolset selected. A stand-alone or single-tier style provides a single structure to store all BPM components (BPM engine, application manager, databases) on a single machine or server. The main advantage of this approach is simplicity and less administrative overhead, although complex deployments will require a different approach.

A two-tier style allows the BPM engine and application manager to be located on different servers, allowing for greater concurrency and better performance.

A three-tiered approach allows for dedicated services for each BPM component individually. Obviously, maintenance and monitoring become more complex, but the scope of projects that can be covered increases.

Finally, in a multi-tier style (with 4 or more), the BPM components are located in separate layers, with dedicated servers. This style requires special care in matters of load balancing and synchronization between the different layers, an aspect that is often underestimated.

Hardware estimates

From the hardware estimation point of view, BPM aspects must be considered. This point is often overlooked, and constitutes one of the most common mistakes when implementing a BPM solution. The main BPM issues that influence the estimation are: the number of processes per year/month/day/week, the number of activities in each process, the number of users involved, integration with external services, the organization’s experience in BPM solutions, and the organization’s current IT infrastructure.

A concrete case

A typical case of a layered BPM architecture is illustrated in reference [2], combining BPM management with SOA -style service orientation. style service orientation .

The main layer is the service application layer, which represents the heart of the system. This shows the link between BPM and SOA, as detailed in [3].

Using BPM, SOA focuses on process services to develop complex business flows. BPM adds additional power for service composition and allows a communication flow to be modified dynamically. Finally, BPM provides the ability to control processes and execution units over the long term, ideal for the context of transaction-based applications.

The immediate layer is the communication flow layer. There are various technologies that can help with this. For example, an orchestration engine like BizTalk is perfectly suited for automated systems. The goal of this layer is to model the interaction between services.

The presentation layer is the classic “Front End”, where the entry points to the offered services are displayed. This layer has its complexity, including concepts such as security, authentication, internationalization, and customization of features and structure.

Finally, an integration layer allows the system to be combined with external systems.

How to approach a BPM architecture

Reference [4] describes some preliminary steps to take into account when facing a BPM architecture. A good architectural BPM design includes examining the project from step 0: that is, having a broad and complete overview of the scope of the system. This includes having a deep knowledge of the system’s behavior and knowing how to discern between detailed design and high-level design. Without having these aspects clear, the architectural development will suffer serious risks to complete its success.

Other useful tips are also described in [4]. For example, a BPM architect should focus on the local perspective of the company, and not consider the global view of all the partner companies involved. This last aspect only needs to be taken into account to ensure that the services satisfy the integration with the partners. Another tip is based on the old saying “don’t reinvent the wheel”: it is rare to have to build an architecture from scratch. One should always try to use functionalities already included in many frameworks such as security, logging, connection management and more.

References

[1] http://blog.andrewrivers.co.uk/2009/04/description-of-bpm-architecture.html

[2] http://www.bptrends.com/publicationfiles/05-06-WP-BPM-SOA-Behara.pdf

[3] http://oreilly.com/catalog/essentialpm/chapter/ch02.pdf