TIBCO ActiveMatrix BPM In Depth

Back in May at TIBCO’s TUCON conference, I had a chance for a briefing on their new ActiveMatrix BPM, although not a full demo. Since then, however, I’ve had about three hours of demo sessions with Roger King to see more of what they’re doing with ActiveMatrix (which I will refer to as AMX) BPM and Silver BPM, the cloud version. King has been at the core of TIBCO’s BPM products for a long time: he was at Staffware long before their acquisition by TIBCO, and now heads up BPM product strategy and product management, so is in a position to not only give a thorough demo, but to provide context for where they’ve come from and where they’re going in BPM. He also does a mean Austin Powers imitation, which is kind of funny when you consider that he’s a Brit imitating a Canadian who is imitating a Brit, all for the amusement of a Canadian. 🙂

AMX BPM Architecture

The AMX BPM platform has five components – Workspace, Work Manager, Event Collector, Process Manager, and Openspace – wired together using public services, which allows anyone to use those same services to replace or augment the components. In fact, the BPM platform and AMX BPM applications are all just AMX composite applications.

There is a common administration interface for all AMX products, and when we’re in the AMX Admin interface, the common nature of the platform becomes more evident: you can see the AMX platform, AMX BPM, sample applications and organizational models that we’ll be looking at in the demo. Selecting the AMX BPM application, you’ll see the underlying five components as well as all public services available.

The AMX service governance and management tools share common components with AMX SOA, but are not included in AMX BPM.

What this new architecture means is that Business Studio can be used to create services using combinations of components, services and other object types, which allows processes to be embedded as part of any application: process is not a separate thing used to orchestrate applications, but part of the application itself.

Organizational Models

Business Studio, as the design/modeling environment for composite model-driven process applications, now supports five model types: process, page flow, organizational, data and form. Organizational models are considered a key starting point: an organizational model becomes a functional overlay on your corporate LDAP, and can include multiple organizations such as trading partners in order to define organizational scope during runtime. Metadata is defined on a per-organization level, which can be used to partition visible information if people from multiple organizations participate in a process at runtime.

Organizational models allow you to define Positions, which represent roles that can be used for work assignment in a process, e.g., all CSRs or all Life CSRs in the insurance claims scenario that’s provided as their sample organizational model. A position can include capabilities such as language skills, and privileges such as ability to authorize claims, scoped to an organization and assigned at an instance level to a process model. You can also define groups, e.g., Managers, and assign capabilities and privileges with groups, as well as access to system actions. Resources in the organization model can be mapped to LDAP attributes at runtime using queries. Later, during process modeling, positions are used to assign participants to a step in a process model, and to perform capability-based routing.

On the end-user side, the model appears in the Organization Browser within the ActiveMatrix Workspace if the user has permissions to see this: an admin, for example, might be able to see all of the organization models for multiple organizations, see the participants that are part of any position, and view or create the queries that bind the resources from the underlying LDAP. A regular user may see only their own organization’s structure, without the ability to modify the participants in a position or any other resources.

Business Object (Data) Models

TIBCO isn’t the first BPM vendor to jump on the process data model bandwagon, and they won’t be the last: the link between MDM and process instance data needs to be firmly established so that you don’t end up with data definitions within your BPMS that don’t match up with the other data sources in your organization.

In Business Studio, you can define a business object model – a sort of simplified UML data model – that allows structured data models to be shared within or across packages and applications The business object model can have subclasses as well as data relationships, and supports a hierarchy of data models. Even better, you can import it from UML, XSD, WSDL or directly from a database, and can export it to XSD or WSDL.

A business object model is then attached via an external reference to a process model to become part of the process instance data. Access control (in/out/bidirectional) can be set for that business object at each step in the process, as with any other instance parameter, in order to control whether the process step can read and write to the instance data defined by the business object. If you create scripts (which are Javascript in AMX BPM) to manipulate the instance data, the script editor will look up attributes and type directly from the business object model, which means that it’s fully-accessible instance data, not a blob that you need to decode manually.

Page Flow Models

One optimization that BPM vendors are starting to learn from application development environment products is the idea of screen flow: a stateless mini process model that runs in the web tier to handle a series of screens/pages for a single user in a monolithic operation. Think of it as the underpinnings for a wizard-type interface, where the user is stepped through multiple pages of information and data entry in order to complete a single task in a process. This is similar to the capabilities emerging in web application platforms such as NetSuite’s SuiteFlow, Salesforce’s Visual Process Manager and the process modeling within OutSystems, except in this case, the page flow is what happens at a single step in a larger process model. It contains a lot of the functionality of a process model, including gateways, conditional logic, data access, service calls, etc., but when the page flow completes, it returns to process engine to be sent on to the next step in the orchestration.

Page flows are another important efficiency improvement in BPM systems architecture; otherwise, you end up doing a lot of dequeuing and enqueuing of work items to and from the process engine, which has a lot of overhead. Some systems have had ways to kludge this for many years by binding together several sequential steps in the process model, such that the work item was dequeued at the beginning of the first step in the group, then not enqueued again until the end of the last step. In the case of TIBCO AMX BPM, the page flow looks almost like a subprocess call, with the monolithic step shown in the process map, then the steps in the page flow shown in a limited version of what looks like the process modeler. The alternative to using something like a page flow in any BPM environment is to build that capability into the user interface for that process step, which tends to make the UI very complex, and embeds far too much of the business logic (including routing logic) into the UI rather than in the process and data flow models.

An interesting use case that we discussed was to create a page flow for the start node of a process and expose that as a business service: since the start node page flow can include steps, forms and data access/validation before instantiating the (stateful) process, it provides an environment for initial data gathering at the start of a process without having to use some other web form to gather the data necessary to kick off a process instance. This can then be published as a business service to call from other appslications and environments, wherever you want the process to be invoked.

User Interface Form Models

User interface forms can be assigned to each step in a process model, and will be auto-generated for the specific task based on the process instance data, which could be a business object model. The default form that is generated – and will be rendered in General Interface to preview the user interface at that step – isn’t that pretty, but it’s fairly straightforward to then pretty it up in the forms editor, adding master-detail structures and different control types, and associating objects with CSS classes for styling.

Although you may not end up using these auto-generated forms without some amount of customization, they remain invaluable for rapid prototyping of processes.

It’s also possible (although only feasible in simple cases) to specify no form URL attached to a process or page flow step, which will generate a form at runtime based on the process instance data exposed at that step.

Process Patterns in Process Models

We didn’t spend much time on the Business Studio process modeler, since there is a lot of common functionality with most other process modelers (although Roger will cringe to hear me say that), but just focused on a few new features.

One of these features is a set of predefined process patterns, similar in functionality to what you might do with business rules, but more visually associated with the process model. We looked at two of these: chaining, where subsequent human tasks for same item are worked by same person if they are capable, but can be assigned to others if the first participant can’t perform all of the tasks; and separation of duties, where subsequent tasks (e.g., work and QA) must be done by different people.

At the time that I saw the demo, chained events were visualized as embedded subprocesses, and patterns couldn’t be combined; these need to be fixed in order to make the patterns more visually accurate as well as more functional.

ActiveMatrix Workspace

The ActiveMatrix Workspace is the web-based end-user environment, with views of the work available to the current user as well as views of the organizational model as discussed above. Taking a look at the work views, however, is where we see some of the first major changes to the underlying process engine: there are no more physical queues; rather, what appear as logical queues (or work lists) to users are created with dynamic queries. In the old days – and in the old architecture of iProcess and some of its competitors – segregating work items into explicit queues was necessary for performance reasons; today, faster hardware and in-memory software allows this to be done dynamically. When I think of all the times that I’ve have to work around queuing mechanisms in BPM systems, both for work assignment and reporting purposes, this is huge since it provides much easier slicing and dicing of the work items. For example, a standard work view for a supervisor would be “Supervised Work”, which shows all work items that are both available but not yet assigned to a user, plus those that have been allocated to specific users: in effect, a view of the unassigned and assigned work in progress, regardless of its logical queue location. Now, you could argue that queues in most BPMS are usually implemented as database constructs anyway, which is mostly true; however, access to work except by queue is often not very efficient in these queue-oriented systems.

In addition to the Work Views and Organization Browser, the Workspace includes the following user views:

• Business Services, which is a user view of process-based composite applications, so that user doesn’t think about kicking off a process, but about doing a business function. In the sample insurance scenario that we were looking at, this included functions such as “First Notice of Loss Notification”.
• Process Views, which shows a view of the executing processes.
• Event Views, which shows an administrator-like view of login/logout and other system events, plus events related to process instances such as access and update. This is tied closely to the Process Views, which links back to the Event Views in order to show instance events.

We walked through the invocation of a business service in the Business Services view, which essentially kicked off a process instance. However, the first two steps of the “process” were actually screens in a page flow: the simple data entry screens were auto-generated, and the process wasn’t actually instantiated until after the Submit button was clicked on the second screen. We followed the process through the remainder of the steps, which showed off most of the capabilities that we had seen in Business Studio during design:

• Looking at the Work View, the new claims show up in an OFFERED state (meaning that they aren’t yet claimed for work by a participant) in all CSRs’ work lists. Each user’s view of the work list depends on their group membership, so it completely dynamic.
• Data is entered by the CSR for the work item to record the claim; the UI in this case was generated from the business object, including multi-entry field types such as multiple claimants for one claim.
• A language filter based on capability is used to assign work for the Customer Interview step; this step also used a 2-screen page flow to gather information while on the phone with the customer.
• The work item is processed through the Assess Claim step, and that work item is excluded from same user for the Pay Claim task using the Separation of Duties process pattern.

TIBCO Silver and Silver BPM

TIBCO’s big splash at the TUCON conference this year was around Silver, their cloud environment based on Amazon EC2, and specifically Silver BPM, their cloud-based BPM offering. This is not a cloud-based process discovery or modeling tool; this is the actual processes executing in the cloud.

Setting Silver BPM apart from some of the other cloud BPM environments is the shared design tool, Business Studio, that can connect simultaneously to both on-premise AMX environments and Silver environments. The same models, applications and other services built in Business Studio can be deployed to either environment without having to export and import them into another design tool. This immediately suggests an obvious use case of Silver for development and testing of process applications, even if they are going to be deployed on premise, since each member of the development and test teams could have their own virtual AMX servers, if desired. Although there is no guarantee of the ActiveMatrix and Silver BPM platforms providing exactly the same functionality at any point in time, I would guess that TIBCO will have to keep them fairly closely aligned in order to support this dev/test use case. IBM uses exactly this strategy for marketing their Smart Business Dev/Test environments (although not for any of their BPM products), and the potential cost reductions for these non-production environments is starting to resonate with enterprise clients, not just smaller businesses. That’s not to say that you can’t use Silver BPM for production environments, just that I am imagining that many larger enterprises won’t yet trust the cloud for core production capabilities.

Although EC2 is underneath Silver, the customer only needs to set up their Amazon EC2 account, enable the EC2, S3 and RDS services, and pay their Amazon bill at the end of the month: all other provisioning and administration is done through the Silver Center console. Silver customers are on a one-year or three-year subscription license with TIBCO (as usual, I forgot to ask about pricing) that is an additional cost above the Amazon services.

From within Silver Center, you can create a new Silver BPM instance using the following steps:

1. Name the instance, then select the product group (e.g., Silver BPM) and software version.
2. Enter the name and passwords for the database administrator, user and sample user accounts.
3. Specify the underlying EC2 properties: size/memory configuration, geographic zone, some security parameters and whether to use an elastic (fixed) IP address.

This will start a new EC2 instance that combines a basic Linux image with the selected Silver BPM software image, which takes about 20 minutes to provision and boot the virtual server.

Once up and running, the Silver Administrator and Silver Workspace look amazingly similar to their on-premise ActiveMatrix counterparts: if I didn’t look at the top banner or the URL, I would not have been able to distinguish them. Even from within Business Studio, once you set up the connection parameters, a Silver BPM server looks pretty much like an AMX server, and you can connect to multiple of each type from Business Studio. Then, you deploy models to any of the servers by dragging and dropping them onto the server.

There are some obvious holes in the current Silver BPM offerings. First, they have cloud-based execution but no cloud-based discovery or modeling: Business Studio is an Eclipse-based desktop application, with models stored in a local workspace and shared primarily through the use of a Subversion repository (more commonly used by developers for source code control). This is not process discovery/modeling for the masses, and doesn’t contain the collaborative features such as interactive sharing of process models that we see emerging in many other tools.

Second, there is no multi-tenancy, but only a 1:1 relationship between Silver BPM and EC2: an EC2 instance can contain only one Silver BPM instance, and a Silver BPM instance cannot span multiple EC2 instances. In the future, they will allow for 1:many and many:1, but for now, this is really more like dedicated cloud resources rather than multi-tenancy hosting.

Third, there is an LDAP server created within the Silver BPM instance, but you need to manually upload your enterprise LDAP and use appropriate tools in order to keep it in sync. You can, however, use your corporate LDAP if you use Amazon Virtual Private Cloud.

TIBCO’s not the first to provide process execution in the cloud – Appian, Fujitsu, Intalio, Cordys and others have come before them – but having a big BPM name like TIBCO enter the cloud BPM market helps to further validate the use of the cloud for process execution. In fact, I’ve had a discussion with one of the more established cloud BPM vendors since my briefing with TIBCO, and I advised them not to think of TIBCO only as a competitor, but as a collaborator helping to expand this market. I don’t imagine that we’ll see many Silver customers before next year’s TUCON, but TIBCO will be out there building the cloud mindshare.

openspace

We finished our marathon demo sessions with a look at AMX openspace, TIBCO’s gadget-based container application for building composite user interfaces. In short: a mashup builder.

The standard AMX/Silver Workspace is fine for some users, while others need a highly-customized UI created by developers for advanced functionality; there is, however, a third category that prefer to roll their own user experience. I first blogged about the potential for enterprise mashups in early 2006, and attended the first MashupCamp in 2006 (and the second one in 2007), so it’s no surprise that I’ve been impatiently tapping my foot waiting for many of the larger BPM/enterprise software vendors to catch up with this trend. True, the customers aren’t there yet, but they’re not going to get there on their own, they need to see mashup/portal builders in action to recognize the value that these tools can bring to experienced users and administrators.

The basics: openspace supports a number of different gadget standards, including Shindig, OpenSocial, iGoogle and GWT, and uses a publish-subscribe model for inter-gadget communication. Gadgets are arranged on tabs/pages within the openspace application, and can be added from the predefined palette of gadgets, from the gadget store hosted on the server, or by specifying the URL and any required parameters for external gadgets such as Google Maps. Each gadget can be themed independently, although that just seems like a recipe for a graphic design nightmare. Once created, openspace pages can be published for other users to use.

This ties back into AMX BPM with the availability of BPM gadgets: process participation gadgets such as Business Services and ToDo List, basic monitoring and reporting gadgets for end users and supervisors, and Spotfire gadgets for more advanced analytics and visualization. You have to be licensed for all the underlying software such as AMX BPM and Spotfire; this just provides a new way to visualize and interact with those tools.

Summary

If you read my previous post on AMX BPM, you already know that I was impressed with what I saw. There are a number of BPM products launched around the same time as Staffware’s product (which became TIBCO’s iProcess) in the early 2000’s, and although most of these need a complete architectural overhaul to bring them up to date, this is the first that I’ve seen of a vendor biting the bullet: AMX BPM is not an iProcess upgrade; it’s a completely new next-generation BPM product. Although they gain immensely in product capabilities, they are leaving behind their existing iProcess customers, although I’m sure that they’ll offer some sort of migration assistance. There are unlikely to be many enhancements to iProcess in the future, but there are no plans for end of life, and it is expected that many current customers will keep their legacy applications on iProcess while looking to AMX BPM for new applications and functionality.

With AMX and Silver, TIBCO have leapfrogged many of their newer competitors in terms of architecture and functionality. Their challenges lie in shifting their existing customers’ new development onto AMX or Silver, and convincing potential customers that they’re no longer part of the BPM old guard.