Hot(ish) on the heels of our first online event (“2010: time to define your Cloud strategy. Are you ready?” – sponsored by Google Enterprise) – we’ve just started to plan our second online “MWD insights” event.

The topic will be “Reinventing Customer Experiences With BPM“, and it’s set to be launched on June 28.

We’re always looking to move forward and improve in everything we do, so we’re making a couple of tweaks to the format of this event in the hope of making this event even more successful than our Cloud Computing event.

Most importantly, this time we’re complementing the initial keynote session with a set of really cool one-on-one case study interviews which I’ll be conducting with people who’ve used BPM approaches and technology to deliver tangible customer experience improvements. But there’s something else we want to do with this event, and that’s to make its quality and relevance completely bulletproof – and that’s where you come in, dear reader.

Below I’ve laid out our current thinking about how the event content will be structured. I’d really love to hear what you think about what we’re planning, and if you have the time to suggest an alteration or just give us a thumbs-up that would be absolutely fantastic. If I hear that what we’re planning is off the mark and looks like not being interesting to people, we’ll make changes.

We’re really excited about building up an ongoing programme of events like this, and we want to make them absolutely top-notch. We wouldn’t want to deliver anything less! The more advance feedback we can get from people who are interested in the topic, the better the event will be.

By the way, one thing we’re *not* changing is that access to this event will be free to all our 3,000 (and growing) Guest Pass subscribers. (Yes, in case you didn’t know, you can sign up for Guest Pass access for free too).

Here’s our current thinking about the event content and structure.

Keynote: Neil Ward-Dutton, Research Director – “Applying BPM to customer experiences – opportunities, approaches and challenges”
The keynote will focus on:

• Why organisations are investing in process change and improvement today at the edge of the organisation – looking at previous waves of process improvement, business conditions, technology change, etc.
• Typical symptoms of poor management or attention paid to delivery of customer experience excellence.
• Why packaged application investments often fail to deliver customer experience improvement results – looking at ‘outside in’ views of an organisation vs. ‘inside out’ views, etc.
• How BPM initiatives and technologies can help drive customer experience improvement – looking at aspects of the business case for investment.
• Examining, at a high level, an approach for uncovering customer experience improvement opportunities.

The keynote will be followed by a set of enterprise case studies (number TBC).

Each case study interview will be carried out by Neil Ward-Dutton, and will last approximately 10-15 minutes. The interview dialogue will be supported by visuals supporting key points of the conversation. Key questions we expect to explore with enterprise representatives include:

• What was the business catalyst for your BPM implementation work to improve the customer experience?
• Who had to be convinced that the path you took was the right one, and how did you make the investment case?
• How did you get started with the work – did you start on a particular problem, and if so, how did you identify it?
• Have there been any cultural, organisational (training etc), governance or technology issues along the way? If so how did you resolve them?
• What has been the outcome so far and what are your plans going forward?

Lastly – if you’d like to find out about how to submit a suggestion for a case study to include, please let me know! Alternatively if you’d like to find out about sponsorship opportunities for this event, please contact our Account Manager Denise Bradley.

Please let me know what you think!

Earlier this year IBM (and reportedly) HP both took Sun Microsystems out for first dates but neither decided to take things any further (though IBM arguably got to second base). Now it seems Oracle is prepared to go the whole way with the iconic dot.com technology brand. Are we looking at a beautiful wedding on the beach in Maui, or a drunken fumble in a dark alley followed by recriminations, tears and vengeful fathers?

It’s telling that in this era of instant communication I feel under pressure to say something incisive and erudite, even though it’s only a few hours since the acquisition was announced and hundreds of other commentators have heard the same conference calls and read the same press releases. So what is there to say beyond “blimey, I never saw that coming”? (Because it’s true, I didn’t – and I never would have put Oracle on the list if I’d been asked to draw one up). I’ll take a deep breath.

I think the most telling take-away I got from all the materials available from the two parties today was the balance of information about earnings, assets and market shares vs. information about shared vision and customer value (there was a bit of the latter in evidence from Jonathan Schwartz and Chuck Philips, but it sounded distinctly lacking in energy). By contrast Oracle CFO Safra Catz was by far the most animated exec on the call, particularly as she explained how Sun would contribute more operating income in its first year as part of Oracle ($1.5bn) than BEA and PeopleSoft did combined (an interesting side note: Oracle paid more for BEA than it intends to for Sun, despite that tasty financial upside. Aren’t stock markets fantastic).

I wouldn’t go as far as Vinnie Mirchandani (executive summary: Oracle is just after making a quick buck and has a poor track record of sustaining innovation following its acquisitions), but I remain to be convinced as to whether this has any positive implications for customers of either Oracle or Sun. You could argue that with Oracle as banker, Sun customers can now have more confidence about the future of their technology choices: but squeezing out $1.5bn operating income out of a company that’s only occasionally managed to turn any kind of a profit in the recent past is going to mean quite a lot of “shrinkage” – the kind of shrinkage that cuts much deeper than the back office. So a future rich in systems innovation is far from certain, at least in the short-to-medium term. And in the current environment, with data center economics shifting so fast, the short-to-medium term is likely more than enough time for Sun’s customers’ heads to be turned towards its competitors. This is a very fast-moving marketplace, and innovation has to be in evidence for any vendor wanting to avoid a slippery slope towards the Systems Supplier Graveyard.

Of course, Oracle’s intention could be (as RedMonk’s Cote among others have noted) to strip out Sun’s hardware and sell it off – instead focusing on the software assets (Java, primarily). In which case it will hardly care about what happens to Sun’s systems customers.

It’s important to be balanced though.

With my optimistic hat on, I can see that there are nice things that could come out of this. Sun could effectively tick a box that Oracle probably has on a strategy document somewhere called “Cloud Computing strategy”; despite Larry Ellison’s public dismissal of the hype, we all know that makes sense for Oracle to continue to move forward from its current position on Cloud. Sun’s virtualisation, datacenter-in-a-box and nascent Cloud platform offerings, combined with the “integrated apps-to-disk” proposition Oracle and Sun talked briefly about today, could sow the seeds of a story that could bridge the interests of mainstream IT shops, leading-edge startups, ISVs and outsourcing providers.

At the moment, it’s too early to tell – we’ll have to wait until the summer, when the deal closes, to cast the runes again. Until then, let’s get on with our lives. Now, what’s on YouTube today?

A couple of months back I had a brief Twitter exchange with David Bressler of Progress Software (@djbressler), following a comment I’d seen from Judith Hurwitz (@jhurwitz) at Progress’ analyst day regarding the lack of brand awareness that the company has out there in industry. What I said was: “Progress is a bit like Unilever – top-level brand is vanilla, sub-brands have chops”. What I meant is that these days, there’s little knowledge of what Progress does (a typical response is either “Who?” or possibly “oh, they used to sell a 4GL and a database in the 1990s, didn’t they”) – whereas there’s much more recognition of brands like Sonic (SOA infrastructure), Actional (SOA management / governance), IONA (middleware, SOA infrastructure), Apama (event processing), DataXtend (data integration) and DataDirect (data connectivity, legacy application integration).

David replied that Progress is a technology company’s company – which is absolutely correct: Progress has a long and successful history of providing a platform for other software vendors to embed in their application offerings. And he followed up with this blog entry, saying “We’d love for the Progress brand to have some chops, and we’re trying but it’s not trivial.”

Well, for a few weeks I’d been meaning to write a blog post of my own exploring this – but in the general headlong rush that we’ve been experiencing so far this year, I’d forgotten to write that post. When I saw today’s news that there’s been a change at the top at Progress, though, I was finally prompted to write some thoughts down. (Thanks for the pointer Miko).

The main thought in my head all those weeks ago was that it’s all very well for Progress to be a bit like Unilever – with the sub-brands (Sonic, Actional, Apama, DataDirect, and so on) having much more visibility in industry than the parent brand – as long as the company doesn’t want to start pulling together broader IT and business infrastructure propositions that tie together pieces from the different brands. Unilever is well-known for owning a vast portfolio of products, many of which actually compete with others in the portfolio (Dove v Lux; or Persil v Surf, for example. The invisibility of the parent brand is fine for Unilever, but it’s bad news for Progress if it wants to really make the most of its potential within enterprises (by cross-selling or bundling its products to help customers with broader opportunities, for example).

So this is the point where the company has to undergo a pretty radical shift. As reported in PCWorld, the new Progress Software CEO (formerly the COO) has established a target of doubling the company’s annual revenue to around $1bn, by “reorienting sales towards multi-product suites, as well as aiming marketing messages more at business executives than IT workers” – that is, precisely what it’s not currently suited to doing.

This goal makes absolute sense, and in fact it has made sense for ages. The majority of the markets where Progress’ brands play are growth markets where there’s real opportunity, right now; and what’s more, the combination of the offerings could have real power, too.

The required shift will be no picnic, but there are worse times for Progress to be trying to make it happen. There’s a new man at the top with a new broom, no doubt; and what’s more, there’s still a small window of opportunity open for another medium-to-large-sized specialist infrastructure software vendor to pick up business, following BEA’s acquisition by Oracle a few months back. TIBCO and Software AG have recently been making much of BEA’s disappearance as an “independent” infrastructure software vendor, and it’s surely no coincidence that both these companies also have aspirations to reach $1bn in annual revenues (Software AG has been particularly vocal about this of late). Progress has long had the potential to join Software AG and TIBCO as a serious contender for enterprises wanting to avoid getting into bed with the MISO pack (Microsoft, IBM, SAP or Oracle) for whatever reason, but until now it just never seemed to be able to be bothered to do what was necessary.

With a new CEO at the top, it’ll be fascinating to see whether Progress can move up a gear. If it succeeds, then enterprises wanting to avoid giving too much technology supplier power to the MISO pack may well have a new choice – and in a market where consolidation has recently been rampant, more choice would be refreshing for everyone.

I’ve been spending a fair bit of time this week talking to a journalist I’ve known for years, Danny Bradbury, for a series of features he’s writing on the middleware strategies of some of the big enterprise software vendors.

After our first chat, something suddenly struck me (probably very belatedly): when middleware is talked about and sold today, what is being discussed is completely different to the stuff I first learned and wrote about in the mid 1990s. The difference is all to do with the meaning of the word “middle”.

In the mid 1990s, “middle” meant “the gaps between applications and software components”. Middleware was technology you turned to in order to try to build distributed systems: we were faced with transaction processing middleware, database middleware, object middleware, and so on – all different forms of middleware optimised for supporting different kinds of distributed software development paradigms. Middleware was a technological concept.

But with the birth of the application server concept in the late 1990s, which consolidated a lot of the popular distributed computing patterns of the time, together with the rise of web protocols and open-source alternatives to commercial web infrastructure, the idea of “middleware” changed fundamentally.

Now, when you see most of the talk about “middleware”, “middle” means “the gap in a technology stack between an operating system and packaged applications”. Middleware is now defined largely by vendors from a software product marketing perspective, rather than by customers from a technology perspective. Consider the portfolios of IBM, TIBCO, SAP, Oracle: they all talk about “middleware stacks”, but these things include process management, content management, master data management, and business intelligence tools – and sometimes even DBMSs. [As a side-note, Microsoft is interesting because to an extent, it's gone in the opposite direction - building more and more "traditional middleware" capability and avoiding talking up the big stack.]

Why is the changing nature of middleware conversations important? Because, as I’ve mentioned before, the people and organisations that influence the language we use to describe things often end up in the best position to control what gets bought, by whom. By redefining “middleware” as being about ever-growing portfolios of infrastructure software, the biggest software vendors we have end up crowding out the propositions of smaller specialists.

So – should we reclaim “middleware”, or should we just let it die a natural death?

Earlier this week I attended an IBM press and analyst summit on the topic of “Business Event Processing”. To coincide with this, the company made some announcements on its “BEP leadership”, with over 3700 “BEP customers”. This is fairly early days in IBM’s attempts to tell a coherent story about what it’s doing in event processing, although it’s been helping customers for many years prior to the January 2008 acquisition of AptSoft (which catalysed IBM’s use of the BEP term). However the company isn’t doing itself any favours with language like this: it’s all too easy for it to come across as disingenuous, or at the very least the result of a significant amount of Vaseline being spread on a camera lens.

Why? Well, it’s a question of boundaries and definitions. Specifically, IBM defines BEP in the following way: (1) an event is “something that happens”; (2) a business event is “an event that has relevance to the business”; and (3) Business Event Processing (BEP) is “the correlation of heterogeneous events in order to achieve smarter business outcomes”.

BEP is a term which has come about primarily through IBM’s own marketing since the AptSoft acquisition. But a similar term, Complex Event Processing (CEP), preceded this by some significant time (it was popularised by David Luckham‘s 2002 book The Power of Events). With a nod to the debate that still simmers about what the CEP term should really signify (is it the processing of compound/aggregated, or “complex” events – or is it application of “complex processing” to events?), IBM’s definition of BEP is very close indeed to what seems to be the pre-eminent definition of CEP. This is no accident: on a call to discuss the AptSoft acquisition, IBM’s Sandy Carter explicitly called out her interest in trying to rename the “CEP category”.

All’s fair in love and software marketing, I suppose, even when it risks leaving everyone confused (most people are still trying to get their heads around CEP). The real problem I have with this, though, that it’s not only a simple renaming that’s at work here. When IBM then goes on to talk about the event processing work it’s doing, it tells a story that’s much broader than the AptSoft technology area, and also broader than what most event-processing folks would think of when they think of CEP. Likewise when IBM refers to “3700 customers” these aren’t AptSoft customers (apart from a tiny minority of them). As well as focusing on WebSphere Business Events (the former AptSoft technology) IBM’s view of BEP encompasses event-processing capabilities that exist in Tivoli/NetCool systems and network management products, WebSphere MQ Event Broker and MQ Low Latency Messaging, a new stream-based event processing platform called InfoSphere Streams (formerly “System S“), the SolidDB in-memory database, and many other bits and pieces as well.

In short, it looks like IBM’s taking a term that only in January 2008 it used to describe a “business friendly” event processing toolset (the AptSoft technology), and is now instead applying it to any software technology that IBM offers which involves the processing of events. A cynic would say it’s got a big plumbers’ canvas toolbag marked “BEP”, and is shoving as much into it as possible.

Now the intention of this post isn’t just to bash IBM for attempting to subvert the CEP concept. The reason I don’t want to leave things here is that there’s more to what IBM’s doing than meets the eye.

As the press and analyst day unfolded, it became clear (not through the presentations from the IBM execs, tellingly, but through Q&A and one-on-one meetings) that behind the scenes, IBM is actually trying to do something pretty interesting. It’s got a big kit-bag of event-processing technologies, yes – but behind this, it’s working to put together a common event processing technology framework that will allow its individual technology components to be assembled in different combinations to support different types of business and IT requirements. So, rather than having separate event processing stovepipes in the WebSphere, InfoSphere and Tivoli software portfolios, together with assorted miscellaneous other components, it’s enabling all of these distinct efforts to cross-fertilize. One of the first outcomes of this work is the snappily-named WebSphere Business Events eXtreme Scale, which marries the former AptSoft technology (never marketed as a platform for high-volume processing) to the WebSphere eXtreme Scale platform.

With this in mind, I think it’s a bit of a shame if IBM sticks to referring to its overall event processing architecture effort as BEP. BEP, like CEP and one of my other favourites Composite Application Development, is a “how” name – it says more about a method than its outcome. Or, in other words, although it might appeal to geeks, it says nothing about why anyone would invest in it. What would work much better, in my opinion, would be for IBM to complement (or even replace) its discussions about BEP with discussions more centred around a “what” idea that is more about the business value of event processing – what all these technologies, and the framework being built, actually enable customers to achieve. If IBM hadn’t already walked away from the term, I’d suggest something like “on-demand business”… but seeing as that’s verboten these days, I’ll keep my thinking cap on. Perhaps “event-driven business”?

Putting all the vendor marketing stuff to one side, what does all this mean for enterprises? First, try and look behind the cynical BEP and CEP marketing stuff. IBM might be mis-stepping in its marketing, but you can be sure that it’s serious about building a set of technology offerings to help customers with a variety of event-processing related problems and opportunities. Second, although algorithmic trading and other capital markets applications are where most of the technology market activity in this space has been over the past year or so, try and take a broader perspective of event processing and how it might offer value. Event processing is a useful computing approach, even when the event volumes aren’t colossal, or the processing requirement isn’t near-real-time, or the processing requirement isn’t highly complex.

Lastly: watch out for a free Guest Pass report we’ll be publishing on event processing before Christmas, where we’ll attempt to unpick the different scenarios and technology requirements in play.

A few days ago Matt Asay wrote a piece on Linux’s use on Wall Street in his “Open Road” blog. He recounted how one of the MDs from Bank of New York Mellon saw “open source as the foundation of choice for their innovation”. He goes on to say that this runs counter to prevailing opinion, which positions Linux (and open-source software technology in general) as a commoditising force.

It’s not as straightforward as he makes out, though: in truth, Linux is BOTH a platform for innovation, and a commoditising force. It’s always, in fact, been this way: there’s one community that is most attracted to the fact that Linux code can be tweaked and reconfigured in extreme ways (you just have to look to Google’s widely-cited work here to see what I mean). And there’s another community, less vocal but much larger in number, which is much more attracted to the fact that open-source software tends to be “free” (of charge) than it is to the ability to mess with the source code.

So Linux (like many other open-source software technologies) has two markets and two demand curves associated with it: one is populated by companies with leading edge technology use requirements; and the other is populated by companies who want to align their technology expenditure much more with the business value they receive from it, and see the lack of an up-front license fee associated with open-source software as a perfect route to do this.

When looking at technologies like this and commenting on their role in industry, we need to be careful which market we’re really referring to.

I was chatting to a friend who’s a top-notch Java developer over the weekend: we were shooting the breeze about Groovy, Rails, Spring, Hibernate and various other Things That Get People Excited (let’s call them TTGPEs), and discussing how far they were likely to penetrate into your average IT shop. “Why do so many people insist on following the J2EE application model and associated patterns so slavishly,” said my friend, “when they’re so plainly not the right tool for the job in so many scenarios?”

“The thing that you never get from reading development books,” I said – he’d just finished showing me a book on Groovy – “is how difficult it can be for your average IT shop to get on board with a new development technology, when you take commercial considerations into account. You can see from looking at code samples that language A is more compact or give you more productivity than language B. But what you can’t see is the bigger picture of costs and risks.”

I remembered a post of Steve Jones’ I’d seen a couple of months back about development as a discipline for the masses – and also this one from Jeff Schneider about the value of SOA governance.

You see, the problem for your average IT shop in taking on TTGPEs is that even when they have been demonstrated to save time and/or money, there are two real barriers to adoption. Both barriers exist primarily because these shops have no option but to see development resources as a commodity.

First, within an average IT shop – think of one within a small utility provider or a local government – the business can’t make a case for paying top whack to hire the very best developers. So, they have to shoot for the “mass market” of developers – hopefully capable and dependable, but not likely to be stellar performers. They also don’t have a lot of time or money available for recruiting, so they tend to minimise the complexity of interviewing as far as possible – asking for “industry standard”, well-recognised skills. Unless they can find TTGPE skills within that “mass market”, they’re not going to consider bringing those skills into the organisation. J2EE skills are now mass-market skills. Groovy skills aren’t (yet).

Second, within such an IT shop, work tends to follow those same “industry standards”, because the risk of doing TTGPEs is that if people leave or get sick, and new people have to be brought in, they have to be able to get new resources up-and-running quickly. If new staff have to spend weeks or months trying to re-engineer glamorous but unknown technology before they can continue a project, that’s a huge, ugly cost.

Regardless of whether J2EE is increasingly being revealed to be more like a VW crossed with a tractor than a Ferrari, then, the truth is that most people have little choice, for now, but to stick with it and make the best of things.

Most readers will by now be familiar with the recent sparring between Oracle and BEA (just see our del.icio.us links over the past days to get an update if you’re not up to speed). There’s been plenty said about this already of course, but I thought it would be fun to look past the “industry insider” angle and consider what this piece of theatre says about the IT industry and what it means for the organisations that this industry sells to.

The original (publicly stated, but unsolicited) offer to purchase BEA came from Oracle on October 12th. It was surely no coincidence that after years of alleged courting by Oracle, the offer finally came once “activist investor” Carl Icahn had acquired a significant position as a BEA shareholder. Icahn started his BEA investment run-up in early September, and now owns around 13% of the stock. As part of his initial disclosure of stock purchase, Icahn’s company stated that the purpose was to attempt to get BEA to sell itself in order to deliver more value to shareholders.

[Just to put some numbers on that "value", as mentioned here, if BEA had sold to Oracle for $17 a share, Icahn would have stood to make a $217.1m profit (that's roughly a 33% return on his $663.8m investment) in just a couple of months.]

Of course it’s fair to argue that BEA has sometimes failed to capitalise on technology and business trends in ways that it might have done, and as a result its technology could deliver more. Icahn does have a point when he says that ISVs in general face an uncertain future as business models in the ICT industry change and value flows increasingly away from hardware and software (catalysed by open source and commodity hardware) and towards services.

But is Icahn’s prescription for BEA (a sale) the right one? This article appraises Icahn’s record and on that reading, he’s certainly been far from infallible. For one minute, let’s look past shareholder value in isolation, and consider the business that BEA is in.

BEA is a company that’s built its business on being a middleware provider that can operate independently from the other technologies that middleware has to interoperate with – databases, desktop software, packaged applications, hardware, management consulting services, and so on. Indeed BEA has often said itself that its position is as “the Switzerland of enterprise software”.

Not every medium or large organisation needs its middleware provider to be “Switzerland” of course. But in a large number of organisations, particularly financial services firms, telecoms providers and governments with extensive, decades-long IT legacies, there’s sufficient heterogeneity to warrant building a strategic relationship with a supplier that can operate independently of all the other stuff and is less likely than others to favour one technology over another. This is a sound strategy based on sound policy (in other contexts, it’s called separation of duties).

Many companies have built relationships with BEA precisely because it could offer them this kind of relationship. And middleware isn’t like vacuum cleaners, or even airline seats: companies (particularly large companies) want long-term relationships with their middleware providers. If BEA is sold – to Oracle, or pretty much anyone else – those customers are going to have the rug pulled out from underneath them. Customers who made strategic IT bets on an independent middleware vendor will have to reappraise their investments and quite possibly spend a heap more money trying to either rejig their strategies, or build new relationships with new suppliers (although options for those wanting a slice of Swiss neutrality are limited: there are only two other software companies of any real size with similar positions – TIBCO and Software AG).

So – to get to the point: what’s troubling me is that in the IT industry, there’s often much hand-wringing about how poorly IT and IT vendors are perceived by businesses, and how everyone needs to work harder to build bridges and raise a positive profile of how IT (and IT vendors) can add value to organisations.

But if the IT industry continues to shuffle deckchairs in the name of shareholder value, to the detriment of customer value, can anyone be surprised when business wallets remain tightly controlled and IT staff, and vendors, are viewed with suspicion by the global community of business IT buyers? If Icahn wants BEA to become more competitive and deliver more value to shareholders, there are more ways to go about it than selling the company. It might be that those prescriptions take longer to kick in than Icahn’s current favourite, though. That probably makes them less likely to be pursued.

Am I being hopelessly naive? Let me know your take. It would be good to start a bit of a debate here, I think.