The Top Five Things Every IT Manager Should Know Before Deploying a BPM Solution

The Top Five Things Every IT Manager Should Know Before Deploying a BPM Solution January 2004 WITHOUT A DOUBT, BUSINESS PROCESS MANAGEMENT (BPM) IS ONE OF THE FASTEST growing segments within the technology landscape. But, as many IT managers know, every hot market also has its share of bandwagon vendors whose products may be functional in the short-term, but completely unsuitable for long-term viability within the enterprise. The purpose of this document is to help IT managers understand and identify the top 5 essential characteristics that every BPM solution must address for long-term success within the enterprise. Today, technology managers are at a clear disadvantage when it comes to evaluating products in an emerging market like BPM. Features and functionality varies widely between vendors and there is no clearly defined scorecard to compare product performance. So how then are managers to make reliable decisions and how can they best determine which BPM capabilities are nice-to-haves, and what attributes are absolutely critical for longterm success? If you are looking at BPM as an enterprise technology, then one thing is clear: more important than any feature, function, bell or whistle, the solution you choose must have the right architecture for long-term enterprise scalability, extendibility and interoperability. The following sections outline the 5 architectural imperatives for any BPM solution and how these technology characteristics impact long-term enterprise viability and ultimately, the success of the BPM implementation. 1. Native J2EE and Standards-Based Architecture 2. User Interaction Layer 3. True Component Architecture 4. Object Model 5. Converging BPM and App Dev Functionality Page 1

#1 Native J2EE and Standards-Based Architecture The J2EE platform provides many inherent services for native J2EE applications such as resource pooling, clustering, load-balancing, transaction monitoring, messaging, etc.. As J2EE grows, these services are immediately available to native J2EE applications. Conversely, non-j2ee BPM products have to either implement these services (which are not part of their core competency), or not implement them at all, limiting the scalability of the solution. For example, Q-Link s Business Process Management development platform was designed and implemented as a native J2EE application. Meaning, the services within Q-Link are composed of standard EJB components: Stateless Session Beans, Entity Beans, and Message Driven Beans (MDBs). There are no external services needed to run outside of the J2EE container. The Q-Link platform is also based on proven, best-practice J2EE design patterns that J2EE developers/shops are familiar and comfortable with. Native support for J2EE provides the following benefits: Easier maintenance - The platform is deployed and managed like any other J2EE application. Best-of-Breed Scalability & Resource Management Customers can scale from using the JBOSS open source application server and an embedded Java database, such as Pointbase to using WebLogic 8.1 and Oracle 9i. Standard Skill Set Developers and administrators familiar with J2EE standards and configuration will inherently be familiar with developing and administrating native J2EE solutions, requiring no specialized skill sets. Extensive Set of Services/APIs - All J2EE standard APIs (JNDI, JMS, JTA, JAAS, JDBC, JAXP, etc.) are integrated and available. The importance of having a native J2EE architecture can be seen in this recent example: in January 2004, Q-Link 5.2 introduced the ability to model distributed (XA) transactions within a workflow. Process designers can now wrap one or more steps of a process within a distributed transaction, and each step has an associated workflow component that may or may not be transaction-aware. In the former case, the work accomplished within the step will be involved in the workflow engine s transaction, while in the latter case the workflow engine s transaction will be suspended until the step-related work is complete. This XA support is one example of the inherent benefits of being a native J2EE application. By leveraging the transaction services offered by the J2EE container, (JTS & JTA) Q-Link could create transactional contexts and transactional components without adding a proprietary distributed Transaction Monitor. Another essential attribute is a stateless architecture. Besides the data dictionary, which is cached in Entity Beans, every other aspect of Q-Link s platform is stateless. This is important in that it enables much easier configuration and performance for the high-availability, faulttolerance, and load-balancing features of the J2EE container, more often than not collectively -implemented using clustering. Furthermore, Q-Link s Stateless Architecture is a reflection of its use of standard EJB components, and therefore not relying on proprietary caching and locking mechanisms outside of the container. Instead, Q-Link stores all process related run-time data with the database, uses Java s Transaction API (JTA) to ensure the ACID properties of an process related transaction, and delegates the locking of objects/data to the underlying data store (leveraging the years of experience in data caching/locking offered by database vendors). Page 2

In addition to J2EE, long-term enterprise interoperability necessitates a BPM architecture based on leading industry standards. For example, Q-Link runs as a native J2EE application, and has adopted XPath as a default expression language and XForms as the mechanism for gathering front-end information. More importantly, the adoption of XPath and XForms served as precursors to the adoption of other XML standards which include XML Schema & Business Process Execution Language (BPEL) and XQuery. Combined, these standards ensure long-term interoperability. #2 User Interaction Layer Forms are an inherent, but often overly-complex mechanism, used for gathering data within an application. Forms interact with end-users collecting data that will be validated against business rules, utilized for routing and controlling the flow of work, parameterized and marshaled into service calls against remote functions/objects, and then rendered in yet another form. Forms are often a major bottleneck in many BPM products for the following two reasons: First, BPM solutions have relied upon various presentation technologies, whether it is a host programming language such as Visual Basic, ActiveX, JavaBeans, and/or a tag-based framework such as Java Server Pages to create forms for user interactions. This typically entails creating forms in a separate, non-integrated environment through coding and code generation. More importantly, this reliance on specific presentation technologies creates the problem of constructing multiple versions of a form - one for each presentation technology/ layer used to interact with a given process. Creating different versions of a form for different technologies and devices that, in the end, interact with the same underlying business processes engenders extra development, expensive maintenance costs related to crossplatform consistency, and complicates the problems of configuration management. Secondly, there is no effective way of managing the relationship between forms and backend services, requiring the bi-directional mapping of data between form and process contexts. While Web Services clearly provide the answer for many back-end interoperability requirements, there still exists the need to fulfill front-end interoperability requirements as well. However, equally important is the need to integrate front-end forms that collect data with the back-end services that utilize the data. This integration can be accomplished by weaving together a set of sequential and parallel business activities, made up of user interactions (forms) and calls to backend services (Web Services), into a single business process. Q-Link, for example, addresses both of these issues by implementing a platform-independent representation of forms. XForms, which are integrated directly into both design and runtime environments, can be plugged into multiple presentation technologies/devices. Furthermore, Q-Link provides a mechanism for mapping independent form context/data (which is versioned and stored within Q-Link) to one or more process contexts for which it is being used. The following quote from the W3C provides a base definition for XForms: XForms is an XML application that represents the next generation of forms for the Web. By splitting traditional XHTML forms into three parts XForms model, instance data, and user interface it separates presentation from content, allows reuse, gives strong typing reducing the number of round-trips to the server, as well as offering device independence and a reduced need for scripting. Page 3

In the context of Process-Oriented Application SM development, a more specific definition is needed. XForms is an XML language that provides a device-independent representation of interactions, utilized to gather data for purposes of instantiating a business process and/or completing a step in a business process. This definition stresses the requirements of deviceindependence as well as the integration of front-end interactions into the definition of a business process. The use of XForms in this context results in the introduction of a new layer in the traditional three-layer application stack as shown below. As non-desktop devices have become more prevalent, the issue of representing user interactions in more than one presentation technology for a particular application has become more apparent. The interaction (form) needed to initiate or interact with a step in a given business process should only have to be defined once, effectively componentized at the interaction layer, and should then be available to be rendered in a.net windows client, Portal, a Java Foundation Classes (JFC) client, and/or a PDA. #3 True Component Architecture A true, component-based architecture is critical for long-term enterprise success. Although many products claim this functionality, components are different than other mechanisms -- such as bridges and adapters -- used by many BPM vendors. True components exhibit the following characteristics: Design & Runtime Integration Components are not only defined by the service/business logic that they implement at run-time, but also by the UI needed to gather information from the process and/or form designer at design time. The UI that the designer interacts with is specific to that component and can also interact with back end systems at design time to help the process/form designer along. This design-time integration is a requirement to truly enable the ease of use aspect of a model driven environment. Separation of Roles A key concept in J2EE is the separation of roles, referred to as division of labor in Sun Microsystem s J2EE blueprints. This concept is reinforced with component-based architectures in that software developers write components, system administrators deploy components (being prompted for deployment specific information), form/process designers design with components, and the run-time environment executes components. Packaging Components should be able to be packaged into a single Java Archive file (JAR) which can be deployed to any BPM solution instance. Meta-data Descriptor information -- such as name, description, transaction capabilities, version info used at design and runtime -- should be stored using XML within every packaged component. Hot Deployment Developers should be able to hot-deploy, activate, de-activate, and redeploy components. Page 4

Components are a cornerstone of Q-Link s architecture. Both the Q-PACs and XFCs are component frameworks for processes and interactions (forms) respectively. All components are treated natively within Q-Link, similar to those base components provided that implement the default functionality and behavior of Q-Link. A component represents an independent unit of production and deployment that is combined with other components to build integrated processes and forms in a model driven environment. The fundamental building block of a business process within Q-Link is an action representing a unit of work to be executed by the workflow engine. Some actions are totally automated, like fetching or posting data from a system, while others involve collaborative human interaction. Each of these actions is a Q-Link Process Action Component (Q-PAC SM ) that a business analyst uses at process design-time and the workflow engine executes at runtime. Every workflow component (such as route-to-skill, route-to-organization, send an email, execute a script, and invoke a Web Service) has been implemented as a Q-PAC. Custom Q-PACs can be developed to provide new functionality to meet specific business requirements. Q-PACs are not adapters like those typically found in an EAI stack. Instead, Q-PACs provide a comprehensive mechanism for extending Q-Link s workflow engine. In Q-Link, a form is used to represent the point for user interaction in a process. The user interaction may include filling out a text box, choosing an item from a drop-down list, or entering a large amount of text into an area, for example. The ability to create and deploy a form to allow for this interaction is made available through Q-Link s Process Application Designer (PAD SM ) design tool. In the PAD, the components that are used to allow for this user interaction are XFCs, or XForms Components. Q-Link supplies a set of base XFCs that can be used to build forms immediately, but custom XFCs can also be written and deployed to meet the specific needs of the organization. The evolution of XFCs in Q-Link result in a BPM solution that takes componentbased methodologies used in application development and applies them to form interactions, resulting in the first solution truly enabling business domain experts. #4 Object Model BPM solutions need to interact with extensive amounts of data relating to process instances, sub-flows (branch instances), steps (action instances) within a process, and the assignments (to user worklists) made to those steps. Unlike many BPM products, in Q-Link this data is stored in normalized relational structures making metric-related data available to any thirdparty reporting tool that can access SQL data-sources. Moreover, once deployed a process type s design is also normalized into relational structures and any new process instances will be associated to that set of design data, making it equally easy to associate runtime & design-time data for purposes of reporting. A core feature of Q-Link is an object-relational definition framework that provides a database abstraction layer for the Q-Link platform. As opposed to Object-Relational (OR) tools that Page 5

are used to provide platform-independent data access for Entity Beans, POF is built on top of a set of Stateless Session Beans and Entity Beans (to store data-dictionary). POF allows customers to extend Q-Link s underlying object model by creating new business objects and modifying existing business objects. A business object is a real world concept that has a separate and distinct existence and is of interest to the user for tracking state. POF implicitly maps these objects to the database, allowing developers to work at the object level. The meta-data describing a business object is stored in an object type. Similar to a process type, an object type is a template from which multiple object instances are created. The benefits of having an Object/Relational framework within a BPM solution include: Database Independence There are no code changes required for Q-Link (or clients of Q-Link) to run on an embedded Java database vs. Oracle, SQL Server, and/or DB2. Shared Data Model Data structures can be created that are shared across process types. Complex Data Requirements More complex data requirements can be handled through a structured mechanism. For example, one-to-many or many-to-many relationships. Upgrade Mechanism Upgrading may sometimes require data-structure changes. POF s export/synchronization capabilities make this an easy process if needed. #5 Converging BPM and App Dev Functionality At the end of the day, BPM is more than just an extension of workflow or Enterprise Application Integration (EAI). BPM is application development. More specifically, it is application development designed to enable asynchronous business processes with both human and/ or systemic interactions. Therefore, BPM solutions that do not inherently provide the necessary application development functionality will force companies to weave a multitude of disparate technologies together, diminishing their ROI and creating a fertile environment for inconsistent and inoperable applications. Consider the following quote from The Third Wave Howard Smith & Peter Fingar: Today s applications are stove-piped by function, by data and in time creating a source of constant frustration for business users who ask, Why can t I change this application and all the other things it touches? Almost every day, in every company, someone is challenging the conventional notion, That is just the way IT is. They are joining up, transforming and connecting different activities that were previously islands, stovepipes and silos. But although integration software is a huge help in integrating software applications, it adds another level of complexity, and doesn t solve the fundamental issue of change. Business people don t want to have to change and then re-deploy applications, no matter whether they or their IT department is responsible; they want applications themselves to be able to change. This shift from data-centric to process-centric methods and systems will become a major focus of winning companies over the next decade. IT systems will more accurately reflect the way business really is-constantly changing, messy and chaotic. Third wave Business Process Systems can be understood as the fastest Rapid Application Development (RAD) methodology ever available to business. There is no translation of the process model none, zero, zilch. The process model is the system the system is the business. Q-Link is leading the next major paradigm shift in the converging Business Process Management (BPM) and enterprise application development markets. With Q-Link s Process-Oriented Application Model (POAM SM ), users assemble comprehensive applications based on business and process constructs rather than code generated software constructs. Page 6

The Q-Link platform enables the seamless integration of user interactions and the orchestration of back-end services while leveraging the stability and scalability of the J2EE platform. By combining this new application model with a highly-integrated suite of BPM technology services such as component-based workflow, and component-based UI design, the Q-Link platform provides enterprises with a number of measurable benefits: Reduces development time and total cost of application ownership by 70% or more compared to traditional J2EE development. Reduces project failure rate by eliminating over 90% of the translation of business specifications into programming code. Leverages existing IT infrastructure (legacy systems, ERP, CRM, application servers, etc.) and provides the infrastructure to utilize emerging technologies such as Web Services. Significantly increases developer productivity, allowing IT departments to reduce project backlogs. Page 7