My ability to think on my feet was put to the test when the Webex server went down 15 minutes into the process discovery webinar that I was presenting for TIBCO. I was merrily clicking along through my slides as I talked, not realizing that no one could see what I was talking about; the slides were pretty sparse and there were only 6 of them with any real content, so not a great loss, but I might have worded things differently if I had know that I was flying blind.

The best part was the Q&A: since we had no text Q&A capabilities, we had to do live phone Q&A, where the operator queued people up and let them ask their questions live on the phone one at a time. I actually liked that since it made me think on my feet, but the down side was that we weren't able to triage the questions ahead of time to make sure that they were relevant to the webinar content and the audience. We only had one off-topic question (about TIBCO's product, which was not covered at all in my session), and the rest were spot on. The last one was on standards, and I went off into a bit of a soliloquy about BPMN, XPDL and BPEL that probably had the attendee regretting that he asked the question, but the feedback has been pretty good so far.

TIBCO is rushing the recorded version of the webinar to get it out this afternoon for you to listen (and watch) a replay and download the slide deck. There are two more webinars that I'm doing in this series, Process Modeling on July 11th and Process Design on August 8th; I'll be sure to offer up a suitable sacrifice to the Webex gods before then.

Posted by Sandy Kemsley at 01:51 PM in BPM | Permalink | Comments (2) | TrackBacks (0) | Add to del.icio.us

I'll be presenting on a webinar today at noon (Eastern) sponsored by TIBCO, the first in a series of three webinars covering process discovery, process modeling and process design. It's not too late to sign up if you want to join in.

From their description of today's webinar:

Join analyst and blogger Sandy Kemsley for an in-depth look at process discovery. Sandy will discuss drivers for process improvement and provide how-to information to addressing:

• Analyzing current processes and doing walkthroughs
• Identifying opportunities for process improvement and automation
• Moving from a functional viewpoint to a business process viewpoint
• Discovering "hidden" processes in emails and manual procedures
• Process prototyping

I spoke briefly at the TUCON conference earlier this year on a related subject, "Modeling for the Masses", and you can see my presentation from that conference below in SlideShare:

Posted by Sandy Kemsley at 07:07 AM in BPA • BPM | Permalink | TrackBacks (0) | Add to del.icio.us

Bluespring is hosting a webinar, The Characteristics of a Truly Agile BPMS Technology, on June 20th, featuring Colin Teubner of Forrester. It looks interesting, although I will have to miss it since I'll be at the Enterprise 2.0 conference.

I do think that it's hilarious that they send out a press release to announce a webinar, however: "Bluespring Software, the Business Process Management Suite (BPMS) software company that puts the power of business process design, execution and management in the hands of business people announces that the company will be hosting a webinar with Forrester Research on process agility."

Posted by Sandy Kemsley at 06:19 PM in BPM | Permalink | TrackBacks (0) | Add to del.icio.us

The acquisition of webMethods by Software AG that I wrote about in April has finally come to fruition, although the planned press/analyst web conference on Friday somehow managed to crash the hosting provider's servers so I didn't get all the gory details. From their press release, however, it appears that the webMethods brand will be retained, and Software AG's current Crossvision business will be renamed as webMethods.

Posted by Sandy Kemsley at 05:32 PM in BPM • SOA | Permalink | TrackBacks (0) | Add to del.icio.us

I thought that my heavy travel time was almost over for the summer, but it just refuses to go away. Due to a new client (yes, I do actually do work that I get paid for sometimes, in addition to all this unpaid blogging :) ), I'll be visiting Chicago and Montreal over the next two weeks before heading off to Boston for the Enterprise 2.0 conference.

Here's my public speaking and conference schedule for June:

• June 13th: I'm appearing in the first of a series of three webinars that I'm doing with TIBCO. The first of these is "Process Discovery", the second (July 11th) is "Process Modelling", and the third (August 8th) is "Process Design".
• June 14th: I'm appearing in a webinar for Savvion entitled "How to Ignite the BPM Spark: Practical Steps You Can Take Today". 
• June 18th-21st: I'll be attending the Enterprise 2.0 conference in Boston and covering it here in this blog, although I'm not presenting there.
• June 27th: I'm speaking at the IQPC BPM summit in Toronto on "Enabling BPM Through Technology".

Interestingly, both TIBCO and Savvion recognize that their customers are interesting in the up-front part of BPM: in the case of Savvion, how to get started on a BPM project, and with TIBCO, how to take a process from discovery through modelling and design. The material will be quite different between the webinars and I'll blog a bit about each of them separately later this week; I encourage you to listen in on all of them.

Posted by Sandy Kemsley at 03:30 PM in BPM • Enterprise2.0 | Permalink | TrackBacks (0) | Add to del.icio.us

There's a webinar going on right now (12 Eastern) on ebizQ about which comes first, BPM or SOA, featuring Colin Teubner of Forrester. I like his agenda point: "Why SOA needs BPM (and not vice versa)".

Posted by Sandy Kemsley at 12:06 PM in BPM • SOA | Permalink | TrackBacks (0) | Add to del.icio.us

Brandon Dean of BEA talked about how to use BPM for compliance and improved visibility into processes. I wrote a course on compliance and BPM recently, and I was interested in how they're seeing this roll out amongst their customer base.

Regulatory compliance (e.g., SOX) and any sort of commercial compliance (e.g., SLAs) or organizational compliance (e.g., internal KPIs) have many of the same requirements: processes need to behave in a consistent fashion, and any exceptions have to be handled using a standard method. Measurements on how well that the process is meeting its stated compliance goals are critical to understand whether or not the underlying business process is compliant. This, of course, plays directly to the strengths of BPM: providing a platform for standardizing and, where possible, automating processes; integration of multiple systems; consistent exception handling; security on the process steps and a comprehensive audit trail on who did what, and when; and monitoring and reporting for visibility into the processes and proactive alerts when they start to wander out of compliance.

Dean covered on how to position BPM for compliance, starting with a great categorization of organizational types ranging from companies that already have compliant processes but just need a better audit trail, to those that are actively trying to find ways around compliance. He made a point that I also discussed in my compliance course: if you implement compliance on a regulation-by-regulation basis, it's a lot more expensive and time-consuming. In fact, I used a quote from a Gartner report from 2004, in the middle of the SOX gold rush:

Enterprises that choose one-off solutions for each regulatory challenge that they face will spend 10 times more on compliance projects than their counterparts that take a proactive approach.

 He went through a number of case studies and how their compliance was facilitated by BPM:

• Dental insurance claims processing, which started out as a completely manual process that had no audit trail and didn't enforce standard rates and practices. Using BPM, they not only had some processes decrease cycle time from 3 days to 8 minutes, but they were able to meet HIPAA compliance requirements.
• Trade processing, where the SLA was not being met and they were risking losing the ability to execute trades. BPM allowed them to set alerts on trades that arrived but didn't complete for some reason, so that any manual intervention required could be performed in time to meet their SLA. This also allowed them to do follow-the-sun processing for more intelligent human resource allocation.
• Residential mortgage processing, which wasn't able to track requests for special handling in loan origination, and was causing them to lose customers. Using BPM, documents were automatically rendezvoused with waiting processes, and the processes presented for work at the point when they were ready to be processed rather than having people track the missing documents manually. This also automated feedback to the brokers to submit the necessary documents to reduce the wait time. A major gain was in making sure that all the information was gathered in a timely manner, and not presented for processing until all the information was available.

Although I think that Dean's definition of compliance is a bit stretched to include both customer SLAs and internal KPIs, his points are valid for developing many types of business cases for BPM.

Posted by Sandy Kemsley at 10:57 AM in BEAparticipate • BPM | Permalink | TrackBacks (0) | Add to del.icio.us

First session of the last morning, Eduardo Chiocconi of BEA and Rob Wald of JPMorgan Chase talked about the ALBPM UI: what comes out of the box, and what you can build yourself.

Out of the box, ALBPM has three user interfaces alternatives:

• HiPer WorkSpace, a full user workspace with menus based on their permissions, a view of their inbox, and views of any instances that the user opens. It uses CSS if you want to change styles, and can be customized further in terms of removing buttons and other controls.
• JSR-168 portlets for any standard portal environment, such as WebLogic.
• WorkSpace Extensions WorkList Portlets that can be plugged into ALI and provide additional integration functionality over the standard portal interface, such as integration with the ALI Collaboration environment.

They're working on consolidating these interfaces in order to reduce the user learning curve.

If those don't work for you, then you can create your own user interface, either browser-based or rich client, using the available APIs. For building web clients, many of their customers have used JSP to re-code the entire user interface, then used servlets to access the engine. Alternatively, you can use Struts or JSF/AJAX. All of these can use their Java-based process API, PAPI, or the web services version, PAPI-WS, to retrieve instances from the engine, or WAPI (a servlet-based API) to execute interactive activities such as screen flows.

For rich clients, they're seeing a lot of .Net development that uses PAPI-WS to retrieve instances, then create the UI. It's also possible to use Eclipse or Swing to build rich user interfaces that call PAPI directly. This is more complex for interactive activities, but there are ways to work around that.

To sum up, there are three public APIs:

• PAPI (process API), which is a Java implementation. If you're working in a Java environment, this provides the tightest integration and best functionality. It manages multiple process engines transparently, and does instance caching on the client side to reduce latency in connecting to the engine -- a critical performance factor.
• PAPI-WS is a subset of PAPI that operates as web services (SOAP), although this is being extended in the near future to provide the full functionality of PAPI. There may be a .Net version of PAPI in the future, but for now you have to use PAPI-WS if you're developing in .Net (e.g., ASP.Net), and can also be used from any web service client. Right now, PAPI-WS is part of the HiPer WorkSpace, but will be decoupled as a self-contained web application in the future. It's also possible to expose processes directly as web services, as we heard in an earlier session, which provides another point of integration from a web service or .Net development environment.
• WAPI, which is a servlet API that can be used to launch the UI of an interactive activity at a point in the process, which can't be done in PAPI or PAPI-WS.

With any custom UI, there's always the question of single sign-on. With the WorkSpace Extensions WorkList Portlets in ALI, that's handled natively; in the HiPer WorkSpace and JSR-168 portlet implementations it requires some customization, although there is a single sign-on login servlet provided with the JSR-168 portlets to make this easier.

Getting to the specific JPMorgan case study, they created a custom user interface since, like many large companies, they want integration with other applications in their environment and want more control over the look and feel of the interface. It's possible to just create custom JSPs and use them in the standard work portal framework, which provides a great deal of control over the UI without completely rewriting it, but this wasn't sufficient for many of their applications. What they ended up doing was creating a completely custom inbox using Struts/JSP/GWT with PAPI: one example that he showed was using Struts and AJAX via the Google Web Toolkit to manage financial reconciliation processes. They're also using IceFaces, an open source RenderKit implementation of JSF (as a replacement for Struts) that supports AJAX to create a visual drag-and-drop components for use in an IDE such as Eclipse. Since JPMorgan is dedicated to the use of open source, they're doing some innovative development that's not seen in most corporate environments, but maybe should be. They're also using the JSR-168 portlets in a more standard portal implementation, and building rich clients with Eclipse.

On the back end of their implementation, they've found that some of the PAPI protocols don't work well over wide-area networks, such as between their US and Japan operations, so they do quite a bit of preloading of the PAPI cache.

JPMorgan has implemented ALBPM as a centralized shared service in order to provide efficient use of both human and server resources: centralized code and best practices on the human side, and a single ALBPM server handling 10 applications without difficulty.

Posted by Sandy Kemsley at 10:56 AM in BEAparticipate • BPM • SoftwareDesign | Permalink | TrackBacks (0) | Add to del.icio.us

Jesper Joergensen gave us BEA's view of how BPM is changing business and the future of BPM. Actually, he starts out with Gartner's view of expected market growth (hockey, anyone?) and how BPM is becoming more and more a part of organizations' productivity improvement initiatives as it moves from opportunistic to pervasive adoption.

There's a number of obstacles to BPM adoption, however, many of them cultural:

1. The ivory tower of process expertise, where a few process experts are doing the modelling. Easy-to-use modelling tools like ALBPM are helping to change that, but my opinion is that we need to have more pervasive technology to enable the shift, and that's going to be web-based, like Appian's process designer or Lombardi's Blueprint process discovery tool.
2. The ROI barrier: many current opportunistic BPM projects are low-hanging fruit in terms of ROI, but projects need to deliver faster and cheaper in order to implement processes with a lesser potential return.
3. Getting beyond just system-to-system orchestration and adding human-facing steps to the process. Stop thinking of those processes as "human-interrupted" and accept people as necessary actors in BPM-automated processes.
4. Managing complexity and scale.

Jesper went on to discuss a number of areas where practices and technologies need to evolve (note that this is not a statement of where ALBPM is going, just how he thinks that the BPM market needs to change):

• Web-based process modelling (which I obviously agree with).
• improved standards and interoperability, especially between a vendor's own tools if they have multiple tools for discovery, modelling and design.
• Automated process discovery based on monitoring (which I saw recently in a vendor demonstration but can't at this moment recall which one), where historical trends in manual decision-making are used to suggest automation of certain decision points.
• Better integration of BPM and BI, since many products currently have very separate BPM and analytics environments that don't integrate well.
• Standardization and service-enablement of process data; I think that BPRI may help with some of the standardization, but it likely needs to be taken further in terms of how process instance data and be extracted from a process engine via RSS feeds or other integration mechanisms.
• Process decision support, e.g., making suggestions based on historical decisions, and potentially raising exceptions if the current decision doesn't match the past trend.
• More open process flows to allow for dynamic changes to the process flow at runtime, even if they weren't anticipated at design time.
• Social computing functionality, such as tagging.
• Better integration with SOA and ESB.
• Enterprise-scale process execution and management to allow for end-to-end cross-departmental processes rather than the more common departmental BPM implementations that we see today.

We're in agreement on a lot of things on this list, and I'm looking forward to how some of these ideas might creep into the product in the future.

Posted by Sandy Kemsley at 02:21 PM in BEAparticipate • BPM | Permalink | TrackBacks (0) | Add to del.icio.us

Last session of the morning was Mateo Almenta Recca of BEA and Kunal Shah of Citigroup talking about advanced process modelling -- specifically process exceptions -- in ALBPM. Exceptions can be either system exceptions, such as a service being unavailable, or business (user-defined) exceptions, such as an account being closed. System exceptions are typically handled through automated retries and/or transaction rollbacks, whereas business exceptions are modelled into the process by the process designer.

Exception handlers can be built into the process at either the individual activity, group (similar to a BPMN transaction) or process level. Exception handlers at an activity appear just as an alternative path out of that activity, although an exception is typically invoked by a timeout or other non-decision activity instead of an explicit decision at that point. Exception handlers at the group level are shown connected to the group wrapper boundary, as in BPMN transaction exceptions, and process exception handlers are visualized as disconnected from the process but on the same model.

All exception handlers can take one of three basic actions: abort the process and go to the end of the process, go back and retry the step that threw the exception, or skip the step that threw the exception and move on to the next step in the process. The back and skip functionality is always at the activity level: an exception at the group level that causes a "back" instruction from the exception handler would return to the specific activity to be retried, not the entire group; "skip" would skip the activity but continue on to any later activities in the same group. This was counter-intuitive for me and I asked specifically about that: I would have expected that a group would be treated more like a BPMN transaction wrapper, such that a retry or skip would apply to the entire group, not the specific activity. Exception handlers can be automatic or manual steps: an automatic exception handler might perform some related transaction rollback in another system before aborting a process, for example, whereas a manual exception handler might allow for data repair before retrying the failed step.

They then talked about compensation flows, which seems to match the BPMN meaning of a compensation, in that it reverses a completed activity or group of activities. This isn't so easy as just rolling back any changed data values in the process instance, since there may have been external systems updated that now need to be rolled back to an earlier state, or non-transactional activities such as sending an email. Compensation flows are used when you can't use automatic rollback because an activity executed successfully, but can also be called by exception handlers. Visually, these appear very similar on the process model to exception handlers, in that they can be attached at the activity, group or process level. Since groups can be nested in a process model, the compensation flow for a group will invoke the compensation flows for any groups nested within it as it rolls back the entire flow of the group.

They finished up with a short Citigroup case study on how they handle trade exceptions in their back-office processes. Although most financial trades are handled straight through with no manual intervention, they handle 2000 trade exceptions each day. From designing a number of similar transactional BPM implementations, I know that there's huge financial risk if you don't handle your exceptions in a timely manner: market fluctuations that occur after the trade is accepted and priced but before it's completed are purely the risk of the financial institution, not the customer, so it's key to get the exceptions resolved as quickly as possible. Citigroup has implemented this as process-level exception handlers that log the exceptions and pass them on for manual review. In most cases, the exception handling process is just a matter of some manual data repair and the trade is resubmitted to the automated process, although some trades are cancelled from within the exception handler.

Posted by Sandy Kemsley at 12:07 PM in BEAparticipate • BPA • BPM | Permalink | TrackBacks (0) | Add to del.icio.us

I started my day in a session about what's coming up in future versions of ALBPM; unfortunately, most of the information hasn't been publicly released, so you'll have to wait to read about it at a later date. BEA will be holding BPM steering group meetings in July, so if you're an ALBPM customer and want to get involved in defining future versions of the product, this is your chance. I'd love to sit in on these, although I can't imagine the size of the NDA that I'd have to sign first.

I'm back listening to Mariano Benitez with an architectural overview of ALBPM for administrators and operators; I think that he's nervous now based on his reaction to my post yesterday. :)

We're going to cover the components of the ALBPM solutions, the enterprise infrastructure, and the deployment alternatives. I'll leave out a lot of the technical details since it would only be of interest if you were actually digging into ALBPM at this level in order to plan a deployment, in which case you're probably in the room with me right now.

In short, an ALBPM project can be made up of many processes, where a process consists of the process flow, points of integration and the presentation layer. Also associated with a process are the roles used by the process (which map to enterprise security), service endpoints, and deployment methods. ALBPM allows you to define the organization as it pertains to the business processes: participants and groups, organizational units, and roles.

Taking a look at the ALBPM enterprise infrastructure, it's (not surprising) three layers:

• There's a number of data sources, including a directory repository (which maintains configuration information about the deployment as well as organizational models used both in process definition and for authentication), the engine back-end database for all information on work in progress, historical instance data archived from the work-in-progress database, a real-time BAM data store with one day's worth of data aggregated for dashboard views, and an OLAP data store for more complete historical analytics. Either Oracle, MS SQL Server or DB2 can be used for the data sources, and although multiple execution engines don't require a separate database for each, they do require at least a separate schema. For performance, however, I would assume that you'd tend to split any production engine data stores and the analytics data stores onto separate database servers for performance reasons.
• In the middle layer is the main process execution engine -- the heart of the system -- plus a few other services such as data warehousing to load the analytics data stores. There are a number of basic services provided by the engine that are used to execute running process instances; no big surprises here on an architectural level if you've seen the process engine of other BPM vendors, although every engine has its specific advantages.
• Layered above the engine are various web applications, such as the main Workspace UI application that can be used both for processing and monitoring work. Listening to highly-technical engineers talk about user functions is always pretty funny: Benitez refers to the action of processing work as "invoking instance operations", so you can be sure that he's not going to be writing any user documentation. To be fair, I used to talk like that when I wrote code, too.

We unfortunately had to rush through the deployment scenarios, but saw that it's possible to deploy ALBPM either as a standalone BPM box or in a J2EE container (simple or clustered).

Posted by Sandy Kemsley at 11:27 AM in BEAparticipate • BPM | Permalink | TrackBacks (0) | Add to del.icio.us

One hour left, and 25% of my battery life. It's a race to the finish.

Craig Cochrane from BEA's professional services and Becky Lewis of SAIC finished off the first day with a session on the specific nature of BPM system roll-outs.

Cochrane pointed out some of the critical groundwork to cover in any BPM project: establish goals and key performance indicators, develop strategies for maximizing user adoption, select BPM projects, and prepare and train resources.

He covered several strategies for designing BPM systems, ranging from low-complexity, near out-of-the-box with direct user access to a standard inbox and a minimal amount of integration with other systems; through to fully-orchestrated situations where BPM controls the entire process, requiring significant integration. These often represent different stages in the same BPM project rather than endpoints in different projects: you can think of the low-complexity systems as early versions of what will eventually be a fully-orchestrated system.

Cochrane advocates an iterative development approach: not as extreme as Agile, but breaking the development into much smaller building blocks that can be rolled out incrementally, with user feedback adjusting the requirements along the way. It's more of a mini-waterfall approach, although that's obviously a taboo word, involving requirements, design, implementation, testing and project management at each stage. As he goes on to discuss change management, it's clear that there's still a lot of the old-style development mindset of use cases and screen mockups at the front end -- in reality, we don't mockup screens any more, we use rapid prototyping tools to create a working prototype, or else we risk delaying development to an unacceptable degree.

Lewis then talked to us about enterprise BPM at SAIC: they have multiple systems that embody parts of business processes (some redundantly due to decentralized IT), but no enterprise-level tool to tie all of them together or enforce consistent roles. They found that the sweet spot for BPM within their organization was processes that are complex, span functional boundaries, and have multiple system interfaces. They did think big and start small: they started on security and other framework components as would be required by future BPM applications, but started with a couple of smaller, low-risk projects. At the same time, they scoped out the high-priority (and higher risk) projects to take on once some of the internal resources were trained, and they'd had a chance to learn about BPM on the starter projects. Their first applications were training request forms plus some of the BPM framework components, and A/P invoice exception handling (now under development).

A big part of their framework vision is around the integration of ALBPM into their existing enterprise portal (built with BEA WebLogic, not ALUI), complete with single sign-on and a common look and feel, and with other technologies such as their Documentum document management system. This required the right balance: they didn't want to customize so much that they couldn't easily implement new versions of the core ALBPM product, but they wanted to have a consistency at the presentation layer. They removed some of the standard functionality (like creating custom views) in order to make it easier to support internally.

They also focussed on integrating their centralized Active Directory with ALBPM so that there wasn't a duplication of effort in maintaining users, groups and roles. Interestingly enough, they created an automated ALBPM process to synchronize Active Directory into the ALBPM users and groups.

A key part of their strategy was to create a BPM knowledge repository, which they did using a wiki to capture key findings, evolving standards and best practices. Although they use a template to provide some level of consistency, they found that a wiki provides much more flexibility for knowledge capture than standard document repositories.

She had some useful summary points, like the one about planning for the first project to take more time than you expect, especially if you're trying to build part of the big-picture framework at the same time. Still, they completed their first project in three months, which is acceptably fast.

Tonight, we're all off to the ESPN Zone for dinner and entertainment, although I'm still trying to figure out exactly what the ESPN Zone is. I realize that sports-themed extracurricular events is the price that I pay for going to the type of conferences where there's no lineup in the women's restrooms.

Posted by Sandy Kemsley at 06:01 PM in BEAparticipate • BPM | Permalink | TrackBacks (0) | Add to del.icio.us

I'm jumping around between tracks (and hence rooms): I started the afternoon in the ALUI Experience track, then on to the ALBPM Technical/Developer track, and now I'm in the ALBPM Experience track for a discussion of best practices for managing BPM projects with Dan Atwood of BEA (another former Fuego employee) and Karl Djernal of Citigroup. It's a bit difficult to pick and choose sessions when you're interested in multiple tracks: this session and the one after it in the same track are both around best practices, although appear to cover different aspects of BPM implementations and I'd like to sit through both. This one is categorized as "beginner" and the next as "intermediate", so I'm hoping that someone's actually checked to ensure that there's not too much overlap between them. I'd also like to see the next technical track on how BPM and ESB work together, but think that I can probably get a briefing on that directly from BEA as required.

Atwood started the session with seven key practices for BPM success:

1. Fundamentals of process-based competition: understanding the competitive advantage of being a process-oriented company, and the business case for BPM.
2. BPM and its value to the corporation: understanding what BPM is and how it differs from other management and technology approaches.
3. From functional management to process-oriented thinking: how the shift from functional management must permeate through the ranks of middle management in order to disperse the fiefdoms within an organization.
4. Getting hands-on BPM experience, with the help of mentors.
5. Foundations for process practitioners: BPM as the capability for implementing and extending other management practices such as Six Sigma.
6. Business process modelling and methods: learn about process-oriented architectures and development methods, and how they differ from traditional approaches.
7. Human interactions and their roles within BPM: while system-to-system automation is often a BPM focus, the human-facing parts of the process are critical. In other words, you can't think of these as being "human-interrupted" processes, as a customer of mine did long ago.

Obviously a big fan of BPM books, Atwood references Peter Fingar, Howard Smith, Andrew Spanyi, John Jeston, Mike Jacka, Paulette Kellerin and Keith Harrison-Broninski, as well as a raft of BPM-related sites (although not, unfortunately, www.column2.com). Also a fan of lists, he finishes up with his top five success factors:

• Executive sponsorship
• Correct scoping
• Start with the end in mind
• Framework
• Engage stakeholders

Hmmm, that seems to make 12 best practices in total...

Djernal then discussed the Agile methodology that they used for BPM implementation at Citigroup, starting with a description of Agile and Scrum as the anti-waterfall approach: providing incremental deliveries based on changing, just-in-time requirements, and involving the end users closely during the development cycle to provide feedback on each iteration. Just as important as delivery mechanisms is the Agile team structure: the team's not managed in the traditional sense, but works closely with the customer/end-user to create what they want. There's a 15-minute team meeting every day, and a delivery (sprint) every 30 days. Many teams vary the sprint length slightly while sticking to the Agile methodology, although there's danger in increasing it too much or you slip back to months-long delivery cycles. Initiated by the original prioritized set of product features, the user feedback on each iteration can impact both the features and the priorities. There's basically three roles in Agile: a product owner who represents the stakeholders, the team that implement everything, and the ScrumMaster who provides mentoring on the Agile process and helps to sort out external roadblocks.

The interesting thing is how they brought together BPM and Agile, since I'm convinced that these are two things that belong together. Process diagrams fill in a lot of the documentation gap and are a naturally agile form of creating a functional specification; they form a good basis for communication between the business and IT. Changes in requirements that cause changes to the business process can be done easily in a graphical process modelling environment. In fact, in many BPM environments, the processes can be prototyped and an initial executable version developed in a matter of days without writing any code, which in turn helps to set priorities on the functions that do require coding, such as developing web services wrappers around legacy systems.

They've learned some things from their experiences so far:

• Get training on using the BPM products, and on BPM in general.
• Use some external resources (like me) to help you get started.
• Since BPM involves integration, setting up the development, testing and production environments can be time-consuming and require specialized resources.
• Spend some time up front putting together a good test environment, including automated testing tools.
• Create a centre of excellence for BPM.
• Start something small for your first BPM project.

There's a lot of arguments about how Agile can't really handle large-scale development projects, but it's my belief that most BPM projects lend themselves well to Agile. The worst disasters that I've seen in BPM implementation have been the product of the most non-Agile development processes imaginable, with months of requirements writing followed by many more months of development, all of which resulted in something that didn't match the users' requirements and was much too costly to change. As I've said many times before, if you can't get something up and running in BPM in a matter of a couple of months, then you're doing something really wrong.

Posted by Sandy Kemsley at 05:47 PM in BEAparticipate • BPM • SoftwareDesign | Permalink | TrackBacks (0) | Add to del.icio.us

Mariano Benitez of BEA (part of the original Fuego team that built what is now ALBPM) and Bhaskar Rayavaram of Bear Stearns (who was with Fuego before joining Bear Stearns) presented a unified view of BPM and SOA.

Benitez started with some pretty basic stuff about how BPM consumes services, either system-level or presentation-level, and how services can be introspected for easy integration. He then discussed ALBPM as producing services, that is, it can create services that can be consumed by other applications. This was much more interesting and comprehensive; however, overly dense with jargon and acronyms, and obviously dependent on us having attended the session immediately prior in that track (which I didn't). There's a number of mechanisms for producing services using ALBPM:

• Web service front-end to a small set of process API (PAPI) functionality, such as instantiating processes, that's part of Workspace; it appears that all PAPI-based web services use a common WSDL that expose the methods of PAPI.
• Process web services, which are similar to the PAPI web services in functionality, but are implemented in the execution engine rather than Workspace. This can only be used to create instances and send notifications, but is designed as part of the process and provides a unique WSDL for each process.
• Extended web services, which provides a component-level service; obviously I'm missing some key piece of information because I really have no idea what he's talking about here. :)
• HTML API framework (formerly WAPI), which allows for the creation of simple HTML forms that can be called as services in order to call Workspace operations.
• JSR168 portlets, to provide portlet functionality to render Workspace operations.
• And if you really want to beat yourself up, you can create plain Java wrappers for PAPI in order to create custom services, or JMS for asynchronous services.

All of this reinforces my impression that BEA's BPM product focus is still too much on hard-core developers -- the same ones that are writing services at the SOA level -- and not enough on the business side. If I think about this morning's presentation by PG&E, he placed BPM on the IT side of the house, with a process modelling layer as being the business side's participation point. Whatever happened to that lovely zero-code BPM that I saw in Fuego?

Rayavaram talked about how Bear Stearns is using BPM in an SOA environment: how processes identify candidates for service enablement, rather than implementing services then looking for processes that might use them. They're also accessing Fair Isaac's Blaze business rules management system via web services calls from the processes. They have a loose coupling of processes and services, with services deployed separately now but with a view to migrating to an ESB and a full event-driven architecture.

Posted by Sandy Kemsley at 05:43 PM in BEAparticipate • BPM • SOA | Permalink | Comments (2) | TrackBacks (1) | Add to del.icio.us

For the first breakout session, I attended BPM 101 for Portals to hear Jesper Joergensen of BEA's product marketing group and Bob O'Connor of Pratt & Whitney. Jesper started out by giving a brief review of BPM (the usual model/execute/analyze/optimize cycle), since this session is in the portals track and most of the audience is likely much more familiar with portals than with BPM. However, since the description claims that he's also going to discuss how process and portals can work together, I want to hear their message on this since I'll be speaking about BPM at a portals conference in two weeks.

O'Connor then told us about how Pratt & Whitney is using portal technology and -- soon -- ALBPM. They've had a customer portal since 2001, but had a lot of business processes that didn't mesh together very well. In 2002, they added SOA functionality that allowed data to be pulled from multiple systems and presented to the customer, such as all maintenance information for a specific engine based on the serial number. In spite of their advances in their customer portal, however, they still had a number of disparate departments with their own business processes, and no real end-to-end enterprise view of processes. That means that lag time between the separate processes wasn't necessarily logged as part of the end-to-end cycle time for an engine overhaul, for example, but definitely impacted the customer. Since it was between processes, that time was no one's responsibility until they started looking at business processes as they span the enterprise, not just within functional silos.Today, they're doing "manual BPM" for collaboration around engine overhauls, where 1000's of process steps and approvals are logged and uploaded so that customers have a near-real-time view of the overhaul process.

For the past year, they've been working with ALBPM (although they're just starting to roll out BPM applications), and see great potential value from combining ALUI and ALBPM to automate the processes using BPM and provide the necessary visibility into those processes via portals. Their initial processes include line maintenance order-to-cash (where any delays in the process severely impact the customer), quality process clinic management, help center routing, overhaul records coordination, employee awards, engine events management, engine wash, and shop processes. Some of these smaller processes took only a day or two to create in ALBPM, while their internal IT had quoted several months and several hundreds of thousands of dollars to do the same thing. They're pulling data from SAP and other enterprise applications into ALBPM at the start of the process, then feeding back any updates at the end; I would have thought that they'd use web services for at least SAP in order to do interactive updates rather than have to deal with the potential for mis-synchronization between BPM and the back-end systems.

They're doing some pretty innovative combinations of technologies to shorten maintenance cycle times, for example, RFID and other sensors to detect any engine problems while a plane is still in the air allow dispatching of maintenance personnel to be at the site when the plane lands. The time to service the engine may be the same, but the down-time for the aircraft is greatly reduced, which shows a commitment to their customers' concerns.

O'Connor, as a BPM department of one person, is part evangelist and part BPM developer (without having much of an IT background), helping to figure out how BPM can be used across Pratt & Whitney and help implement the solutions.

Although this presentation was really about BPM, I can understand why it's in the portals track: since Pratt & Whitney was a big portals customer first, this shows how you can successfully add BPM to a portal environment.

Posted by Sandy Kemsley at 05:41 PM in BEAparticipate • BPM • SOA | Permalink | TrackBacks (0) | Add to del.icio.us

The general session continues with some BEA product and services information from Shane Pearson, VP of Marketing and Product Management someone whose name that I missed since I was late coming into the session after the break (someone help me out with the name, please), particularly what's been done in the past year:

• In AquaLogic User Interaction, there's some new integrations, improved usability, and greater platform support. They also have some new solution suites; listed under services, I'm not sure how productized these are, or whether they have to come as a professional services offering.
• In ALBPM, they've re-branded and internationalized the Fuego product, and enhanced its integration with other BEA products such as the service bus. They've enhanced both the business and developer tools. As with the ALUI products, they now offer strategy workshops, and there are a number of BPM-specific educational offerings such as BPM lifecycle assessment, some of which are available online.
• In Enterprise Social Computing, the release of the new AL Pages, Ensemble and Pathways products. They also offer management consulting in this area (yes, the phrase "new paradigms" was used); I see this sort of consulting as a huge growth area in the Enterprise 2.0 space, but not necessarily one that can be addressed by product vendors.

Great quote from the presentation: "People use enterprise systems where they provide value, but otherwise work outside enterprise systems for day-to-day work." For years, I've been going into customers and pinpointing deficiencies in their enterprise systems (and usually, therefore, in their business processes) by finding out where they use Excel, Access and paper log files: these are the mechanisms that they create for when the enterprise systems don't provide sufficient value or actually hinder the process. Or, as was stated as the dilemma of the information worker on a later slide, "Our ability to create information has outstripped our ability to easily and accurately use this information in the context of business".

They see their three main product foci as enterprise social computing, BPM and SOA, with impacts on people and participation as well as technology. The product portfolio breaks down as follows:

• Social computing: AquaLogic Pages, AquaLogic Ensemble and AquaLogic Pathways
• Activity servers: AquaLogic Commerce Services, AquaLogic Interaction Analytics, AquaLogic Interaction Collaboration, AquaLogic Interaction Publisher and AquaLogic Interaction Search
• Interaction servers: AquaLogic Interaction and WebLogic Mobility Server
• BPM: AquaLogic BPM (which is a suite including modelling and analytics in addition to the execution engine)

There was a comment about BPM standards such as BPMN and XPDL being supported in the next version -- this is something that I'll want to drill into during a more detailed session or demo. They're also adding RSS enablement, so that work lists can be consumed with any feed reader tool.

The focus at the end of the presentation came back to social computing -- as I mentioned earlier, BEA is obviously betting a lot on this new market segment. I've been reading and writing so much about these technologies that much of this is old hat, but it's likely pretty new for much of the audience, or at least its application within the enterprise is a new concept. "Users at the center", "Poised to transform the enterprise": all the right buzz phrases in place. There were some interesting stats about the use of social computing within organizations, some of which I find hard to believe: 15% using internal blogs? Also, Pearson the presenter has a pretty slim grasp of aggregate statistics, since he added up all the % of who is using enterprise blogs, wikis, bookmarking, etc., and stated that 80% of organizations are using social computing. Um, maybe not. The 15% who are using internal blogs almost certainly has nearly 100% overlap with the 18% who are using internal bookmarking. The stats shown for consumer social networking participation also look high compared to what I've seen recently: 13% of people who are online are creating web pages, blogs and YouTube videos?

There's a not-surprising chart about age demographics and social networking: I'm a "young boomer", apparently, and only 12% of us in this age category create content on the web, so I'm obviously an outlier with three blogs, 3000 Flickr photos, a few videos on YouTube, hundreds of bookmarks on del.icio.us.

it's obvious that the MySpace generation is driving much of the content creation and, if they ever get jobs, will be the ones forcing the adoption of social computing within the enterprise.

Posted by Sandy Kemsley at 12:20 PM in BEAparticipate • BPM | Permalink | Comments (2) | TrackBacks (0) | Add to del.icio.us

Last up before the morning break was Brian Abrahamson, Director of Enterprise Architecture at PG&E; although I've been interested in the portal presentations prior to this, I was relieved to finally get some BPM/SOA content. They started on a huge business transformation strategy two years ago due to various factors such as deregulation and changing legislation that are impacting the competitive landscape in the utility industry, forcing them to become more competitive. Price is certainly a point of competition, but they also have customer service issues such as managing unexpected outages (e.g., what Abrahamson referred to as a "car-pole incident"), installing new residential service, and managing regular maintenance and work orders.

They made an explicit decision to create an SOA layer that would leverage their SAP and Oracle systems in order to provide a more agile development environment. They've been using EAI technologies for a number of years to create integration between enterprise applications, but most of the business processes were embedded in these applications rather than being explicitly defined and executed. Their current direction, therefore, is moving from application-centric to process-centric by allowing the construction of composite applications and business processes from the services provided by the enterprise applications. They consider BPM to be a strategic enabler of their future vision.

What they've done so far is to expose services from the enterprise applications, and used ALSB as an enterprise service bus. ALBPM then allows those services to be used, via the bus, to create executable business processes using those services. As soon as they started exposing BPM to their internal clients, however, there was an immediate demand for modelling, simulation and analytics; now, they're planning for a business process modelling layer that allows their business analysts to do all of these with some type of more comprehensive BPA tool, with round-tripping as a key requirement. Above all of layers is a process architecture and governance layer that, like the modelling layer below it, is business-driven, whereas they see the BPM, ESB and SOA layers as being IT's domain.

They have realized a couple of key points: from the IT side, SOA provides a service layer than greatly expedites BPM; from the business side, cross-departmental process optimization is key to future growth. They have a business process competency centre that does mainly paper-based and manual modelling and analysis, which is a big driver for getting the business process modelling layer in place in their BPM stack.

They learned some valuable lessons along the way: put SOA principles and practices in place early; get executive sponsorship of BPM initiatives; business process modelling, management and governance is more of a business issue than a technology tool issue; and lastly, the market is still maturing and requires partnering with some key technology partners.

Posted by Sandy Kemsley at 10:28 AM in BEAparticipate • BPM • SOA | Permalink | TrackBacks (0) | Add to del.icio.us

Day 1 of the BEA user conference in Atlanta, and we start out with a morning of general sessions hosted by Ira Pollack, SVP Sales at BEA; the remainder of the 2-1/2 day conference is all breakout sessions. There's wifi around but I seem to be missing the conference code necessary to get logged on, so posts will be delayed throughout the conference as I'll be gathering them up to publish at times when I can get internet access. There's also not a power source in sight, which could mean that the last parts of this are really delayed as I transcribe them from paper. :(

BEAParticipate is a new user conference dedicated to portals, BPM and social computing with tracks for business and developer-focussed audiences. My focus has only come on BEA with the acquisition of Fuego a year or so ago, so I'm not sure what they had in terms of user/developer conferences prior to (or in addition to) this, although I talked last night with a web developer who has been a Plumtree customer for years and has transitioned from the Plumtree conference as it was rolled into this conference.

We started out with Mark Carges, EVP of BEA, (who many years ago helped develop the source code for Tuxedo) with a high-level vision of how these technologies can create new types of agile applications, and how BEA is delivering BPM, SOA and enterprise social computing (Enterprise 2.0). He talked about the difference between traditional and situational applications, the top-most point of which is that traditional ones are built for permanance whereas situational ones are built for change: exactly the point that I made last week in my talk at TUCON. He covers other comparative points, such as tightly- versus loosely-coupled, non-collaborative versus collaborative, homogeneous vertical integration in application siles versus heterogeneous horizontal integration, and application-driven versus business process-driven.

He walked us through a few examples of their customers' portal applications -- purely intranet, customer-facing, and public -- and one example of BPM in a customer, before moving on to talk about BEA's strategy and product development, particularly in Enterprise 2.0. He made the point that enterprise applications are having to learn from the consumer-facing Web 2.0 applications by allowing for different types and degrees of user participation. Instead of just listing consumer Web 2.0 applications, however, Carges makes analogies with how the same sort of technology could be used inside an enterprise: Digg-like ranking used for ranking sales tools internally; social bookmarking and implicit connections for internal expert knowledge discovery (much like what IBM is doing with Dogear, which I'm sure that they'll turn into a commercial product once companies like BEA prove the market for it); mashups for creating a single view of a customer from multiple sources including product, support incidents and account information; and wikis to capture competitive intelligence. This is where their new product suite fits: AquaLogic Pages (to create pages, blogs and wikis), Ensemble (for developers to create mashups) and Pathways (for tagging and bookmarking). All of these mesh with IT governance such as security and versioning, but the content isn't controlled by IT.

Interesting that the focus of his talk has really been on their new Enterprise 2.0 products rather than portals or BPM; they obviously see this as a strong potential growth area.

Posted by Sandy Kemsley at 10:23 AM in BEAparticipate • BPM • Enterprise2.0 • mashups | Permalink | Comments (2) | TrackBacks (0) | Add to del.icio.us

The Transformation & Innovation conference is running in Washington DC on May 21-24, with several sessions on BPM.

I won't be there; the dates are sandwiched in between a vacation trip to Nova Scotia and a presentation at the Shared Insights Portals & Collaboration conference in Las Vegas.

Posted by Sandy Kemsley at 04:07 PM in BPM | Permalink | TrackBacks (0) | Add to del.icio.us

Thursday morning, and it seems like a few of us survived last night's baseball game (and the after-parties) to make it here for the first session of the day. This will be my last session of the conference, since I have a noon flight in order to get back to Toronto tonight.

Tim Stephenson and Mark Elder from TIBCO talked about Business Studio, carrying on from Tim's somewhat shortened bit on Business Studio on Tuesday when I took up too much of our joint presentation time. The vision for the new release coming this quarter is that one tool can be used by business analysts, graphical tools developers and operational administrators by allowing for different perspectives, or personas. There's 9 key functions from business process analysis and modelling to WYSIWYG forms design to service implementation.

The idea of the personas within the product are similar to what I've seen in the modelling tool of other BPMS vendors: each has a different set of functions available and has some different views onto the process being modelled. Tim gave some great insight into how they considered the motivations and requirements of each of the types of people that might use the product in order to develop the personas, and showed how they mapped out the user experience flow with the personas overlaid to show the interfaces and overlaps in functionality. This shows very clearly the overlap between the business analyst and developer functionality, which is intentional: who does what in the overlap depends on the skills of the particular people involved.

As we heard in prior sessions, Business Studio provides process modelling using BPMN, plus concept modelling (business domain data modelling) using UML to complement the process model. There's a strong focus on how BPM can consume web services and BusinessWorks services, because much of the audience is likely developers who use TIBCO's other products like BusinessWorks to create service wrappers around legacy applications. At one point between sessions yesterday, I had an attendee approach me and thank me for the point that I made in my presentation on Tuesday about how BPM is the killer app for SOA (a point that I stole outright from Ismael Ghalimi -- thanks, Ismael!), because it helped him to understand how BPM creates the ROI for SOA: without a consumer of services, the services themselves are difficult to justify.

We saw a (canned) demo of how to create a simple process flow that called a number of services that included a human-facing step, a database call to a stored procedure, a web service call based on introspecting the WSDL and performing some data mapping/transformation, a script task that uses JavaScript to perform some parameter manipulation, and an email task that allows the runtime process instance parameters to be mapped to the email fields. Then, the process definition is exported to XPDL, and imported into the iProcess Modeler in order to get it into the repository that's shared with the execution engine. Once that's done, the process is executable: it can be started using the standard interface (which is built in General Interface), and the human-facing steps have a basic form UI auto-generated.

It is possible to generate an HTML document that describes a process definition, including a graphical view of the process map and tabular representations of the process description.

As I mentioned in other posts, and in many posts that I've made about BPA tools, is that there's no shared model between the process modeller, which is a serious issue for process agility and round-tripping unless you do absolutely nothing to the process in the iProcess Modeler except to use it as a portal to the execution repository. TIBCO has brought a lot (although not all) of the functionality of the Modeler into Studio, and are working towards a shared model between analysts and developers; they believe that they can remove the need for Modeler altogether over time. There's no support at this time, however, to being able to deploy directly from Studio, that is, Studio won't plug directly into the execution engine environment. Other vendors who have gone the route of a downloadable disconnected process modeller or a separate process discovery tool are dealing with the same issue; ultimately, they all need to make this new generation of modelling tools have the capability to be as integrated with the execution environment as those that they're replacing in order to eliminate the requirement for round-tripping.

Posted by Sandy Kemsley at 12:59 PM in BPM • BPM standards • SOA • TUCON | Permalink | TrackBacks (0) | Add to del.icio.us

In an afternoon breakout session, Larry Tubbs from AmeriCredit talked about using TIBCO to automate their contract processing workflow, that is, the part between loan origination/approval and the contract administration system. Their business case was similar to that I've seen in many other financial and insurance applications: visibility into the processes, appropriate management of the resources, and ever more stringent regulatory requirements. They did a product evaluation and selected TIBCO, using iProcess Suite, BusinessFactor, BusinessWorks, and EMS as the underlying service bus. They implemented really quickly: for their initial release, it was a matter of months from initial design to rollout to five branches handling 1600 cases simultaneously (the system is designed for a peak load of 7000 cases).

Nimish Rawal from TIBCO, who was involved in the implementation, described some details of what they did and the best practices that they used: use iProcess engine for process orchestration and BusinessWorks for integration; put application data in a separate schema (they had 583 instance data fields and 257 metadata fields); create a queue/group structure according to business divisions; and allow the business to control the rules to allow for easy changes to the process flow or any changing regulations. They used master and slave iProcess servers hitting against a common database to distribute the load, and used clustering for high availability although the failover process is not automatic (which surprised me a bit since clustering software or hardware can automate this). They also planned for disaster recovery by distributing nodes between two physical locations and sending archive files from the master to DR site about once every five minutes; again, the failover is not automatic, but that's less expected in the case of a total site loss.

Rawal also went through the TIBCO professional services engagement model. On the AmeriCredit side, they had four core developers to work with the TIBCO team (which went from five to seven to two), and now the TIBCO people only do mentoring with all development being done by AmeriCredit's developers.

Posted by Sandy Kemsley at 06:46 PM in BPM • TUCON | Permalink | TrackBacks (0) | Add to del.icio.us

Ryan Herd, who heads the BPM centre of competence within RBM Private Bank, was up next to talk about the analysis that they did on open source BPM alternatives. Funny that the South Africans, like we understated Canadians, use the term "centre of competence" as opposed to the very American "center of excellence". :)

Don't tell Ismael Ghalimi, but Herd thinks that jBoss' jBPM is the only open source BPM alternative; it was the only one that they evaluated, along with a number of proprietary solutions including TIBCO. Given that he's here speaking at this conference, you can guess which one they picked.

Their BPM project started with some strategic business objectives:

• operational efficiency
• improved client service
• greater business process agility

and some technology requirements:

• a platform to define, improve and automate business processes
• real-time and historical process instance statistics
• single view of a client and their related activities

They found that then needed to focus on three things:

• Process: dynamic quality verification, exception handling that can step outside the defined process, and a focus on the end-to-end process.
• People: have their people be obsessed with the client, develop an end-to-end process culture in order to address SLAs, and create full-function teams rather than an assembly-line process.
• Systems: a single processing front-end, a reusable business object layer and centralized work management.

Next, they started looking at vendors, and for whatever reasons, open source was considering the mix: quite forward-thinking for a bank. In addition to TIBCO and jBPM, they considered DST's AWD, IBM's BPM, eiStream (now Global 360) and K2: a month and a half to review all of the products, then another month and a half doing a more focussed comparison of TIBCO and jBPM.

For process design, jBPM has only a non-visual programmer-centric environment, and has support for BPEL but not (obviously, since it's not visual) BPMN. It does allow modelling freedom, but that can be a problem with enforcing internal standards. It also has no process simulation. TIBCO, on the other hand, has a visual process modelling environment that supports BPMN, has a near zero-code process design and provides simulation. Point: TIBCO.

On the integration side, jBPM has no graphical application integration environment, although it has useful integration objects and methods and has excellent component-based design. The adapters are available but not easily reused, and has no out-of-the box communication or integration facilities. TIBCO has a graphical front-end for application integration, and a lots of adapters and integration facilities. Point: TIBCO.

On the UI side, jBPM has only a rudimentary web-based end user environment, whereas TIBCO has the full GI arsenal at their disposal. Point: TIBCO.

Reporting and analytics: jBPM has nothing, TIBCO has iProcess Analytics and (now) iProcess Insight.

Support: don't even go there, although jBoss wins on price. :)

Overall, they found that the costs would be about the same (because of the greater jBPM customization requirement), but a much longer time to deploy with jBPM, which had them choose TIBCO.

Given what they found, I find it amazing that they spent three months looking at jBPM, since jBPM is, in its raw form, a developer tool whereas TIBCO spans a broader range of analyst and developer functionality. The results as presented are so biased in favour of TIBCO that it should have been obvious long before any formal evaluation was done that jBPM wasn't suited for their particular purposes and should not have made their short list; likely, open source was someone's pet idea so was thrown into the mix on a lark. Possibly an open source BPM solution like Intalio, which wasn't available as open source at the time of their evaluation, would have made a much better fit for their needs if they were really dedicated to open source ideals. I'm pretty sure that anyone in the room that had not considered open source in the past would run screaming away from it in the future.

Getting past the blatant TIBCO plug masquerading as a product comparison, Herd went on to show the architecture of their solution, which uses a large number of underlying services managed by a messaging layer to interface with the BPM layer -- a fairly standard configuration. They expect to go live later this year.

Posted by Sandy Kemsley at 04:10 PM in BPM • OpenSource • TUCON | Permalink | TrackBacks (1) | Add to del.icio.us

At this point, it makes more sense to start labelling the posts by session title rather than presenter, since we're getting into some pretty detailed breakout topics. This one was presented by Roger King, Director of BPM Product Strategy & Management at TIBCO, and Justin Brunt, product manager for iProcess.

Most of the technical people working TIBCO's BPM group seem to be vestiges of the Staffware acquisition; many of them are still based in the UK, where the development is still done.

They started out with a review of what's happened in the products in the past 12 months:

• Business Studio 1.x, a standalone modelling and simulation product aimed at business analysts; the free downloadable version released in November already has more than 10,000 downloads. Modelling is done in BPMN, and XPDL is supported for import and export -- necessary for even getting the models into the iProcess Suite for execution, since there is no shared model with the process execution environment. It also supports imports from Visio and ARIS. There's some more advanced features as well: a hierarchical organization of business processes and associated assets; and process simulation with SLA indicators and reports.
• iProcess Suite 10.5, with improved work queue performance and scalability to support more concurrent users, better performance for sorting and filtering (always slow with most BPM products) and faster startup time. It also included an enhanced web client based on General Interface, with GI or custom forms support and a number of other new functions.
• iProcess Insight 2.0, the BAM product, which I reviewed in a post yesterday.

What's coming in the near future:

• Business Studio 2.0, with support for the full BPMN 1.0 specification and XPDL 2.0. I keep meaning to download Business Studio and do some comparative analysis with some of the other downloadable modelling products, but I may wait until version 2.0. I wrote about a few of the new features from Tim Stephenson talk yesterday, but here's a recap. In the process analyst perspective: design patterns/fragments to speed design, refactoring, concept modelling with UML support, import/export of EPC/FAD from ARIS, and custom XSLT translations to XPDL. In the process architect perspective: service registry, native services such as email and database connectors, direct server deployment and version control
• iProcess Suite core component support for some new platforms, including 64-bit Windows Server and Red Hat Linux; direct deployment from Studio to Engine (although it's not clear if this is via a shared model or just automates the import/export process); and new audit trail entries. They've also simplified installation.
• Web services capability, with support for WS security at the transport and SOAP layer, and support for withdraw actions and delayed release.

They went on to discuss a number of key themes in product development for this year and beyond.

They're gradually migrating to a single modelling/design environment -- Business Studio -- although they're still not quite there yet; this will provide a more consistent experience for both business and IT users of the design tools. This supports the move to full model-driven development by allowing for the easy integration of forms design into the Eclipse-based environment, which can in turn generate GI, JSP or other runtime forms for the updated iProcess web client. Business rules definition will be in the Eclipse-based design environment, although it's not clear if they're using a third-party BRE or have their own rules technology. The old modelling environment, Business Modeler, isn't going away any time soon, but new feature development will focus on Business Studio so will encourage migration. Like most vendors using this tactic to get existing customers off an old product, I expect that they'll hear grumbling about this for years.

The out-of-the-box web client will be simplified and made to look more like the familiar Outlook client, with improved performance. The UI will also be exposed as components and services to allow them to be included in custom applications or portals, and they'll ship an out-of-the-box BPM portal using TIBCO's portal platform to show how this can be used. There will be better MS-Office integration and an Eclipse-based desktop application.

They're also going to provide a project collaboration portal for BPM projects, to allow people developing TIBCO BPM applications to collaborate. They're also adding in some governance capabilities to help handle the lifecycle of BPM projects and assets.

King mentioned my presentation from yesterday directly, and commented that they're going to be supporting more of the BPA tools for import soon, including Proforma. They've obviously identified that it's important to be extremely open from both a standards and BPA support standpoint.

Next on the list is goal-driven BPM, or virtual processes, where there may be too many process alternatives to model explicitly and the optimal runtime process has to be generated based on process parameters and environmental factors. This sounds like fuzzy future stuff, but would be great if they can pull it off.

They're also developing workforce management and more complex resource modelling for the purposes of business optimization.

There was a brief point at the end about preparing for the next generation of SOA, although no time to talk about what this means; I would have loved if this session had been a bit longer.

Posted by Sandy Kemsley at 04:08 PM in BPM • BPM standards • BRE • TUCON | Permalink | TrackBacks (0) | Add to del.icio.us

In the last session of the day, hence the only thing standing between the attendees and the bar, Tim and I gave a talk on business process modelling. My portion of the talk, which was not at all TIBCO-specific, talked about modelling for the masses; I'll publish it here when I get a chance. Tim followed on with information about the new release of Business Studio, and how it's used for process modelling. Tim and I met via email about a month ago when we were getting this all set up, and on Sunday we finally had a chance to meet face-to-face. In spite of our short time together, we're pretty aligned on most of the issues, so had some pretty good synergy in our talk.

I feel sorry for Tim, as I do for anyone who presents after me, since I tend to get really carried away with what I'm talking about, and I went over my 20-minute allotment of our 40-minute presentation. 10 minutes over. I had a great time, however. :)

Tim went into many of the details of process modelling in the TIBCO Business Studio environment, and showed some particular BPMN examples that can be tricky to understand, such as gateways and events. It looks like they've done some nice work of creating process fragments -- design patterns for portions of a process -- that can be easily inserted in at any point in a process to save time. He also discussed their concept modeller for business domain modelling, allowing you to create an enterprise common object model using formal UML notation. He also had to shore up the damage that I did by slamming the lack of round-tripping by most BPA and BPM vendors.

That's it for today; we're all off for drinks at the evening reception, then I have dinner with some of the product marketing team which will give me a chance to pump them for information about what's coming up.

Tomorrow promises to be interesting -- the BPM track is packed with winners, so I'll be stuck in this same room with the crappy wifi all day, but promise to emerge occasionally and publish what I've written.

Posted by Sandy Kemsley at 08:19 PM in BPA • BPM • TUCON | Permalink | TrackBacks (1) | Add to del.icio.us