I’m attending a workshop at the first morning of CASCON, the conference on software research hosted by IBM Canada. There’s quite a bit of good work done at the IBM Toronto software lab, and this annual conference gives them a chance to engage the academic and corporate community to present this research.

The focus of this workshop is service integration, including enabling new services from existing applications and creating new services by composing from existing services. Hacking together a few services into a solution is fairly simple, but your results may not be all that predictable; industrial-strength service integration is a bit more complex, and is concerned with everything from reusability to service level agreements. As Allen Chan of IBM put it when introducing the session: “How do we enable mere mortals to create a service integration solution with predictable results and enterprise-level reliability?”

The first presentation was by Mannie Kagan, an IBMer who is working with TD Bank on their service strategy and implementation; he walked us through a real-life example of how to integrate services into a complex technology environment that includes legacy systems as well as newer technologies. Based on this, and a large number of other engagements by IBM, they are able to discern patterns in service integration that can greatly aid in implementation. Patterns can appear at many levels of granularity, which they classify as primitive, subflow, flow, distributed flow, and connectivity topology. From there, they have created an ESB framework pattern toolkit, an Eclipse-based toolkit that allows for the creation of exemplars (templates) of service integration that can then be adapted for use in a specific instance.

He discussed two particular patterns that they’ve found to be particularly useful: web service notification (effectively, pub-sub over web services), and SCRUD (search, create, read, updated, delete); think of these as some basic building blocks of many of the types of service integrations that you might want to create. This was presented in a specific IBM technology context, as you might imagine: DataPower SOA appliances for processing XML messages and legacy message transformations, and WebSphere Services Registry and Repository (WSRR) for service governance.

In his wrapup, he pointed out that not all patterns need to be created at the start, and that patterns can be created as required when there is evidence of reuse potential. Since patterns take more resources to create than a simple service integration, you need to be sure that there will be reuse before it is worth creating a template and adding it to the framework.

Next up was Hans-Arno Jacobsen of University of Toronto discussing their research in managing SLAs across services. He started with a business process example of loan application processing that included automated credit check services, and had an SLA in terms of parameters such as total service subprocess time, service roundtrip time, service cost and service uptime. They’re looking at how the SLAs can guide the efficient execution of processes, based in a large part on event processing to detect and determine the events within the process (published state transitions). He gave quite a detailed description of content-based routing and publish-subscription models, which underlie event-driven BPM, and their PADRES ESB stack that hides the intricacies of the underlying network and system events from the business process execution by creating an overlay of pub-sub brokers that filters and distributes those events. In addition to the usual efficiencies created by the event pub-sub model, this allows (for example) the correlation of network slowdowns with business process delays, so that the root cause of a delay can be understood. Real-time business analytics can also be driven from the pub-sub brokers.

He finished by discussing how business processes can actually be guided by SLAs, that is, runtime use of SLAs rather than just for monitoring processes. If the process can be allocated to multiple resources in a fine-grained manner, then the ESB broker can dynamically determine the assignment of process parts to resources based on how well those resources are meeting their SLAs, or expected performance based on other factors such as location of data or minimization of traffic. He gave an example of optimization based on minimizing traffic by measuring message hops, which takes into account both rate of message hops and distance between execution engines. This requires that the distributed execution engines include engine profiling capabilities that allows an engine to determine not only its own load and capacity, but that of other engines with which it communicates, in order to minimize cost over the entire distribute process. To fine-tune this sort of model, process steps that have a high probability of occurring in sequence can be dynamically bound to the same execution engine. In this situation, they’ve seen a 47% reduction in traffic, and a 50% reduction in cost relative to the static deployment model.

After a brief break, Ignacio Silva-Lepe from IBM Research presented on federated SOA. SOA today is mostly used in a single domain within an organization, that is, it is fairly siloed in spite of the potential for services to be reused across domains. Whereas a single domain will typically have its own registry and repository, a federated SOA can’t assume that is the case, and must be able to discover and invoke services across multiple registries. This requires a federation manager to establish bridges across domains in order to make the service group shareable, and inject any cross-domain proxies required to invoke services across domains.

It’s not always appropriate to have a designated centralized federation manager, so there is also the need for domain autonomy, where each domain can decide what services to share and specify the services that it wants to reuse. The resulting cross-domain service management approach allows for this domain autonomy, while preserving location transparency, dynamic selection and other properties expected from federated SOA. In order to enable domain autonomy, the domain registry must not only have normal service registry functionality, but also references to required services that may be in other domains (possibly in multiple locations). The registries then need to be able to do a bilateral dissemination and matching of interest and availability information: it’s like internet dating for services.

They have quite a bit of work planned for the future, beyond the fairly simple matching of interest to availability: allowing domains to restrict visibility of service specifications to authorized parties without using a centralized authority, for example.

Marsha Checkik, also from University of Toronto, gave a presentation on automated integration determination; like Jacobsen, she collaborates with the IBM Research on middleware and SOA research; unlike Jacobsen, however, she is presenting on research that is at a much earlier stage. She started with a general description of integration, where a producer and a consumer share some interface characteristics. She went on to discuss interface characteristics (what already exists) and service exposition characteristics (what we want): the as-is and to-be state of service interfaces. For example, there may be a requirement for idempotence, where multiple “submit” events over an unreliable communications medium would result in only a single result. In order to resolve the differences in characteristics between the as-is and to-be, we can consider typical service interface patterns, such as data aggregation, mapping or choreography, to describe the resolution of any conflicts. The problem, however, is that there are too many patterns, too many choices and too many dependencies; the goal of their research is to identify essential integration characteristics and make a language out of them, identify a methodology for describing aspects of integration, identify the order in which patterns can be determined, identify decision trees for integration pattern determination, and determine cases where integration is impossible.

Their first insight was to separate pattern-related concerns between physical and logical characteristics; every service has elements of both. They have a series of questions that begin to form a language for describing the service characteristics, and a classification for the results from those questions. The methodology contains a number of steps:

1. Determine principle data flow
2. Determine data integrity data flow, e.g., stateful versus stateless
3. Determine reliability flow, e.g., mean time between failure
4. Determine efficiency, e.g., response time
5. Determine maintainability

Each of these steps determines characteristics and mapping to integration patterns; once a step is completed and decisions made, revisiting it should be minimized while performing later steps.

It’s not always possible to provide a specific characteristic for any particular service; their research is working on generating decision trees for determining if a service requirement can be fulfilled. This results in a pattern decision tree based on types of interactions; this provides a logical view but not any information on how to actually implement them. From there, however, patterns can be mapped to implementation alternatives. They are starting to see the potential for automated determination of integration patterns based on the initial language-constrained questions, but aren’t seeing any hard results yet. It will be interesting to see this research a year from now to see how it progresses, especially if they’re able to bring in some targeted domain knowledge.

Last up in the workshop was Vadim Berestetsky of IBM’s ESB tools development group, presenting on support for patterns in IBM integration offerings. He started with a very brief description of an ESB, and WebSphere Message Broker as an example of an ESB that routes messages from anywhere to anywhere, doing transformations and mapping along the way. He basically walked through the usage of the product for creating and using patterns, and gave a demo (where I could see vestiges of the MQ naming conventions). A pattern specification typically includes some descriptive text and solution diagrams, and provides the ability to create a new instance from this pattern. The result is a service integration/orchestration map with many of the properties already filled in; obviously, if this is close to what you need, it can save you a lot of time, like any other template approach.

In addition to demonstrating pattern usage (instantiation), he also showed pattern creation by specifying the exposed properties, artifacts, points of variability, and (developer) user interface. Looks good, but nothing earth-shattering relative to other service and message broker application development environments.

There was an interesting question that goes to the heart of SOA application development: is there any control over what patterns are created and published to ensure that they are useful as well as unique? The answer, not surprisingly, is no: that sort of governance isn’t enforced in the tool since architects and developers who guide the purchase of this tool don’t want that sort of control over what they do. However, IBM may see very similar patterns being created by multiple customer organizations, and choose to include a general version of that pattern in the product in future. A discussion about using social collaboration to create and approve patterns followed, with Berestetsky hinting that something like that might be in the works.

That’s it for the workshop; we’re off to lunch. Overall, a great review of the research being done in the area of service integration.

This afternoon, there’s the keynote and a panel that I’ll be attending. Tomorrow, I’ll likely pop in for a couple of the technical papers and to view the technology showcase exhibits, then I’m back Wednesday morning for the workshop on practical ontologies, and the women in technology lunch panel. Did I mention that this is a great conference? And it’s free?

We started after the break with Jeremy Westerman, head of BPM product marketing for TIBCO, presenting on AMX BPM. The crowd is a bit slow returning, which I suspect is due more to the availability of Wii Hockey down the hall than to the subject matter. Most telling, Westerman has the longest timeslot of the day, 45 minutes, which shows the importance that TIBCO is placing on marketing efforts for this new generation of their BPM platform. As I mentioned earlier, I’ve had 3+ hours of briefing on AMX BPM recently and think that they’ve done a good job of rearchitecting – not just refactoring – their BPM product to a modern architecture that puts them in a good competitive position, assuming that they can get the customer adoption. He started by talking about managing business processes as strategic assets, and the basics of what it means to move processes into a BPMS, then moved on to the TIBCO BPM products: Business Studio for modeling, the on-premise AMX BPM process execution environment, and the cloud-based Silver BPM process execution environment. This built well on their earlier messages about integration and SOA, since many business processes – especially for the financial-biased audience here today – are dependent on integrating data and messaging with other enterprise systems. Business-friendly is definitely important for any BPM system, but the processes also have to be able to punch at enterprise weight.

His explanation of work management also covered optimizing people within the process: maximizing utilization while still meeting business commitments through intelligent routing, unified work lists and process/work management visibility. A BPM system allows a geographically distributed group of resources to be treated as single pool for dynamic tunable work management, so that the actual organizational model can be used rather than an artificial model imposed by location or other factors. This led into a discussion of workflow patterns, such as separation of duties, which they are starting to build into AMX BPM as I noted in my recent review. He walked through other functionality such as UI creation, analytics and event processing; although I’ve seen most of this before, it was almost certainly new to everyone except the few people in the room who had attended TUCON back in May. The BPM booth was also the busiest one during the break, indicating a strong audience interest; I’m sure that most BPM vendors are seeing this same level of interest as organizations still recovering from the recession look to optimize their processes to cut costs and provide competitive advantage.

Ivan Casanova, director of cloud marketing for TIBCO, started with some pretty simple Cloud 101 stuff, then outlined their Silver line of cloud platforms: Silver CAP for developing cloud services, Silver Fabric for migrating existing applications, Silver BPM for process management, and Silver Spotfire for analytics. Some portion of the IT-heavy audience was probably thinking “not in my data centre, dude!”, but eventually every organization is going to have to think about what a cloud platform brings in terms of speed of deployment, scalability, cost and ability to collaborate outside the enterprise. Although he did talk about using Fabric for “private cloud” deployments that leverage cloud utility computing principles for on-premise systems, he didn’t mention the most likely baby step for organizations who are nervous about putting production data in the cloud, which is to use the cloud for development and testing, then deploy on premise. He finished with a valid point about how they have a lot of trust from their customers, and how they’ve built cloud services that suit their enterprise customers’ privacy needs; IBM uses much the same argument about why you want to use an large, established, trusted vendor for your cloud requirements rather than some young upstart.

We then heard from Greg Shevchik, a TIBCO MDM specialist, for a quick review of the discipline of master data management and TIBCO’s Collaborative Information Manager (CIM). CIM manages the master data repositories shared by multiple enterprise systems, and allows other systems – such as AMX BPM – to use data from that single source. It includes a central data repository; governance tools for validation and de-duplication; workflow for managing the data repository; synchronization of data between systems; and reporting on MDM.

Last up for the Toronto TIBCO Now was Al Harrington (who was the mystery man who opened the day), giving us a quick view of the new generation of TIBCO’s CEP product, BusinessEvents. There’s a lot to see here, and I probably need to get a real briefing to do it justice; events are at the heart of so many business processes that CEP and BPM are becoming ever more intertwined.

My battery just hit 7% and we’re after 5pm, so I’ll wrap up here. The TIBCO Now roadshow provides a good overview of their updated technology portfolio and the benefits for customers; check for one coming your way.

We’re overtime on the general session, 2.75 hours without a break, and Matt Quinn is up to talk about the TIBCO product stack and some of the recent releases as well as upcoming releases:

• Spotfire 3.1
• BusinessEvents 4.0, with an improved Eclipse-based development environment including a rule debugger, and a multi-threaded engine
• BEViews (BusinessEvents Views) for creating real-time customizable dashboards for monitoring the high-speed events (as opposed to Spotfire, which can include data from a much broader context)
• ActiveSpaces Suite for in-memory processing, grid computing and events, with the new AS Transactions and AS Patterns components
• Silver Suite for cloud deployment, including Fabric, Grid and CAP (Composite Application Platform)
• PeopleForms, which I saw a brief view of yesterday: a lightweight, forms-based application development environment
• tibbr, their social microblogging platform; I think that they’re pushing too much of the social aspect here, when I think that their sweet spot is in being able to “follow” and receive messages/events from devices rather than people
• Silver Analytics
• ActiveMatrix 3.0, which is an expansion of the lightweight application development platform to make this more of an enterprise-ready
• ActiveMatrix BPM, which he called “the next generation of BPM within TIBCO” – I’ll have more on this after an in-depth briefing
• Silver BPM, the cloud-deployable version of BPM
• Design Collaborator, which is a web-based design discovery tool that will be available in 2011: this appears to be their version of an online process discovery tool, although with more of a services focus than just processes; seems late to be introducing this functionality to the market

I heard much of this yesterday from Tom Laffey during the analyst session, but this was a good refresher since it’s a pretty big set of updates.

We had a brief comment from Tom Laffey in the general session about TIBCO’s new ultra low latency messaging platform to be released by year end, which breaks the microsecond barrier. They’re calling it FTL, which makes my inner (or not so inner) geek giggle with happiness: for sci-fi fans, that’s the acronym for “Faster Than Light” spaceship drives. I love it when technology companies tip a nod to the geeks who use and write about their products, while remaining on topic.

It’s also new (for TIBCO) since it provides content-based routing and structured data support, which are, apparently, just as important as a cool name.

The third keynote speaker this morning was Wolfgang Gaertner, CIO of Deutsche Bank: we’ve moved from international crime-fighting to the somewhat more mundane – but every bit as international and essential – world of banking. Their biggest challenge over the past few years has been to reduce the paper flow that was slowing the communication between their processing centers, reduce processing time, and improve customer service levels: all of which they have achieved. They’ve used TIBCO to integrate their multiple legacy systems, especially those from mergers and acquisitions such as they had with Berliner Bank, where they wanted to maintain the customer brand but integrate the back-end systems to allow for greater efficiency and governance.

They’re using BPM to manage some of the processes, such as special account opening and exception handling, and are finding that the new technology drives new opportunities: as other areas in the bank see what can be done with integration and BPM, they want to have that for their applications as well. They’re also planning to rip out their core legacy systems and replace them with SAP, and use TIBCO for integration and workflow: TIBCO is a big enabler here, since Deutsche Bank now has sufficient experience with TIBCO products to understand how it can be used to help with this technology transformation.

Tom Laffey, EVP of Products and Technology, gave us an update at the analyst session yesterday on their new product releases (embargoed until today), but started with an interesting timeline of the their acquisitions. Unlike some companies, who make acquisitions just to remove a competitor from the market, TIBCO appears to have made some thoughtful buys over the years in order to build out a portfolio of infrastructure products. More than just being a Wall Street messaging company with Rendezvous, they have a full stack of mission-critical event processing, messaging, process management, analytics and more that puts them squarely in competition with the big players. Their competition differs for the different product segments: IBM is their biggest competitor, but others including Oracle, some small players and even open source in some cases. They offer fully-responsive 7×24 support through a series of worldwide support centers, handling more than 40,000 support requests per year.

Unfortunately, this leaves them with more than 200 products: a massive portfolio that makes it difficult for them to explain, and even more difficult for customers to understand. A core part of the portfolio is the “connect” part that we heard about earlier: moving point-to-point integrations onto a service bus, using products such as Rendezvous, EMS, BusinessWorks, all manner of adapters, ActiveMatrix, BusinessConenct, CIM, ActiveSpaces and tibbr. On the “automate” part of the platform is all of their BPM offerings: iProcess, the newly-announced ActiveMatrix BPM, Business Studio and PeopleForms. Laffey claimed up front that iProcess is not being replaced by ActiveMatrix BPM (methinks he doth protest too much), which means that there is likely some functionality overlap. The third part, “optimize”, includes Spotfire Suite, S+, BusinessEvents and Netrics.

He discussed their cloud strategy, which includes “internal clouds” (which, to many of us, are not really clouds) as well as external clouds such as AWS; the new Silver line of products – CAP, Grid, Integrator, Fabric, Federator and BPM – are deployable in the cloud.

The major product suites are, then:

• ActiveMatrix (develoment, governance and integration)
• ActiveMatrix BPM (BPM)
• Spotfire (user-driven analytics and visualization)
• BusinessEvents (CEP)
• ActiveSpaces (in-memory technologies, datagrid, matching, transactions)
• Silver (cloud and grid computing)

He dug back into the comparison between iProcess and ActiveMatrix BPM by considering the small number of highly-complex core business processes (such as claims processing) that are the focus for iProcess, versus the large number of tactical or situational small applications with simple workflows that are served by PeopleForms and ActiveMatrix BPM. He gave a quick demo that shows this sort of simple application development being completely forms-driven: create forms using a browser-based graphical form designer, then email it to a group of people to gather responses to the questions on the form. Although he referred to this as “simple BPM” and “BPM for the masses”, it’s not clear that there was any process management at all: just an email notification and gathering responses via a web form. Obviously, I need to see a lot more about this.

The keynotes sessions this morning were typical “big conference”: too much loud music, comedians and irrelevant speakers for my taste, although the brief addresses by Steve Mills and Craig Hayman as well as this morning’s press release showed that process is definitely high on IBM’s mind. The breakout session that I attended following that, however, contained more of the specifics about what’s happening with IBM WebSphere BPM. This is a portfolio of products – in some cases, not yet really integrated – including Process Server and Lombardi.

Some of the new features:

• A whole bunch of infrastructure stuff such as clustering for simple/POC environments
• WS CloudBurst Appliance supports Process Server Hypervisor Edition for fast, repeatable deployments
• Database configuration tools to help simplify creation and configuration of databases, rather than requiring back and forth with a DBA as was required with previous version
• Business Space has some enhancements, and is being positioned as the “Web 2.0 interface into BPM” (a message that they should probably pass on to GBS)
• A number of new and updated widgets for Business Space and Lotus Mashups
• UI integration between Business Space and WS Portal
• Webform Server removes the need for a client form viewer on each desktop in order to interact with Lotus Forms – this is huge in cases where forms are used as a UI for BPM participant tasks
• Version migration tools
• BPMN 2.0 support, using different levels/subclasses of the language in different tools
• Enhancements to WS Business Modeler (including the BPMN 2.0 support), including team support, and new constructs including case and compensation
• Parallel routing tasks in WPS (amazing that they existed this long without that, but an artifact of the BPEL base)
• Improved monitoring support in WS Business Monitor for ad hoc human tasks.
• Work baskets for human workflow in WPS, allowing for runtime reallocation of tasks – I’m definitely interested in more details on this
• The ability to add business categories to tasks in WPS to allow for easier searching and sorting of human tasks; these can be assigned at design time or runtime
• Instance migration to move long-running process instances to a new process schema
• A lot of technical implementation enhancements, such as new WESB primitives and improvements to the developer environment, that likely meant a lot to the WebSphere experts in the room (which I’m not)
• Allowing Business Monitor to better monitor BPEL processes
• Industry accelerators (previously known as industry content packs) that include capability models, process flows, service interfaces, business vocabulary, data models, dashboards and solution templates – note that these are across seven different products, not some sort of all-in-one solution
• WAS and BPM performance enhancements enabling scalability
• WS Lombardi Edition: not sure what’s really new here except for the bluewashing

I’m still fighting with the attendee site to get a copy of the presentation, so I’m sure that I’ve missed things here, but I have some roundtable and one-on-one sessions later today and tomorrow that should clarify things further. Looking at the breakout sessions for the rest of the day, I’m definitely going to have to clone myself in order to attend everything that looks interesting.

In terms of the WPS enhancements, many of the things that we saw in this session seem to be starting to bring WebSphere BPM level with other full BPM suites: it’s definitely expanding beyond being just a BPEL-based orchestration tool to include full support for human tasks and long-running processes. The question lurking in my mind, of course, is what happens to FileNet P8 BPM and WS Lombardi (formerly TeamWorks) as mainstream BPM engines if WPS can do it all in the future? Given that my recommendation at the time of the FileNet acquisition was to rip out BPM and move it over to the WebSphere portfolio, and the spirited response that I had recently to a post about customers not wanting 3 BPMSs, I definitely believe that more BPM product consolidation is required in this portfolio.

BPM acquisitions must be in the air: today, Progress Software announced that they’ve bought Savvion for $49M. This is hot on the heels of IBM’s announcement last month that they’re buying Lombardi, with one huge difference being that Progress doesn’t already have a BPM product in their lineup, whereas IBM has two. Of the three mid-range BPMS-only vendors that I would most commonly name – Appian, Lombardi and Savvion – that’s two out of the three announcing acquisition in less than a month. With the economy just starting to pull out of a huge pit, that’s telling news: as I mentioned in my post about Lombardi, if the economic climate were different, these would be IPOs that we’d be seeing rather than acquisitions. These acquisitions by larger companies, however, changes the BPM market landscape pretty significantly, since this makes it significantly easier for Lombardi and Savvion (under the IBM and Progress banners, respectively) to get a foot in the door of larger customers who rely on their major vendors to bring them enterprise solutions, rather than considering a smaller company. One advantage that Progress/Savvion have at this point in time is that the acquisition is actually closing today (or later this week), whereas IBM/Lombardi went the pre-acquisition announcement route, and will endure several months of limbo before the deal closes. [Update: I’ve received a few tweets and emails indicating that the IBM/Lombardi close will happen very soon, possibly around February 1st, although I haven’t heard a final date. My “several months” was based on past experience.]

I had an early morning call with Dr. John Bates (CTO of Progress) and Dr. Ketabchi (CEO of Savvion), but a few people obviously had earlier time slots: Neil Ward-Dutton has already posted his initial thoughts, as has Jason Stamper. I agree with Neil that this is a smart move for Progress: a good fit of products with minimal overlap, directly addressing some of the challenges that they’re hearing from their customers in terms of achieving operational responsiveness. The existing suite of Progress products allows for determining what happened within an organization – a rear-view mirror approach – but not much that allows the organization to quickly change how they’re doing things in order to drive efficiency or respond to changing conditions. Bringing BPM into the fold allows them to change that, primarily through tying Progress’ Apama CEP with Savvion BPM, but also by leveraging the rest of the Progress SOA and ESB infrastructure, including data and application integration.

Savvion’s had a couple of internal shakeups in the past two years: in early 2008, Savvion axed contractors, most of their marketing department and some salespeople, ostensibly in order to shift towards a solution focus, although at the time I said that they could be positioning themselves for acquisition. They’ve had a strong push on their vertical solutions since that time, wherein they develop frameworks for vertical applications, then allow partners – or even customers – to built vertical solutions on those common frameworks.

Like many BPM vendors, Savvion has often sold to the technology side of organizations but have shifted focus to the business side recently. Progress is still a very technology-focused set of tools, so it will be interesting to see how well they can bring together the different marketing messages. In my conversation with him this morning, John Bates said that they’re moving towards more of a solutions-oriented approach rather than product-oriented: although this is an easier sell to the business side, it can be used to mask a number of disparate products being clumped together without much natural cohesion (cf. “IBM BPM”).

There will need to be some product integration points to be able to really sell this as an integrated suite of tools rather than a “solution” patched together with professional services. First, they need to bring together a common process modeling environment. Ditto for an event/process monitoring environment. Third, they need to consider the touchpoints within application development: although data integration and application integration will be designed using the existing Progress products, these have to be seamlessly integrated into Savvion’s process application development environment. There are likely also areas of integration at the engine level, too, but getting the developer and analyst-facing tools integrated first is key to acceptance, and therefore sales, of an integrated solution.

Another consideration will be a software-as-a-service offering: Savvion already has inroads in this with their BPO market, although they haven’t yet announced any consumer-facing SaaS products. Bates stated that Progress considers SaaS “an important paradigm”, which I would translate as “we know that we have to do it, but aren’t there yet”. Pushing BPM and CEP to mid-range and smaller companies is going to require a strong SaaS offering, as well as providing a platform for larger enterprises to use for piloting and testing.

Because the acquisition has already closed, or is closing within the next day or two, Progress and Savvion sales and partner channels are already being brought together; the same will happen soon for marketing teams. As always happens in this case, there will be some losses, but given the small degree of overlap in product functionality, they’ll probably need most of the skills from both sides to make this work. Dr. K. has stated that he’ll stay with Progress, although his role hasn’t been announced.

The BPM+CEP equation is becoming increasingly important as organizations focus on operational responsiveness, and I think that it’s particularly significant that Progress appointed Bates – formerly co-founder and CTO of Apama before their acquisition by Progress – to the CTO position during the time when they must have been negotiating to acquire Savvion. Clearly, Progress sees BPM+CEP as an important mix, too.

Disclosure: Savvion has been my client within the past year, for creating a webinar and internal strategy reports, although we have no active projects at this time.

I took some time out from sessions this afternoon to meet with Software AG’s deputy CTOs, Bjoern Brauel and Miko Matsumura, but I’m back for the last session of the day with Cory Kirspel, VP of identity risk management at ChoicePoint (a LexisNexis company), on how they have created externally-facing solutions using BPM, BAM and ESB. ChoicePoint screens and authenticates people for employment screening, insurance services and other identity-related purposes, plus does court document retrieval. There’s a fine line to walk here: companies need to protect the privacy of individuals while minimizing identify fraud.

Even though they only really do two things — credential and investigate people and businesses — they had 43+ separate applications on 12 platforms with various technologies in order to do this. Not only did that make it hard to do what they needed internally, customers were also wanting to integrate ChoicePoint’s systems directly into their own with an implementation time of only 3-4 months, and provide visibility into the processes.

They were already a Software AG customer with the legacy modernization products, so took a look at their BPM, BAM and ESB. The result is that they had better visibility, and could leverage the tools to build solutions much faster since they weren’t building everything from the ground up. He walked us through some of the application screens that they developed for use in their customers’ call centers: allow a CSR to enter some data about a caller, select a matching identity by address, verify the identity (e.g., does the SSN match the name), authenticate the caller with questions that only they could answer, then provide a pass/fall result. The overall flow and the parameters of every screen can be controlled by the customer organization, and the whole flow is driven by a process model in the BPMS which allows them to assign and track KPIs on each step in the process.

They’re also moving their own executives from the old way of keeping an eye on business — looking at historical reports — to the new way with near real-time dashboards. As well as having visibility into transaction volumes, they are also able to detect unusual situations that might indicate fraud or other situations of increased risk, and alert their customers. They found that BAM and BI were misunderstood, poorly managed and under-leveraged; these technologies could be used on legacy systems to start getting benefits even before BPM was added into the mix.

All of this allowed them to reduce the cost of ownership, which protects them in a business that competes on price, as well as offering a level of innovation and integration with their customers’ systems that their competitors are unable to achieve.

They used Software AG’s professional services, and paired each external person with an internal one in order to achieve knowledge transfer.

Not only did Oracle schedule this briefing on Canada Day, the biggest holiday in Canada, but they forced me to download the Real Player plug-in in order to participate. The good part, however, is that it was full streaming audio and video alongside the slides.

Charles Phillips, Oracle President, kicked off with a welcome and some background on Oracle, including their focus on database, middleware and applications, and how middleware is the fastest-growing of these three product pillars. He described how Oracle Fusion middleware is used both by their own applications as well as ISVs and customers implementing their own SOA initiatives.

He outlined their rationale for acquiring BEA: complementary products and architecture, internal expertise, strategic markets such as Asia, and the partner and channel ecosystem. He stated that they will continue to support BEA products under the existing support lifetimes, with no forced migration policies to move off of BEA platforms. They now consider themselves #1 in the middleware market in terms of both size and technology leadership, and Phillips gave a gentle slam to IBM for over-inflating their middleware market size by including everything but the kitchen sink in what they consider to be middleware.

The BEA developer and architect online communities will be merged into the Oracle Technology Network: Dev2Dev will be merged into the Oracle Java Developer community, and Arch2Arch will be broadened to the Oracle community.

Retaining all the BEA development centers, they now have 4,500 middleware developers; most BEA sales, consulting and support staff were also retained and integrated into the the Fusion middleware teams.

Next up was Thomas Kurian, SVP of Product Development for Fusion Middleware and BEA product directions, with a more detailed view of the Oracle middleware products and strategy. Their basic philosophy for middleware is that it’s a unified suite rather than a collection of disjoint products, it’s modular from a purchasing and deployment standpoint, and it’s standards-based and open. He started to talk about applications enabled by their products, unifying SOA, process management, business intelligence, content management and Enterprise 2.0.

They’ve categorized middleware products into 3 categories on their product roadmap (which I have reproduced here directly from Kurian’s slide:

• Strategic products
• BEA products being adopted immediately with limited re-design into Oracle Fusion middleware
• No corresponding Oracle products exist in majority of cases
• Corresponding Oracle products converge with BEA products with rapid integration over 12-18 months
• Continue and converge products
• BEA products being incrementally re-designed to integrate with Oracle Fusion middleware
• Gradual integration with existing Oracle Fusion middleware technology to broaden features with automated upgrades
• Continue development and maintenance for at least 9 years
• Maintenance products
• BEA had end-of-life’d due to limited adoption prior to Oracle M&A
• Continued maintenance with appropriate fixes for 5 years

For the “continue and converge” category, that is, of course, a bit different than “no forced migration”, but this is to be expected. My issue is with the overlap between the “strategic” category, which can include a convergence of an Oracle and a BEA product, and the “continue and converge” category, which includes products that will be converged into another product: when is a converged product considered “strategic” rather than “continue and converge”, or is this just the spin they’re putting on things so as to not freak out BEA customers who have put huge investments into a BEA product that is going to be converged into an existing Oracle product?

He went on to discuss how each individual Oracle and BEA product would be handled under this categorization. I’ve skipped the parts on development tools, transaction processing, identity management, systems management and service delivery, and gone right to their plans for the Service-Oriented Architecture products:

• Strategic:
• Oracle Data Integrator for data integration and batch ETL
• Oracle Service Bus, which unifies AquaLogic Service Bus and Oracle Enterprise Service Bus
• Oracle BPEL Process Manager for service orchestration and composite application infrastructure
• Oracle Complex Event Processor for in-memory event computation, integrated with WebLogic Event Server
• Oracle Business Activity Monitoring for dashboards to monitor business events and business process KPIs
• Continue and converge:
• BEA WL-Integration will be converged with the Oracle BPEL Process Manager
• Maintenance:
• BEA Cyclone
• BEA RFID Server

Note that the Oracle Service Bus is in the “strategic” category, but is a convergence of AL-SB and Oracle ESB, which means that customers of one of those two products (or maybe both) are not going to be happy.

Kurian stated that Oracle sees four types of business processes — system-centric, human-centric, document-centric and decision-centric (which match the Forrester divisions) — but believes that a single product/engine that can handle all of these is the way to go, since few processes fall purely into one of these four categories. They support BPEL for service orchestration and BPMN for modeling, and their plan is to converge a single platform that supports both BPEL and BPMN (I assume that he means both service orchestration and human-facing workflow). Given that, here’s their strategy for Business Process Management products:

• Strategic:
• Oracle BPA Designer for process modeling and simulation
• BEA AL-BPM Designer for iterative process modeling
• Oracle BPM, which will be the convergence of BEA AquaLogic BPM and Oracle BPEL Process Manager in a single runtime engine
• Oracle Document Capture & Imaging for document capture, imaging and document workflow with ERP integration [emphasis mine]
• Oracle Business Rules as a declarative rules engine
• Oracle Business Activity Monitoring [same as in SOA section]
• Oracle WebCenter as a process portal interface to visualize composite processes

Similar to the ESB categorization, I find the classification of the converged Oracle BPM product (BEA AL-BPM and Oracle BPEL PM) as “strategic” to be at odds with his original definition: it should be in the “continue & converge” category since the products are being converged. This convergence is not, however, unexpected: having two separate BPM platforms would just be asking for trouble. In fact, I would say that having two process modelers is also a recipe for trouble: they should look at how to converge the Oracle BPA Designer and the BEA AL-BPM Designer

In the portals and Enterprise 2.0 product area, Kurian was a bit more up-front about how WebLogic Portal and AquaLogic UI are going to be merged into the corresponding Oracle products:

• Strategic:
• Oracle Universal Content Management for content management repository, security, publishing, imaging, records and archival
• Oracle WebCenter Framework for portal development and Enterprise 2.0 services
• Oracle WebCenter Spaces & Suite as a packaged self-service portal environment with social computing services
• BEA Ensemble for lightweight REST-based portal assembly
• BEA Pathways for social interaction analytics
• Continue and converge:
• BEA WebLogic Portal will be integrated into the WebCenter framework
• BEA AquaLogic User Interaction (AL-UI) will be integrated into WebCenter Spaces & Suite
• Maintenance:
• BEA Commerce Services
• BEA Collabra

In SOA governance:

• Strategic:
• BEA AquaLogic Enterprise Repository to capture, share and manage the change of SOA artifacts throughout their lifecycle
• Oracle Service Registry for UDDI
• Oracle Web Services Manager for security and QOS policy management on services
• EM Service Level Management Pack as a management console for service level response time and availability
• EM SOA Management Pack as a management console for monitoring, tracing and change managing SOA
• Maintenance:
• BEA AquaLogic Services Manager

Kurian discussed the implications of this product strategy on Oracle Applications customers: much of this will be transparent to Oracle Applications, since many of these products form the framework on which the applications are built, but are isolated so that customizations don’t touch them. For those changes that will impact the applications, they’ll be introduced gradually. Of course, some Oracle Apps are already certified with BEA products that are now designated as strategic Oracle products.

Oracle has also simplified their middleware pricing and packaging, with products structured into 12 suites:

He summed up with their key messages:

• They have a clear, well-defined, integrated product strategy
• They are protecting and enhancing existing customer investments
• They are broadening Oracle and BEA investment in middleware
• There is a broad range of choice for customer

The entire briefing will be available soon for replay on Oracle’s website if you’re interested in seeing the full hour and 45 minutes. There’s more information about the middleware products here, and you can sign up to attend an Oracle BEA welcome event in your city.