Introduction: The zero-code promise
Business process management (BPM) is becoming popular among business users to capture business process requirements in the form of a process model. The business team can then use existing methodologies to improve the process. The Business Process Management System (BPMS) can help technology teams execute the process modeled by business users as well as measure process execution data and present it to the users in an understandable form. Business users can then analyze the data and identify the areas of improvement for the process.
Business users have talked a lot about BPM, but not much has been said about what BPM and BPMS has in store for developers. The newly published BPM 2.0 specification promises a zero code upon implementing BPMS. That is, according to the specification, if business services are already available, business users can model the process and execute without writing any code. Can this zero-code promise be a threat to the developer community? In this article you explore the changes in system implementation methodology and in responsibilities of developers that may result from this new paradigm.
BPM follows the model-driven architecture1 concept, where a process modeler is used to create an executable process model. The process definition from the model is captured with a process definition language like Business Process Execution Language (BPEL)2 or Business Process Modeling Language (BPML). The process definition is then deployed on a process engine. The process engine is responsible for orchestration of the process instance and measurement of key performance parameters when the process starts executing. Business Process Management Server or System (BPMS) is a toolkit that implements BPM practices in an organization.
BPMS is becoming very popular among business users because it empowers them to define, maintain, measure, analyze, and continuously improve their business processes. BPMS is capable of executing application-to-application and person-to-application processes. Implementation of BPMS technology reduces time-to-market for changes in business processes. With the help of BPMS implementation, changes in business process are addressed with minimal IT efforts, resulting in faster time-to-market and business process change.
Because the process definition is available in pictorial form, it is convenient to share across the organization and it is easy to understand. This visual rendering helps business users communicate process requirements to the IT staff, reducing the gap that typically exists between the business and IT teams.
BPMS also measures and stores the process execution data, which can be used later for creating business activity monitor (BAM) reports. BAM reports can be used to report process efficiency and bottlenecks, activity alerts, escalations, user productivity, and other measurements of process performance.
A BPMS typically offers the following tools:
- Business process modeler. Used by business users to define the business process. Process is defined as set of activities in sequence, parallel, or loop
- Executable process modeler. Imports a business model from another business process modeler. The system architect adds execution details for each activity in the modeler. These modelers generate a process definition and usually generate code.
- Process execution engine. Executes the process defined in the executable process modeler and captures the process execution data.
- Business activity monitoring component. Consists of a set of reporting tools for process owners, senior management, and other business users.
- User portal. Allows end-users to participate in the process execution.
- Admin portal. For the process owner to manage the process instances. The admin portal can be used for deploying and version management for process definition.
Business Process Modeling Notation (BPMN)4, a deliverable of the Business Process Management Initiative (BPMI) standards body, is a workflow language used by enterprises for documenting their processes. BPMN is the graphical notation for representing a business process. Most of its notations cater to business users, who are comfortable with flow charts representing business processes
Business processes are elicited using process maps or workflows. Two main standards exist for capturing workflows. Business Process Execution Language (BPEL) is an XML-based standard for capturing process definition. BPEL, originally designed for orchestration of Web services, was later adopted by leading BPMS vendors such as IBM, Microsoft®, and BEA as the main standard for orchestrating any type of services or components. The current version of BPEL does not support manual activities, but new versions will. BPMS products that currently support BPEL have also added extensions to BPEL to support manual activities.
Usually a BPMS provides tools like an executable process modeler, a process execution engine, BAM support, and a user portal to allow for user participation. The system should also provide features like a business process modeler, process simulation, BAM reporting templates, a process admin portal, alert/notification mechanism, integration with user data repositories like Lightweight Directory Access Protocol (LDAP), a rules engine, and a document management server.
Most of the BPMS products offer code generation and electronic form capabilities. Some BPMS products claim to generate Web services and native application code, as well.
IBM® WebSphere® Process Server (Process Server), the IBM BPMS offering, is deployed on WebSphere Application Server. Process Server has support for short-running processes with all system activities, as well as long-running processes with human activities. Process Server offers a process modeler that enables users to model executable processes using standard BPEL constructs along with extensions to BPEL. The process engine executes the process using the BPEL process definition, which includes orchestration of Web services. The process engine also invokes components of legacy applications using an adaptor software developer's kit (SDK) and involves human participation through a user portal. The Process Server user portal implementation includes autogenerated Web forms for each human activity. Process Server also provides a testing and debugging environment for developers.
A system architect who understands the business process as well as IT applications and services can use the executable process modeler, which does what the name suggests -- provides a visual model of executable processes. That pictorial process definition is captured in BPEL, which in turn is deployed to the process engine. All components involved in process execution are deployed to the process engine or the application server. Many BPMS tools create a single deployable file, making the deployment process easier.
One or more process instances can be started on the process engine using appropriate application program interfaces (APIs) or the user portal. The BPMS orchestrates execution of services and components. Some BPMS tools convert the BPEL into executable code. Other BPM tools deploy BPEL to the process engine, which in turn parses BPEL and stores the sequence of activities in memory. In that case, the process engine is responsible for invoking activities in the desired order and passing parameters across the activities. Process engines use specifications like Web Service Invocation Framework (WSIF), Web Service Definition Language (WSDL), Java Message Service (JMS), generated native code, and adaptors to invoke the activities. Usually the BPMS tools provide the adaptor SDK to write adaptors to integrate with custom applications.
As the process instance executes in the process engine, the execution data is stored and can be used for continuous process improvement. Process execution data is used to generate reports at run time, generating alerts and escalations; this same data can also be periodically reviewed at a later time. The data can be analyzed by business analysts and process owners and used to find process bottlenecks and areas for improvements. According to these findings, the process owner then changes the process definition using the business process modeler. These changes are further mapped in the executable process modeler and changes are done in the IT layer wherever required.
The process may require some manual steps to be completed by business users. Users can participate in process execution by logging in to the user inbox provided by user portal. Users can claim, view, transfer, and complete activities.
Knowing the difference between component-based software system and BPM
At first glance, BPMS may look a lot like a component-based architecture approach, but you'll notice some key differences. First, component-based architectures create reusable software components and link them together to build applications. A BPMS follows the same concept, but its goal is the creation of reusable services that are linked together to create a process.
Another crucial difference: In component-based systems, the link between various software components is coded or scripted by developers. If there is a change in that link, the script file is changed and redeployed. In a BPMS implementation, the link between various services is drawn as part of the process model. The process model is captured in BPEL and deployed on the process engine. When there is a change to the process definition, the process model is changed and BPEL is redeployed on process engine. So, with BPMS when the process changes, there is no need to change the connecting code.
Impact of BPMS on the development team
The main impact BPMS has on the development team is that, if the system is used correctly, far less code has to be written, changed, and maintained. Let's examine why.
A typical process can involve only the orchestration of services. As long as all the services are already available, business users can define a process in the process modeler and execute it in the process engine without writing a single line of code. It is the responsibility of the IT department to keep all the required services ready beforehand. When a process change requires a change in the service definition or the addition of new services, developers get requirements from business users and write or modify code accordingly.
Let's also examine the case where a process involves execution of different types of applications, such as packaged applications, Java applications, and legacy applications. The process engine invokes such activities using the adaptor layer. BPMS tools provide an adaptor layer for integrating with existing legacy applications. These applications can be written in Java, C++, COBOL, and other languages. BPMS tools usually provide some of the adaptors as out-of-the-box functionality while some adaptors can be written by developers using an adaptor SDK to extend the adaptor layer. In that case, developers have to write custom adaptors to interact with each different type of application. BPMS products provide code generation for invoking such application components. Some BPMS tools generate code in native languages so that systems can be invoked from the process engine with the help of adaptors. BPMS products may also have the capability of generating code to convert back-end systems into ready-to-use Web services.
In addition, to enable BAM features, many tools provide preexisting reporting templates and a management dashboard. These reporting templates can be used by business users to create reports on the fly, and the dashboard can be used by senior management to monitor process execution at real time.
Many BPM tools offer integration with rules designers and rules engines. The rules of the process are defined by business users and need not be coded by developers.
Most BPMS tools provide implementation of a user portal for the users to participate in process execution and an admin portal for the process administrator to monitor the execution of process instances.
Some BPM tools promise to generate up to 70% of documentation for the process and its components. The main advantage of this is that when the process definition is changed, the documentation can be regenerated with changes on the fly.
BPMS tools further reduce the coding burden in other ways, as well. Some tools provide the option of alert and notification services for users. They may also provide support for long-running processes by storing the state of process instance. Further, they may provide ready-built ways for integrating with user repositories and various work allocation rules.
Unlike conventional application development processes, when using the BPMS paradigm, developers need not code some parts of applications, such as:
- Information related to process flow
- Transfer of data among process activities
- Measurement of process execution data
- Client code to invoke services like web services and Enterprise JavaBeans (EJBs)
- Business rules
- Process efficiency, user efficiency, and other reports
Understanding the new role of developers in the BPMS paradigm
The application development scenario is changing in light of the BPMS paradigm. Many organizations are defining their own BPMS implementation methodology. The most common methodology, software development life cycle (SDLC), may be replaced by the BPMS implementation methodology.
For example, the requirement collection phase of SDLC may be replaced by the business process model defined by business users. The requirement phase may also involve designing the user portal, dashboard, and BAM reports. The high-level design phase may be replaced with executable process model definition and design for services.
Further, the development phase may become far less code intensive. BPM can be implemented on new systems or on the existing systems. In the case of new system implementation, developers need to develop new reusable services. These services can be orchestrated by the BPMS engine based on the process definition. In case of a reengineering project, developers may develop new services but at the same time may integrate new services with existing applications. For integration with existing application code, developers may write service wrappers. Another option for integrating with existing applications is to use out-of-the-box adaptors to connect new functionality to the application. Developers may also develop new adaptors using an adaptor SDK if they are not available out of the box.
Most BPMS tools help good UI designers create UI screens with minimal coding efforts. Based on the BPMS tool capability, developers may spend less time coding UI screens for the application, but they may spend more time designing the screens using the UI designer tool provided by the BPMS tool.
Though most BPMS tools provide implementation of a user and admin portal, a project may need to use custom portals.Typically, though, the BPMS tools will provide an API to make it easier to develop such portals.
Most BPMS tools provide BAM report templates, although most projects require customized reports to be created based on the requirements of clients and management. These customized reports would be created by the developers and can be real-time reports and they may be Web based.
BPMS can be applied to an existing application that needs reengineering or to new system development. New system development may be Service-Oriented Architecture (SOA) based, which would mean development of new reusable services. New services may also be developed for system reengineering. In a system reengineering process, for connecting to legacy applications the developer needs to implement an adaptor or write wrappers to existing legacy applications to expose them as services. There also may be a need to create custom user and admin portals and customized Web forms for humans to participate. Even though many BPMSs offer some reporting templates for BAM, most BPM implementations need creation of BAM reports and Web-based dashboard for real-time reporting.
Defining new competencies for IT developers
Developers who need to implement BPMS may have to learn some new concepts, tools, and technologies. Developers first need to learn the BPM concept, along with the BPMS tool used for development. Developers need to know the capability of tools and understand the features provided by the tool out of the box.
Business knowledge of the system is always an additional advantage for the developer. Knowledge of the BPM domain can also help a developer better understand the process. Senior IT staff has to maintain the executable process model so they need to have knowledge of BPMS, the process modeling tool, and a complete knowledge of IT layer (that is, the list of available services and components).
The BPMS tools are usually Microsoft .NET®- or Java-based and are usually deployed on Web servers or application servers. Developers should have knowledge of the underlying technology of the BPMS tool being used. And developers should be competent in Web-based technology. Since, BPMS tools work closely with SOA, it is beneficial for the developers to understand concepts of SOA and to have knowledge of Web services. As many of the standards (BPEL, BPML) in the BPM world are XML based, knowledge of XML is an added advantage.
Summary: Developers still own the IT layer
In this article you learned how recent industry trends to adopt BPMS may affect the developer community. We discussed this potential new methodology for software development and the new tools and standards that have to be learned by the developer.
As a result of these changes, developers may not be directly involved in end-to-end process implementation. Business process change may need minimum changes in the IT layer, requiring less intervention by developers. But any business process requires that the IT layer be available for execution. This IT layer includes the services required to execute activities in the process. The elements of this IT layer will continue to be owned by developers.
- Article: "An introduction to model-driven architecture," by Alan Brown (developerWorks, February 2004)
- Specification: "Business Process Execution Language for Web Services Version 1.1," by various contributors (developerWorks, February 2002)
- Blog entry on business process management: "BPM 2.0," by Ismael Ghalimi (developerWorks, February 2006)
- Object Management Group Business Process Management Initiative Web page: Business Process Modeling Notation (BPMN) information
- SOA content area: "New to SOA" (developerWorks, March 2006)
Learn
-
Get details on how to use Cogito: Cogito README
-
In "Sockets
programming in Python," (developerWorks, October 2005)
learn the basic API for writing sockets as well as a module that eases socket server
development.
-
"Inside
the Linux™ kernel debugger," (developerWorks, June 2003) details KDB,
the built-in kernel debugger in Linux, which allows you to trace the kernel execution
and examine its memory and data structures.
-
Visit the developerWorks
Linux zone to expand your Linux skills.
-
Stay current with
developerWorks technical events and webcasts.
Get products and technologies
-
Download a free trial version of
WebSphere
Application Server Version.
-
Build your next development project with
IBM
trial software, available for download directly from developerWorks.
-
Get Cogito
and the Linux kernel source at The
Linux Kernel Archives.
Discuss
- Participate in the discussion forum.
-
KernelNewbies.org has many resources for people who are new to hacking the kernel: FAQ, IRC channel,
mailing list, and wiki.
-
Participate in developerWorks
blogs and get involved in the developerWorks community.
Sukriti Goel is a technical architect with Software Engineering and Technology Labs, the R and D division of Infosys Technologies Limited. Her areas of expertise include deploying business process management systems, Web services and Java. Contact Sukriti at sukriti_goel@infosys.com.
Comments (Undergoing maintenance)
Table of contents
Next steps from IBM
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
