BPM Perspective: Evaluating BPM Applications: BPM design reviews and Rubik's Cube

Brief introduction

I know exactly what you're trying to say--BPM review and Rubik's Cube? What will be discussed next, PacMan or Facebook? You will certainly ask "scott,bpm Design review and the Rubik's Cube have what relation?" "Well, let me introduce some background information first." I've been using BPM technology for about 15 years and come to the conclusion that reviewing a BPM application is similar to solving a Rubik's cube problem. BPM Solutions present themselves through a large number of patterns and application types. More importantly, a given BPM solution typically renders multiple dimensions, even in a single application. When you review a BPM solution, you must take into account all dimensions and ensure that they are properly combined with each other. Similarly, the cube is cracked to have the same color on each side of the cube. So, there is a relationship between BPM Design review and Rubik's Cube, which requires a technology that evaluates multiple dimensions as part of an end-to-end process.

Last year, a customer asked me to develop a BPM review process to support their development efforts. At first, it seemed like a simple application, but when I got deeper into the work, I realized it was much more difficult than I had originally imagined, and the complexity of designing a BPM review process involves multiple aspects that a BPM application contains or displays, and needs to evaluate each area, In order to develop methods for optimizing the improvement of the solution.

Now, let me answer your question about the relationship between the BPM design review and the Rubik's Cube: In BPM (about solving Rubik's Cube), you have multiple dimensions or colors that need to be aligned to "meet" requirements, and you need to deal with these dimensions in the right order to review a BPM solution.

A key tenet of these BPM applications is the need to combine multiple BPM patterns and application types to develop a complete BPM strategy. These patterns and application types range from straight-through processes, specialized processes, rule-centric patterns, and traditional workflows. All of these patterns take advantage of a number of different factors; As a result, when we review the BPM applications and the factors in these variants, we need to be flexible enough that when we discuss BPM design reviews in this article, I will introduce a wide range of features (different colors of the Rubik's Cube). To provide a set of guidelines that allow readers to use appropriate review techniques according to their needs.

In this column, I'll introduce a methodology for BPM design reviews based on general rules, and a method for multiple strategic customers. What I need to say is that each organization is different, so you may need to tailor these technologies for your organization.

Purpose and goal of design review: not just arranging colors

Looking at Figure 1 (commonly referred to as the "wedding cake" or the SOA hierarchy), it is clear that process applications are not independent. A business process application provides a critical layer between a customer application (for example, a user interface) and a potential business and technical services. BPM typically includes the "orchestration" of multiple business and technical components to provide composite business services, which typically require state management capabilities, although simple BPM applications may only reflect traditional workflows, such as automated human tasks. In addition to making services, BPM applications need to interact with crosscutting concerns, such as integration, non-functional requirements, data infrastructure, and governance. This is precisely why the BPM review needs more than the "arrange colors" reason, because the review is very complex and must deal with a large number of different or sometimes conflicting dimensions. In addition, design reviews typically require the involvement of multiple groups, with business teams and technical teams who need to ensure consistency between business and IT in BPM application design and development.

Figure 1. SOA Layer

Perhaps it is best to start by defining the key objectives of the BPM design review. In my experience, the goal is to:

Identify design assumptions and requirements between the business and IT.

Ensure that business and IT stakeholders are synchronized with scope and requirements.

promote collaborative development methodologies.

Accelerate development

Most importantly, reduce the level of exception before deployment.