TIBCO BPM Now and Future: iProcess, Meet ActiveMatrix BPM

The session that I’ve been waiting all day for is with Roger King, who runs BPM product management and strategy for TIBCO, where he discussed the new ActiveMatrix BPM and TIBCOSilver BPM offerings for on-premise and cloud deployments. They’ve been working on this for a couple of years, and obviously keen to get it out of the gate. As I tweeted earlier after taking a look at ActiveMatrix BPM in the solutions showcase, this isn’t a complementary product to iProcess: it’s the successor to iProcess, in spite of what was said about this yesterday. Have no doubt: AMX BPM is not an upgrade to iProcess, it’s a new product, based on a new technical architecture, and already (at version 1) provides more functionality than iProcess.

With both AMX BPM and Silver BPM, Business Studio is used for modeling the process; ActiveMatrix versus Silver is just a deployment choice at the time of deployment, which means that you can deploy the exact process to an on-premise ActiveMatrix application server or to the cloud. In fact, if you’re modeling your iProcess processes now in Business Studio, rather than in the iProcess Modeler, you can deploy those directly to AMX or Silver, too. What’s changed from iProcess is that they’ve bundled much more into the BPM bundle: it’s a full composite application development and deployment plaform, including forms-based user interface, rules and SOA capabilities, so that all of the process-related artifacts can be modeled in a single environment. Their previous focus on support for process patterns is now extended to include resource, business and data patterns, too, and there’s more work management and workforce optimization functionality. Their tag line: “Business Friendly, Enterprise Strength”.

This model-driven development is based on five types of models: process (which we’re used to in BPM), form, data, organizational and client application. In order to do this, they reused some pieces that will be familiar for iProcess customers, but some new stuff too:

• BusinessStudio for modeling, extended for new functionality
• New OSGi-based deployment model, where an application package (process, rules, services, etc.) is deployed rather than just a process
• New container-based grid platform
• New runtime, which is an ActiveMatrix application
• Workspace, similar to that used by iProcess, but extended
• New Openspace gadget-based client, including interfaces for mobile devices

The architecture starts with the OSGi runtime with the ActiveMatrix service platform as the basic platform, with the ActiveMatrix BPM SCA composite application as the BPM platform running on that platform, including Process Manager, Openspace, Event Collector, Work Manager and Workspace components. Everything used by the AMX BPM components are visible to other applications, meaning that it can be easily embedded or integrated with other AMX BPM applications.

Both business analysts and process developers create executable process models with the other supporting models and forms user interfaces, while the SOA developer creates process-based services, all within the AMX BPM environment. Work is managed and executed by various level of workers, using organizational models that can be extracted from LDAP. Users may access work using Workspace (the same interface as is used for iProcess), Openspace (a mashup-type interface) or Mobilespace (the mobile version of Openspace, currently available for iPhone), or through a custom interface. Performance data is visible for different levels of monitors, again through standard dashboards or custom interfaces.

One of the interesting things that can be done is modeling of page flows: since AMX BPM allows for both user interface and process to be modeled, there are some parts of the flow that aren’t run in the process engine, but are executed in the web tier as a series of pages/views linked by rules and services, presented to the same user during a single session with the state information maintained during the flow; this provides smart capabilities to an otherwise simple forms user interface, without having to round-trip to the process engine for some basic decisioning and screen flows. It also allows for a more seamless interface in the modeler: a page flow model is shown almost as if it were an expanded subprocess from a task in the main process model, so that you can view the whole process – that which runs on the process engine as well as in the web tier – in a common environment. This reminds me somewhat of the screen flow capabilities that are starting to emerge as part of web application platforms such as Salesforce and NetSuite, although in the context of a larger process rather than in the context of a packaged application.

I also like data modeling capabilities in their business object models: you can interrogate an existing database directly in order to derive the data model for your process instance data, which saves a lot of redefinition (and the errors that can be introduced) of the data model as part of the process model. You can also import the data model from UML and other formats. Eventually, this needs to be able to integrate with enterprise MDM initiatives, but this is a good start.

The forms-based UI designer has some nice features as well, being able to automatically generate master-detail forms with grids for detail records based on joins in the data model. Although it’s not a really complex forms designer, it does allow styling with a style sheet, and I expect to see some improvements here as they figure out what their customers really want. They can separate presentation from page flow, and some companies may decide to use the AMX BPM page flow but do their own presentation screens.

They’ve moved away from the concept of queues that supported iProcess to dynamic work lists that are generated on the fly; this makes sense given the advances in dynamic data access. In general, creating a new BPM product from the ground up today not only makes their 20-year-old iProcess architecture look dated, but also the 10-year-old generation of products from other vendors that started the current BPM revolution in the early 2000’s.

Tons of interesting stuff here, more than I can absorb on the fly for a live blogging post, but I’ll nail down a full briefing in the next couple of weeks.

AMX BPM shares common components with the AMX SOA product line, but does not include AMX Service Grid (which includes more containers) or AMX Service Bus – if you’re a TIBCO customer (or planning to become one), these are details that you’ll want to work out in terms of licensing to make sure that you have all the right pieces, and aren’t paying for things that you’re not using. If you’re an iProcess customer, then don’t look for AMX BPM as part of your upgrade maintenance: it’s not an upgrade, it’s a new product. iProcess is not being end-of-lifed; it will be maintained and have minor enhancements for some time to come, but I don’t get the idea that you’re going to see a lot happening here since King stated that the major BPM investment for them will be in AMX BPM. If you have one of the other BPM products, such as InConcert, you may want to start saying your prayers now (although there has been no EOL notice as yet). In any case, at some point you’re going to want to consider a migration path off these older platforms for processes that you want to continuously improve, since they are not going to see any significant upgrades in the future, even though the official line is that iProcess “is not going away for a long, long time”.

The current plan is to provide for coexistence of iProcess and AMX BPM in Workspace so that users can pull work from either system without having to worry about which one it is on. And, although you could take an iProcess model in Business Studio and deploy it in AMX BPM, you’d probably want to take advantage of much more of the new functionality, such as the forms-based user interface designer, which means essentially rewriting everything except the process model. Although there is some service composition capability in AMX BPM, you’re probably going to leave most of the service composition heavy lifting in BusinessWorks, since AMX BPM really is geared towards turning processes into services, not general composition.

Interestingly, when I saw a quick demo at the booth earlier today, I detected essence of BPEL in the process model (such as catch and throw events); King confirmed that at the composition level, this is heavily extended BPEL.

Essentially, AMX BPM provides BPM on an SOA platform, but without the BPM designers having to worry about the SOA parts. From that standpoint, the BPM functionality competes well with the pure play BPM suites, but it provides a great deal more flexibility in dealing with services than you’ll see from the pure plays. They see their competition as the other stack vendors, IBM and Oracle, but with the lack of innovation and cohesion in both of those vendors’ BPM offerings, TIBCO seems to come out ahead in BPM functionality. Seems like the best of both worlds.