agsandrew - Fotolia
A new structured BPM design approach from Red Hat promises to bridge the world of application development and business process management, making it easier for enterprise architects, developers and line-of-business people to implement new business processes more quickly. This framework can bring business automation and modern delivery techniques together, a key element to preparing enterprises for future projects, said Justin Holmes, business automation practice lead for Red Hat Consulting, at the Red Hat Summit in San Francisco.
Microservices developers often argue that they can enable business agility more quickly with microservices and DevOps than with business process management (BPM), Holmes said. That faction said BPM is old hat, not required. Holmes countered that dumping BPM models is akin to "throwing the baby out with the bathwater."
"It is important to figure out how to use business automation and continuous integration to take the best of both worlds and bring them together," he said.
In a presentation at Red Hat Summit, Holmes described how a structured design approach to business automation marries DevOps and BPM models.
According to Holmes, the first step is building a map that illustrates the objectives that have been classically defined for BPM. One advantage is this model makes it easier to switch out different components of the infrastructure. It also makes it easier to plan the roles of various technologies in modern BPM models. This makes it easier for line-of-business operators to create and modify business logic without requiring IT. The developers are more focused on ensuring the applications provide consistent functionality as the rules change.
The goal of mapping is to increase the visibility business people have around how IT systems work and run. The next step is to map out the rules and decisions someone makes to create the repository.
The components of the model
Red Hat's vision is based on a design model for structuring conversations around enterprise architecture. These components include model business and logic, version artifacts, build package, store package, deployed package and execute business logic.
Modeling is the task of capturing business logic for execution. This logic can be modeled with application code, with the elements of business automation or the combination of both methods. This includes tools for guided editing, integrated development environments (IDE), document-based generation and spreadsheets.
A version control system is a master repository of business logic artifacts that could include application code and business rules. Versioning makes it easier to record changes to artifacts over time and enable recovery of past versions.
The build system involves the process for preparing and compiling artifacts into packages for release. These packages are stored in a package repository, which includes a master source of ready-to-deploy software packages. This is more efficient and consistent in rebuilding the package each time it must be deployed.
The deploy system executes predefined and previously validated decisions to reduce the potential for error. This includes a management console, access to application resources, a push runtime and polling runtime tools.
The execution environment includes the servers, storage, operating system, networks and other systems required to execute business logic.
Mix and match components
This basic framework looks something like a prix fixe menu. It starts with six questions, which require one answer for each component. Just like with the menu, it is important to choose one option from each of the six categories.
"It is possible to order more than one item from each category, just like in a restaurant," Holmes said. "Only it will cost more to build and maintain."
The other important thing, he added, is the appetizer does not impact the entrée. In this framework, the choice of business-modeling tool has no effect on the execution environment chosen. The various components can be switched out. These are orthogonal decisions and can also change over time.
"This is not unique to us," he said. "You can think about the same patterns with competitors or your own internal tools."
Holmes illustrated his point with a few case studies. One example featured a company that wanted to check for fraudulent charges on credit cards. The decision model reportedly made it easy to implement governance into this process. In another example, a hospital was trying to add additional functionality beyond an existing BPM system from IBM. Holmes said the design model approach allowed them to see where they had overlapping technologies that could be streamlined.
Leverage version control from development
Red Hat made an interesting architectural decision to move from a database-driven version control and build system to a Git-based version control and Maven build system in its JBoss BPM.
"This represents a massive shift for a relatively small technology change," Holmes said. "The reason is that the industry has long used databases and proprietary version control. But these don't hook into the CI/CD [continuous integration/continuous development] worlds."
Holmes said part of this decision was based on the fact that these tools are already part of the software supply chain concept that can check for the integrity of components and look for security flaws. He also stated that these questions have already been solved with the modern CI/CD.
"It is hard to do that with databases if you have to build all of the solution on your own," Holmes explained. "We decided we would not build our own build or version control systems. This is a massive shift because every rule change made goes through the same continuous delivery pipeline that Java code does."
Give developers and business same IDE
Holmes also said this new model allows business users and developers to use the same development tools for code and designing business processes. It is common in traditional business automation services to have a web portal intended for less technical users and an IDE for developers. According to Holmes, this approach separates out the responsibility clearly, and it's possible to do a few things specifically in the IDE and other specific things in the web interface.
Holmes also said integrating both of these into a common IDE makes it possible to support the idea of collaborative cross-functional teams that look like modern Agile teams.
"This approach encourages us to create cross-functional teams, where the subject matter experts and developers are on the same team using the same tools," Holmes said.
Learn how to implement solid DevOps
Why businesses need to think about their BPM models in 2016
How to overcome the technology barriers of DevOps