Saturday, November 28, 2009

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.

No comments:

Post a Comment