Technical Concerns with BPM

	Bookmark This Page Email This Page Format for Printing Submit an Article Read More Articles
	Related Tools & Articles 10 Things You Can Do To Improve Your Business with BPM Right Now 5 Trends in Business Process Management Combining Business Process Management and Workflow
	Discussion Forum "First, key areas are best viewed not as areas but as Integrated Functions (IF). Look at it from this perspective: There are functions I want to tackle,..." Contribute to this Discussion

By Denouvre de Beer

During my 12 years of IT development, I've been exposed to many challenging technologies that proved either to be beneficial or limiting in my career path. Recently, I was given the opportunity to assist with a business process management (BPM) development cycle using well known workflow software. This article concentrates on the challenges (both technical- and business-related) I faced when embarking on this journey.

The term BPM can have many different meanings. Here's how Gartner defines it: "It is the modeling & management of processes that promote systems integration for integrated business processing. One of the main goals of BPM is to enable managers to save time and, therefore in the long run, money."

BPM technology should be approached from two directions. First, prior to the BPM analysis, it requires analysis of the following areas:

• Client processes
• Business governance
• Business strategy
• IT governance and strategy

Why? BPM is the conduit between business directives and their integration within a technological environment. To ensure the success of a BPM implementation, both the governing policies and strategic directions need to be considered.

Second, once the base business and IT analyses have been done, the client requirements are conducted. After assessment, these requirements must be aligned to the business and IT governance and strategic directions.

I will now cover the integration issues I faced when implementing BPM, concentrating specifically on the technical challenges we encountered using the software designed to implement workflow processing.

Lack of Understanding

Organizations considering BPM must have a good understanding of the differences among business process modeling, business process management and what the various software tools offer. I recommend using analysts who have studied the business process modeling approach and have a good insight into what should be done to achieve ultimate process agility and development. Business and process analysts must be of such advanced skill levels, that detailed processes are defined not only with the organization's business strategy in mind, but also with an all-encompassing eye for defects and possible enhancements.

Skilled process analysts that are both business- and technically-minded will design processes with re-usability, maintainability, performance and reliability in mind.

Experienced process developers will make the difference as to whether project delivery is an ongoing success or not. If developers are still finding their way around the software or have just stepped out of training with very little modeling experience, this could impair the timetable for delivery.

Get the Basics Right

Processes will take time to mature! As one report points out, "The benefits will far outweigh the implementation costs when process maturity is reached, provided [and I think this is important] that all parties involved at this stage are capable of defining processes properly, identifying risks and planning around them."

How do you manage such an approach? In an ongoing manner, trusting that the business and process analysts have left room for improvement when it comes to process definitions, enhancements and integration. It is best practice to get senior managers to identify risks upfront and the project managers to manage these risks, changes and control measures required to ensure above-average delivery.

Processes

Process analysis, process engineering and process integration are three distinct fields and need to be addressed as such. Each requires a defined method of approach from a specific mindset. Whenever you address these areas, ensure it's addressed from the right perspective, so that successful delivery is attained.

Key Roles in Assessing the Workflow Tool

In my opinion, the software architect and middle/lower management, who understand the technical systems integration platforms, are best suited to make software purchasing decisions. Often senior management isn't close enough to the development lifecycle and is unaware of the technical challenges that may arise with the purchasing of any given workflow software.

Integration

When approaching technical integrations within the BPM perspective you need to keep the following guidelines in mind.

First, any organization deciding on any level of integration must ensure they actually have an integration strategy. This strategy should take a larger perspective than just the BPM component, using the business and IT governance and strategy as sources for definition.

Second, an important consideration when implementing BPM system integration is to figure out where the business logic must lie. Often you might shortcut the implementation by placing the business logic in the "coded integration layer." I don't consider this the best approach to take for workflow development. The strength of BPM should be the containment of business logic within the BPM process; thus it's able to be defined and altered as the business changes. This also removes the dependency on the "coded integration layer" and allows for rapid process change and implementation. Integration layers should "expose" their abilities and allow the BPM layer to manage the logic required (within reason, of course).

Third, various methods of communication for integration should be considered. The "one size fits all" approach isn't necessarily the best or most efficient when it comes to BPM. Another important consideration when looking into integration is whether or not other systems will be required to access this system or the integrated process data will require exposure to external systems. This may affect both the scope and architecture of the integration.

Other considerations applicable to integration include the following:

• Does the underlying system contain rule sets that need to be adhered to?
• Must the BPM layer implement functionality that will be replaced when integrating into other systems?
• What are the possible methods of communication to be used when communicating with other systems? Pushing or pulling data is the key to successful integration.
• What are the integration issues regarding platform compatibility, if any? If there are obstacles, what are the possible resolutions, and will the organization be willing to accommodate this?
• How will you achieve transactioning across system boundaries, within and across processes within a system? What are the main considerations for optimal component and data transactions?
• What are the data mapping issues and possible resolutions?

Pilot the Software

Use technically competent resources within your own organization to deliver expert opinion on the product's capability. Using your own organization's resources will ensure that the solutions developed are in the organization's best interest and not a "slap-dash" approach by the vendor's representatives. Also during the pilot phase of the project, ensure that the most difficult and challenging technical issues are appropriately addressed and resolved.

Other applicable considerations include:

• Static or dynamic reporting requirements. Pilot some of the most complex reporting requirements to see how functional and accurate the software solution is and how it affects performance.
• Understand the underlying data structure – it is the most important thing you will ever do. Databases reveal functional relationships that aren't necessarily evident to the developer or, more importantly, supported by the workflow tool. Investigate what happens to the processing data via the workflow engine before it reaches data storage.
• Construct standard policies and procedures together with the best architectural approaches for workflow development. For example, using stored procedures might be the best practice for a specific Microsoft development project, but may not constitute the best architectural approach for workflow development, due to the workflow's engine processing requirements.

Not an Application but a Process

Some would consider the final workflow product immature, based on other existing software technologies available. However, the battle continues as to whether this is so when, in fact, the final product is not an application but a process as meant to be. Or could it possibly be that the analysis carried out was from an application perspective and not a process perspective?

I have found that when an analyst or developer who is used to performing implementation within a given technology must work with a new workflow tool, they'll face a decision: Where the simple basic concepts that were previously available are no longer available in the workflow tool, should they adapt to this different approach or implement what they already know?

Conclusion

Business now requires IT to not only understand technical infrastructure issues, but also the greater organizational strategy and business tensions. BPM implementations will fail to secure true business improvement if they don't address and comply to the requirements of the organization holistically.

With the introduction of service orientated architecture (SOA), many companies now look at BPM as a platform through which they can create process-driven procedures that interact with the rest of the organizational structure through the service layer. One of the dangers facing BPM is the movement from simple human interactive BPM procedural approach to one where clients require BPM processes to function as applications and integrate with the various systems contained within the organization. While this is possible through certain BPM toolsets, it requires a different approach both technically and analytically from the more traditional process analysis. The incorrect structuring of this new approach will result in poorly implemented BPM processes. Businesses approaching BPM from a traditional application development approach will have many lessons to learn, as will process engineers required to implement BPM processes that include a stronger application approach.

Consultations and special thanks to: C. Buske with Byte Technolgies.

Useful Links

"Business Process Management and the Future of BPM" by Gartner's Jack Germain
http://www.cio-today.com/story.xhtml?story_id=132002B1ZE2O

"Building a Business Case for BPM – a Fast Path to Real Results," published by Metastorm
http://www.transformationandinnovation.com/documents/BuildingaBusinessCaseforBPM.pdf

About the Author: