Enterprise 2.0: Enterprise Mashups Technical Deep-Dive

Nicole Carrier of IBM, who was on the enterprise mashups panel yesterday, returned this morning to dig into more of the details behind mashups, particularly as implemented on their platform, Lotus Mashups (which I believe started life as QEDwiki). She started by defining mashups and widgets, then outlined what makes a mashup unique in terms of scope, process, users and technology. There are some key differences between mashups on the consumer internet and within the enterprise, however: enterprise mashups typically need to access enterprise systems, which might need to be unlocked/wrapped for accessibility (e.g., create widgets and feeds to access that data or functionality), and enterprise assets available for mashup need to be cataloged in some way.

She walked us through building a mashup with Lotus Mashups, pulling in widgets and feeds from various data sources as well as Google gadgets and arranging them on a page. More than just a portal interface, this environment allows you to create “wiring” between the objects on the page in order to allow data or selections in one widget to impact or filter another one. Once created, pages can be shared with others by publishing in a catalog, and other users can be given read-only or edit permissions on pages.

Joel Farrell, the chief architect of IBM’s InfoSphere MashupHub, joined Carrier to show how some of the data sources are discovered and/or created for use in mashups, and how they’re shared with others.

This quickly turned into an in-depth review of how to use the IBM mashup products, and a lot of the audience started to bail out. Including me.

Enterprise 2.0: Enterprise Mashups Panel

David Berlind hosted a panel on enterprise mashups, with Michalene Todd of Serena, Nicole Carrier of IBM, Lauren Cooney of Microsoft (recently of IBM) and Charlotte Goldsbery of Denodo. I was supposed to moderate this panel, but when the vendors started treating it like a sponsored panel by switching out participants, and the conference organizers refused to kick in for any of my expenses (in an outrageously biased policy where they pay some speakers’ expenses but not others depending on who you complain to), I decided that it wasn’t worth the hassle and bowed out. David’s a great moderator and knows a lot about mashups, but ultimately, I think that he allowed this panel to be hijacked by the vendors, with the exception of Lauren, who speaks her own mind rather than the Microsoft party line. Serena totally screwed up on this one by bumping Kelly Shaw off the panel — a panel that’s described as being full of “girl uber-geeks” — and replacing her with a non-technical corporate marketing person who was out of her depth, and Denodo didn’t do much better by putting in a self-described salesperson.

There was an interesting discussion about how data is exposed to be consumed by mashups, e.g., ATOM/RSS, and the implications with respect to the security of the underlying data, the ability of mashup platforms to consume that data, and how to appropriately encapsulate data so that a non-technical person creating a mashup can’t do evil things to the underlying data source, like doing a search on a non-indexed field in a large database table. You need to consider the interfaces for accessing the data and services: SOAP, RESTful services, web services, etc.

Realistically, business users still can’t do mashups, in spite of what the vendors tell you: there’s just too much technical stuff that they need to know in order to do mashups still. Although it’s easy to drag and drop things within a graphical environment, that’s not the issue: it’s understanding the data sources and their interactions that’s critical. The real target for many of the mashup platforms, as I’ve stated many times before, is for the semi-technical types within business units who are now creating end-user computing applications using Excel, Access and other readily-available tools. I don’t think that’s anything to be ashamed of, and striving for the goal of allowing any business user to do mashups is unrealistic. I was at a client site recently, and of all the claims adjusters and their managers who I talked with there, I can’t imagine that a single one of them would be inclined to even try to create a mashup or — without intending any insult to them in any way — have the skills to do so. Likely the closest that business users will come to building mashups will be configuring their own personalized portal within an existing framework, similar to iGoogle; a proper mashup framework may also allow the portal widgets/gadgets to interact, such as using selections in one widget as a filter for another on the same page. A lot of the good business applications, the things that are now being handled by other MS-Office-based end-user applications, are spreadsheet-like in nature; data visualization is a critical part of mashups, but there’s rarely a Google map involved.

Another issue is whether mashups are ready for prime time: are they really intended to be deployed as production applications, or are they just an easy-to-use prototyping environment? What about underlying data sources that aren’t under your control (like Google Maps) in terms of SLAs and fault tolerance? Although internal systems can also have failures, at least you have some degree of control over your own IT resources in terms of high availability of applications and their data sources, and any critical external services that you use — whether in a mashup or any other type of application — has to come from a company with whom you can nail down a believable SLA.

Enterprise 2.0: IBM’s Social Networking Directions

I had a great opportunity today at lunch for a one-hour session with Jeff Schick, VP of social networking at IBM, and Joan DiMicco who came to IBM after doing media studies at MIT and is one of the key people behind Beehive. There were only seven of us plus these two quite technical IBM’ers in a suite upstairs in the hotel, giving us an opportunity to have an informal roundtable discussion: a sort of social networking nerd heaven.

We started out with a discussion about Beehive — a sort of enterprise Facebook that IBM has developed for internal use — which has gained 33,000 users in less than a year since internal release. That’s 10% of IBM’s workforce, which is a pretty significant adoption rate considering that it’s not required for creating any sort of work product. Beehive is purely a social platform, not a work platform, to allow IBM employees to create social and personal connections. I have friends within IBM, mostly former FileNet people who were absorbed during the acquisition, and one of them speaks glowingly of Beehive as a way to find other people with similar interests to her in order to find people whom with to collaborate.

Schick said that people are starting to be freer with the information that they share on Beehive, and we had a discussion about whether this additional degree of sharing tended to increase the camaraderie amongst co-workers. They’re seeing a blending of personal and professional information published on Beehive, which tends to enrich the communication between people since you have a more multi-faceted view of someone who you’ve met only online. He also talked about adding social concepts to business applications, for example, being able to link directly from someone’s name on a specific business transaction to other information that they have shared, such as shared files or profile information.

Jeffrey Walker of Atlassian was also in attendance, and he asked about the issue of having multiple social networks and how he really just wants a filtered version of Facebook for the enterprise, not yet another social platform. DiMicco responded that people who do external social networking in addition to Beehive tend to create very different profiles in, for example, Facebook and Beehive: they might post photos of their kids within Beehive but not in an open Facebook photo album. In other words, they use Beehive and other social networks for different reasons. Schick added that you can have links to your other social network profiles on your Beehive profile, so if you already have a lot set up elsewhere, you can link to it rather that replicate it, but that (in my opinion) devalues it somewhat since you don’t have federated searching across all of someone’s profiles if they choose to keep only a minimum in Beehive. Later, we heard about Fringe, a sort of internal FriendFeed to aggregate all of the internal and external information sources to provide some level of federated search, which does ease some of those concerns.

The interesting thing about IBM and Enterprise 2.0 is that IBM definitely eats their own dogfood; in fact, they eat it long before they consider serving it up to their customers. A few years ago, I heard about IBM’s Dogear (a social bookmarking tool, like Del.icio.us for the enterprise) at a Toronto-based Enterprise Camp; at the time, I tried to dig around and figure out when it would become available as a product, but they used it extensively internally before finally productizing it. Similarly, there are plans to productize Beehive and Fringe as behind-the-firewall social applications for enterprises under the Lotus Connections brand, now that they’ve had a chance to polish off the rough edges through their own internal use. These aren’t just for big enterprises: some smaller companies are using them as well.

The interesting opportunity is that IBM puts a stamp of credibility on the whole social networking space by offering applications to enterprises, which will undoubtedly benefit other social application vendors as the tide rises. They also see (rightly) that their social technology is far ahead of Microsoft’s, although it is being positioned against SharePoint in some cases. Schick sees content management as a key part of collaboration, and integration between the Lotus Connections products and ECM platforms such as FileNet, Documentum and SharePoint will allow them to make that even stronger.

Oracle-BEA versus IBM-FileNet: the Borg versus death by a thousand cuts

Almost two years ago, I reported on the IBM acquisition of FileNet, wherein I quoted their plan to “integrate IBM’s BPM and SOA technologies with the FileNet platform”. I interpreted this to mean that FileNet BPM could finally get separated from its document-centric chains, and become the product that it should have been years ago. Just as Jessica Rabbit said “I’m not bad, I’m just drawn that way”, the FileNet BPM wasn’t (isn’t) document-centric, it’s just marketed that way. As the former director of e-business evangelism for FileNet in 2000-1 when they were launching this generation of the BPM product, I had some idea of what I was talking about — I saw that 40% of the BPM installations in some countries did not involve documents at all, and that this was due to the local sales and marketing messages and techniques rather than any inherently different BPM requirements between countries. So several years after I left FileNet, when the acquisition occurred and I saw that initial press release, I imagined that the best possible thing would be if the BPM product were to be separated out and made part of the IBM WebSphere suite, in order to flesh out the badly-needed human-facing workflow side of things over there. I realized that would mean some major surgery on the product, but a stronger unified BPM suite would emerge from that.

A few days later, an analyst call with IBM set me straight on that: the GM of the IBM Information Management unit that would be absorbing FileNet referred to FileNet’s BPM as “content-centric”. Uh-oh. I knew that couldn’t mean anything good for the product. I still have a lot of friends inside IBM-FileNet, and at first, it seemed like they were being allowed some degree of autonomy. Then, they gradually started being pulled into the “IBM way”, and a lot of people started getting unhappy, and many eventually left. There were few explicit purges, except for some redundant administration, but that doesn’t mean that there weren’t losses.

Recently, IBM announced its grand plan for BPM; Bruce Silver covered it here, describing how they plan to bring together process and content:

[T]he steps that involve content operations (e.g. adding/revising/securing documents) are done by a FileNet P8 process, which is invoked via WSDL as a subprocess in the end-to-end WebSphere process.

In other words, after more than a year, my premonition about the FileNet BPM product was realized, and it became — from a marketing standpoint — a shadow of its former self. I’m sure that customers using FileNet BPM for end-to-end processes (which IBM thinks are more suitable for WebSphere Process Server) cringed as they see the future of their installed product atrophy. I can only imagine the impact on the (still fairly segregated) sales team: one day, they’re selling FileNet BPM as a full BPM solution, the next day, it’s a document-centric subprocess handler, to be called from WPS. In much the same way that other BPEL vendors handle human-facing tasks as second-class citizen, calling a subsystem using WSDL to manage them, IBM is demoting FileNet BPM to the same realm. Although I predicted this right from the first analyst call, it doesn’t give me much satisfaction when I think about what it could have been.

The current monster acquisition in this space is Oracle and BEA, and it’s interesting to see the contrast in acquisition styles. Unlike the death-from-a-thousand-cuts method inflicted by IBM on FileNet, Oracle is more like the Borg: BEA is being assimilated, and fast. The acquisition — from the first rejected offer last October to the final accepted offer this January — was completed in late April, less than two weeks before the BEA Participate user conference. At the conference, I found that many of my BEA acquaintances were not staying on with Oracle; many others have announced that they’re leaving since then as well.

The Register reported yesterday on how Oracle is dismantling the AquaLogic product line: the AquaLogic web products (portals and Web 2.0) and, it appears, the WebLogic products will go one direction (hypothesized by the Register to be the Stellent team), with some rationalization of AquaLogic and WebLogic finally occurring; AquaLogic BPM will be moved under the Fusion middleware team. I haven’t dealt much with the WebLogic side of BEA, but when I dared to suggest that AquaLogic Pages could be used as a lightweight replacement for WebLogic Portal, I was “corrected” on the official party line. Given my confusion over this, I have to assume that some part of the market has also been confused over why BEA offers two different portal products. If it takes Oracle’s firm hand to finally merge them, that’s a good thing.

Oracle is doing exactly what I thought IBM should have done with FileNet: split up the product where it made sense and merge those pieces into similar teams that already exist, rather than try to maintain an intact semi-autonomous unit and brand, then gradually re-jig the product, potentially misleading customers about the final outcome.

As a member of the Enterprise Irregulars, I’ve been invited to a dinner hosted by Oracle next week at the Enterprise 2.0 conference; it will be interesting to see if BEA is so completely assimilated that the name isn’t even uttered.

IBM tops AIM market, but what of BPM?

A press release this week from IBM announces that a preliminary Gartner report on application integration/middleware (AIM) and portal software has crowned IBM as the market leader based on 2004 licence revenue. Their figures put IBM’s share at around 37% of the worldwide market, with chief rivals BEA, Oracle and Microsoft trailing far behind at 7.2%, 4.4% and 4.3%, respectively. The full report is due out at next week’s Application Integration and Web Services Summit.

As you poke around in the data, however, you find out that the number is made up of several products, including application servers (where they compete with BEA), integration software (where they compete with TIBCO, Microsoft BizTalk and webMethods) and portals (where they compete with Microsoft SharePoint). In fact, I suspect that anything that carries the “WebSphere” brand is considered part of their AIM stable, including ongoing licence fees for tons of pre-WebSphere-era MQSeries installations connecting ancient IBM mainframes using proprietary protocols. If you check out IBM’s software product list, there’s a whole lot of WebSphere going on, and it didn’t all start under that brand. In fact, I remember when what is now WebSphere MQ Workflow was rebranded from “FlowMark” to “MQSeries Workflow”, prior to its re-rebranding as WebSphere a year or so ago. Since MQSeries was the hot new brand at the time of the first rebranding, it was seen as an attempt to “standardize by branding”, although FlowMark wasn’t even based on MQSeries until much later.

From a BPM standpoint, the biggest complaint that I have about IBM’s products is the apparently piecemeal strategy. In recent years, we’ve seen a number of products put forward by IBM as BPM and/or workflow: WebSphere MQ Workflow (a somewhat clumsy workflow product that never really developed into a cohesive contender), Content Manager’s Document Routing (a very simple routing capability for document-based workflows), Lotus Workflow (I’m not even going there), Advanced Workflow (now apparently being sunsetted), and the latest entrant, WebSphere Business Integration.

WBI, previously called WebSphere Process Choreographer, is based on the CrossWorlds EAI product acquired by IBM: just type in www.crossworlds.com and see where it takes you. Because of that origin, it’s coming from the EAI space, and my concern is that the product focus will remain on integrating systems and will never fully develop the human-facing functionality, including business-focussed tools for modelling, simulation and analytics. Gartner’s 2004 magic quadrant for pure-play BPM doesn’t mention any of the IBM products, although they did show up in the 2004 magic quadrant for business process analysis due to the Holosofx acquisition.

If this is going to be the next-generation BPM product, IBM needs to stop spending so much time listening to the IT departments (who get far too excited about EAI) and spend more time listening to the business departments in order to develop the human-facing components that they need to move into the pure-play BPM market. At the very least, they need to perform a mercy killing on MQ Workflow as soon as possible to reduce customer confusion and focus their efforts on a single BPM product offering.

Of course, there’s always going to be some platform limitations to WBI: it’s going to require WebSphere Application Server and WebSphere MQ. Given the market penetration of WAS and MQ in large organizations, however, I don’t see that as a problem; the opportunity to grab a huge BPM market share is theirs to blow.