Turning a Model into Code
by Amy Larsen DeCarlo

Creating Change

Big returns from successful business process management (BPM) initiatives enabled by service-oriented architecture (SOA) are inspiring other organizations to launch similar projects to improve their own operational efficiencies. After all, who wouldn’t be motivated by the kind of dividends earned by the mortgage company¹ that saved millions in annual labor costs simply by reducing its 14-step post-closing process down to just two steps? Thanks to the combination of executive enthusiasm for process improvement and increasingly sophisticated business process management suites, more businesses than ever are getting on the BPM and SOA bandwagon.

Unfortunately, like many corporate projects, BPM engagements are susceptible to shifting priorities and other challenges that can delay, or even completely derail, progress. Difficult transitions, for one, can kill the momentum of any project, and BPM initiatives are no different. Converting BPM ideas into action can be a stumbling block as organizations try to integrate simulated process models into real-world production environments. Many factors associated with these changes can impede a BPM initiative’s progress, not the least of which is the human element.

Stakeholders often have agendas that conflict with a process change. For example, a BPM model may automate an operational function currently handled manually. This change will result in shifting employees currently responsible for handling that process into a different business role, which could jeopardize affected employees' roles in the organization. The way around this hurdle simple: Have a single authority in place to make decisions and keep BPM initiatives moving forward.

There are also some significant technical challenges around translating an analytical process model created by a BPM modeling tool into code that fuels an actual process improvement. Organizations need more than a business modeling application that produces an elegant flow chart; they need a solution that transforms that model into code that can be used to construct new composite applications. They also need a tool that can simulate the results, so they can test "what if" scenarios before implementation. WebSphere Business Modeler provides simulation capabilities that enable customers to test processes and associated cost savings. This type of application provides the foundation for a more agile and effective business.

Businesses struggling to turn an analytical model into something actionable don’t necessarily need a legion of developers to build new applications. Instead, organizations can employ solutions such as IBM WebSphere Integration Developer and WebSphere Process Server reduce the manual labor associated with coding the reusable components that provide the foundation for the composite applications that drive operations in a service-oriented architecture (SOA) environment.

The first of these solutions, the IBM WebSphere Integration Developer authoring tool, works with a number of IBM applications, including the BPM-specific WebSphere Business Modeler, which creates the analytical process models. In this capacity, IBM WebSphere Integration Developer can take in process data as Business Process Execution Language (BPEL) documents and other business objects from WebSphere Business Modeler and turn them into a complete executable process model. This model contains information crucial to process flow and optimization, including integration, data transformation, exception handling and user interface design. IBM WebSphere Integration Developer can then pass these executable process models to the IBM WebSphere Process Server, which manages the communications among processes and services to support a flexible operating environment.

These solutions help transition organizations from the modeling phase to the integration stage. The result is an environment that supports a more agile and responsive organization built on a foundation of composite applications. Developers can reuse components to accelerate application design and rapidly introduce new services. The composite applications can adjust automatically to various scenarios by modifying process flows. But the constant pace of both technological and organizational change means businesses can’t stop here. They need to keep up with ongoing dynamics. Next month we will examine how companies can keep tabs on how their applications are performing and make adjustments based both on how effectively applications are servicing the business and how conditions external to the application environment, including shifts in market dynamics, are affecting the company.

¹ Principal Residential Mortgage Inc. (an IBM customer since acquired by Citigroup)

Back to Homepage »

Related Articles by Amy Larsen DeCarlo