Client-side Service Composition Using Generic Service Representative

I’m back for a second day at CASCON, attending the technical papers session focused on service oriented systems.

First of the three papers was Client-side Service Composition Using Generic Service Representative by Mehran Najafi and Kamran Sartipi of McMaster University; this concept is presented to prevent the possible privacy and bandwidth problems that can occur when data is passed to a server-side composition. This relies on a client-side stateless task service and service representative, and doing whatever processing can be done locally before resorting to a remote web service call. Using the task services approach rather than a Javascript or RIA-based approach provides more flexibility in terms of local service composition. McMaster has a big medical school, and the example that he discussed was based on clinical data, where privacy is a big concern; being able to maintain the patient data only on the client rather than having it flow through a server-side composition reduces the privacy concerns as well as improving performance.

I’ve been seen this paradigm in use in a couple of different BPM systems that provide client-side screen flow (usually in Javascript at the client or in the web tier) within a single process activity; I’ve seen this from TIBCO AMX/BPM’s Page Flow, Salesforce’s Visual Process Manager and Outsystems. Obviously, the service composition presented in the paper today is a more flexible approach, and is true client-side rather than on the web tier, but the ideas of local process management are already appearing in some BPM products.

There were some interesting questions about support for this approach on mobile platforms (possible as the mobile OS’s become more capable) and a discussion on what we’re giving up in terms of loose coupling by having a particular orchestration of multiple services bound to a single client-side activity.

CASCON Workshop: Accelerate Service Integration In Your BPM and SOA Applications

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?

TIBCO Now Roadshow: Toronto Edition (Part 2)

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.

TIBCO BPM Now and Future: iProcess, Meet ActiveMatrix BPM

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

TIBCO Product Stack and New Releases

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.

Deutsche Bank’s Wolfgang Gaertner at TUCON

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.

TIBCO Products Update

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.

TIBCO Go-To-Market Strategy and Regional Sales Update

Following the product update (which is embargoed until tomorrow), Ram Menon was up to talk about their go-to-market strategy. TIBCO has really been known as a powerhouse in the financial services in the past, but given the meltdown in the financial markets over the past two years, they’ve probably realized that this former cash cow doesn’t always stay on its feet. However, their event-based products can go way beyond that into retail pipeline management (think RFID tags on items for sale), government and many other areas; they just need to figure out how to sell into those markets. They have a number of vertical marketing messages prepped to go, but as a couple of analyst tweets pointed out, it’s a bit of a confusing message when they don’t have the applications to back it up, and the case studies are almost identical to those of IBM’s Smarter Planet, which doesn’t give them a lot of differentiation.

They have a 40-company road show planned, as well as vertical market pushes through their SI partners. In the panel of the regional sales VPs discussing what’s actually happening out there, we saw a chart of the industry verticals where financial services is the biggest single sector, but only around 25% of the total (I think – the slide went by quickly). Discussions on the panel indicated that SOA is their biggest business in the US (basic integration middleware, really, for non-intrusive implementations rather than rip-and-replace), but is still in the early stages in Asia, where messaging is the hot topic. BPM sales in the Americas typically also include SOA infrastructure, indicating that they’re leaning heavily on the value of the stack for BPM sales rather than its standalone capabilities: not sure if that’s intentional positioning, or an artifact of the product, sales force, or both. There is a lot of interest in newer ideas such as in-memory analytics: as one of the panelists put it, the customers “just get it” when you show the value proposition of reducing response time by having information available faster. It will be interesting to see how their vertical marketing efforts line up with the existing market penetration both by industry and product.

All in all, TIBCO’s branding feels a bit behind the times: Enterprise 3.0 is becoming a joke amongst the analysts attending here today (we’re tweeting about staging an intervention), and the “ending r with no preceding vowel” of tibbr is so 2006. The new TIBCOSilver brand covers all of their grid and cloud offerings, but doesn’t really make you think “cloud” when you hear the name. Like Brenda Michelson, however, I like the “Two Second Advantage” message: it’s short, memorable, and actually means something.

TIBCO’s Enterprise 3.0 Vision

Murray Rode, TIBCO’s COO, started the TIBCO analyst day with their vision and strategy. The vision: Enterprise 3.0. Srsly. They seem to have co-opted the Enterprise 1.0/2.0 terms to mean what they want it to mean rather than the more accepted views: they define Enterprise 2.0, for example, as everything from the 80’s to 2009, including client-server. I don’t mean to sound negative, but that’s not what we mean by Enterprise 2.0 these days, and whoever came up with that idea for their branding has just made them sound completely out of touch. Their spectrum goes from Enterprise 1.0 data processing from the 60’s to the 80’s, Enterprise 2.0 client-server, and Enterprise 3.0 predictive analytics and processing: using in-memory data grids rather than databases, and based more on events than transactions.

Putting aside the silliness of the term Enterprise 3.0, I like their “Two Second Advantage” tagline: when fast processing and analysis of events can make a competitive difference. Their infrastructure platform has three pieces:

  • Connect (SOA), fed by messaging and data grids
  • Analyze and optimize
  • Automate (BPM)

They can used the cloud as a deployment mechanism for scalability, although that’s just an option. In addition to the usual infrastructure platform, however, they’re also following the lead of many other vendors by pushing out vertical solutions.

We’re about to head into the product announcements, which are embargoed until tomorrow, so things might get quiet for a while, although I’m sure that there will be lots of conversation around the whole Enterprise 3.0 term.