uEngine is one of professional open source product. uEngine has been designed to be easily embedded in all of its components to fit in its identity, Open Source. It delivers special solution for conformance to existing application architecture, the redundant functionality implementation problem as well as for the Total-cost of ownership those are caused by recently increasing enterprises’ spotlight on the BPM.
uEngine is a professional open source company as well as an open source community which first registered to the sourceforge.net in the past 2003. its main product - uEngine BPM suite is divided into three components which are: first, uEngine BPM foundation which includes process engine, modeling tool, and the fundamental management portal, And second, uEngine process portal which contains personalization, dashboard, and single-sign-on, And, for the last one, uEngine BP Analyzer which provides OLAP based multi-dimensional process performance analyzer, charting, and dashboard setting. uEngine is open source BPMS but provides most features of commercial products since it incorporates best open source products such as Liferay Enterprise Portal, Mondrian OLAP Server, JBoss Drools BRE and Apache Axis II on top of its BPM foundation framework.
Figure 1. uEngine assembles best open source products in its BI, portal, Web Service functionalities.
A component framework, which organizes the core of uEngine, enables unique integration patterns such as plug-in activity type addition using call-back implementation, single data management of external organization chart and application data using database pointer process variables. It shows features of ‘Embedded BPM’ which differs from existing package-based BPMS which can’t avoid such overheads like database synchronization batch jobs or technician-friendly EAI tooling.
A BPM Framework
uEngine has began with a component-assembling tool and many times it has been incorporated into another products under manner of OEM. This history and technical background of uEngine ease such linkage model like not only server/client model but also the library/framework model. Its call-back implementation manner enables extracting audit data from engine or connection with external instance messenger and external work list systems and packaging existing software as ‘Activity type’ so that they can be used in the BPM modeling/execution environment.
Figure 2. uEngine provides a component framework and plug-in tools in order to add new activity types so that the existing SW can be easily melt into the BPM architecture.
More specifically, uEngine defined three requirements to be a good ‘BPM framework’ as follows:
- A good BPM Framework should be seamlessly a part of system architecture that supports applications to be interoperated. Under the philosophy of the embedded BPM, the BPM is placed within another system, not integrated with the system. Consequently, it is required for the BPM to be very convenient in lying in the contexts or containers of a certain application as its part.
- From the perspective of data management, a good BPM Framework does not possess an independent data schema nor lead to the modification of data modeling within a legacy system. The data items of the application system instead are pointed by the BPM so that the redundant treatment and synchronization of data in both systems are not prevented.
- Applications are developed on the basis of their functions, not usually considering inherent business processes actively. When the BPM is embedded into the applications, it should be able to clarify those ambiguous processes as executable processes by the BPM engine. In this regards, if the BPM does not express the function of the applications as a specific type of an activity, there is substantial limitation for describing the logical processes within the applications and simultaneously melting the BPM into the applications. Therefore, whatever functions of the applications are modeled, the framework of the BPM would be competitive to create a new type an activity and use it for raising adaptability with the applications.
Table 1. Comparison of Packaged BPM and Framework BPM
| Packaged BPM | Framework BPM |
Integration Style | Client/Server | Library and Framework |
Application Data Integration | Necessary for additional development of Agent Activity, SQL Activity and Batch programs for synchronization of application data and BPM process variables | Very convenient in data synchronization by directly referencing data on tables within applications as actual values of process variables of BPM |
Event Hooking in an Engine | Impossible or if possible, it should be customized by solution developers on the basis of customer’s requirements | Possible to install a listener component that can detect various kinds of events such as process execution, quit or participant modification |
Organization Chart Integration | Required to adjust data of an organization chart provided independently by BPM to that of an existing organization chart in a customer | Solved by easily making an independent component that includes a series of procedures of aligning organization data on BPM with that on applications, rather than by developing a demon for data synchronization |
New Activity Addition | Should be requesting the development of an activity to a solution vendor | Can customize any type of an activity by considering an activity component interface and plug-in it into BPM engine. Please note activity developer doesn’t have to possess programming knowledge such as JAVA Swing |
BPM Implementation Strategy | Top-down strategy. Customers should utilize only activities that are already provided by a BPM system. | Bottom-up strategy. Whenever necessary, it is flexible to make and add a new activity for customer’s businesses. |
uEngine in Enterprise Application Architecture
The application architecture by uEngine is characterized by more seamless integration with applications than the packaged BPM and the single-point management of original data item. These characteristics are presented in Figure 1. Generally, the packaged BPM integrates application systems through message transportation in the server side by EAI. However, our integration picture is beyond just the integration of data items. BPM must support the lifecycle of a business process that comprises the stages of modeling, simulation, execution, monitoring and analysis. In this regards, BPM should also provide more elaborate process modeling tool that reflects performance indicators in a BSC system, a monitoring cockpit that shows BSC-relevant information in a process chart, a integrated worklist that include an independent BSC worklist and a process analyzer that accommodates BSC analysis data according to data structure for BPM analysis and offers its results together with that of BPM. While the packaged BPM does not provide these features for the process lifecycle, they can be conquered by the embedded BPM that possesses the callback type of interfaces and support framework-oriented development.
The packaged BPM has built-in data structure for its organization chart and process execution. For example, when the package BPM accommodates data items from an organization chart in a HR system, data synchronization between each other is required. In order to do this, cron-jobs are usually operated regularly. This means whenever an independent system is added, another crone jobs can be created for data synchronization of the added system. Therefore, as presented on the top of Figure 1, it is most likely to be full of crone jobs on the enterprise application architecture.
On the other hand, as for the uEngine, its engine does not possess its own data structure of an organization chart but, just references original sources of organization chart by setting their pointers to them. Similarly, uEngine has only to focus on the interfaces that collect data items from distributed applications. This type of integration is a technologically ground to clarify the role of each system including BPM.
Conclusions
In the market of OS, the strongest rival against MS is Linux. The Linux OS, with opening its source codes, has a convenient architecture to be embedded into mobile devices and enterprise servers. In addition, the Linux open kernel enabled software to integrate OS very closely. This OS-friendly feature played a very important role to encourage the development of open source software.
uEngine, A BPM Framework, provides a reasonable and realistic component-based development environment that can lead developers to implement and management system components in standardized ways. By this feature of ‘embedded’ / ‘framework’, uEngine would be a good choice for the CIOs who want minimum impact on introduction of BPMS in their well-established existing application architecture. Also it is worth to be reviewed by the SW vendors who develop ERP, PDM, SCM, or CRM which can be upgraded towards a process-centric management information system by incorporating a BPM product.
A selection of a BPM product for a company resembles the setup of an operating system in a personal computer. Sometimes, we face the situations in which extensive operation, due to just trivial problems, is inevitable in spite of a heavy cost. BPM serves as an enterprise nervous system and so needs flexibility and adaptability. Therefore, the selection of BPM is a matter of choice, a customer will subordinately follow the roadmap of the packaged BPM or actively lead the enterprise-wide system coordination through the BPM Framework such as uEngine.
About uEngine BPMS project
