Workflow Soluiton

This Workflow White Paper covers some of the things that customers should consider when evaluating different workflow or business logic systems in the market today.

From ease of use to how many and what types of data that a workflow management system can connect to, there is a lot to consider when purchasing a workflow system.

You will only obtain the best results from a Business Logic Management System (BLMS) if it designed to do business the way your organization does business. The single most common reason why many BLMS projects fail is that the organization did not select a system that was sufficiently flexible to accommodate its business methodology. Don't make that mistake. You can avoid failure by following these 10 guidelines:

1. Your BLMS should be fully scalable, integrate-able, and support the complete separation of business logic from the clients that use that information. This results in extreme levels of code reuse and portability. It also allows you to upgrade applications without affecting functioning, tested business logic.
2. Non-technical users should be able to create and modify very detailed levels of business logic without requiring the assistance of the IT department. The ideal BLMS should provide a point-and-click or GUI interface that empowers the user to manage the logic using symbols that are easily understood.
3. The BLMS must support a test environment that permits the business analyst or non-technical user to test logic changes before deploying the modifications to a live environment. This is the only way to ensure that changes do not negatively impact business logic integrity or compromise the production system.
4. In support of the test environment, the BLMS needs a realistic debugging process that is graphical and easy to understand. It must provide the user with the ability to adjust the logic and then run the new logic through a simulation mode to see exactly how that logic impacts results. The debugger must provide a method for adjusting parameters and data, in real time, so that the business analyst can create realistic test cases and validate each one as it is executed.
5. The BLMS should be modular so the organization is not burdened with buying more than it needs for the job at hand. That being said, each module must easily integrate with existing modules, retroactively, in order that the applications can assume added functionality as the need arises.
6. Those modules should provide built-in support for the core requirements of any sophisticated business system, including:
   1. The ability to automate decision making using a rules-based process.
   2. A monitoring engine that allows you to configure any number of check points and then lets the system take the appropriate action based upon the type of trigger received.
   3. Support for integral workflow and BPM (Business Process Management) capabilities.
   4. The ability to communicate with other systems and users via dialogs and computer-based "conversations" that closely mimic intelligent human dialog. Support for diverse communication technologies, including SALT or VoiceXML, SMS, instant messenger conversations (AOL, MSN, and Yahoo Messenger), should be included. The system should also support direct output into any HTML-based application with the same high level of configurability.
7. The BLMS needs to be able to transparently communicate with the information consumers without forcing those users or systems to know anything about the underlying technology of the BLMS, such as: the language it was written in, the version of the compiler used, or the type and structure of any associated databases. In essence, the BLMS should be capable of providing a "black box" interface where the consumer simply sends a query and receives the data back in a format that it can understand.
8. The BLMS should follow current best practices for software development and be capable of supporting Web services and other current technologies via HTML, XML, SOAP, etc.
9. The IT department should not have to endure an excessive learning curve when implementing the BLMS. Insist upon complete documentation and actual code examples to make the transition to a logicbased system easier and to accelerate the implementation and deployment process.
10. The BLMS should include access to a full SDK (Software Development Kit) that enables developers to easily create and integrate their own custom components into the BLMS without negatively impacting the system's usability, security or stability.

The goal of implementing any BLMS is to allow the organization to ultimately save money by automating tasks that used to require heavy human intervention. Unless you choose your BLMS platform wisely, that goal will be lost in a sea of development and implementation costs that could take years to pay off -- if they pay off at all.