I have another travel update I'll post shortly, but wanted to get one "on topic" post up as well.

Long time blog readers will know that I've had a long time interest in business models and pricing models for enterprise software. CPU pricing, while currently the norm, has several major challenges. CPU performance continues to increase rapidly, effectively cutting software vendor's prices in half every eighteen months. Not to mention the very definition of a CPU is becoming nebulous. Is an eight core Sun Niagra processor a single CPU? Or how about a eight virtual CPUs all runing on a single physical CPU using something like VMWare. Or what about open source business models that are charging for support (or even for new features). 

All of this makes pricing enterprise software challenging. BEA tries to cope with this by having well documented and explicit policies around multi-core and virtualization. And by, where it makes sense, having enterprise license agreements that allow for even more flexible use of products. Others, like Sun, having taken revolutionary steps such as subscription-based per employee pricing. Still others have declared an intention to do transaction based pricing. (Which, as I've discussed before, I think is a horrible idea. It makes software costs unpredictable and discourages use.)

But perhaps worst of all is what IBM just announced for it's middleware pricing. They've brought back the idea of "power units" or MIPS based pricing, this time calling it "processor value units". IBM portrays this as providing for more flexibility and simplicity in pricing. (I think flexibility in this context means "we can charge you more".) Most disturbing is their announced intention to "differentiate licensing of middleware on processors .. [evolving] to differentiate processor families based on their relative performance". Meaning that if a faster processor comes out, IBM plans on charging you more to run their software. Or they might charge you more to run on Sun SPARC chips than IBM chips.

I agree that simplicity is a desirable characteristic for pricing. But I don't think processor value units create any simplicity at all. In order to buy WebSphere I know need to know how exactly what models of servers I have, exactly how many cores they have, exactly how I've partitioned those servers, and exactly what processor value IBM has assigned my server model. That doesn't sound simplistic to me.

Posted by davidogren in Other | Permalink | Comments (0) | TrackBacks (0)

Because of AquaLogicBPM's strong presence in Latin America, ocalization and internationalization have always been a strong feature of AquaLogicBPM. Not only does AquaLogicBPM take advantage of the strong Unicode and internationalization features of Java, but AquaLogicBPM has always considered localizing information that will be presented to end users as just a natural part of building a process.

However, as Fuego, we never had a strong sales presence in Asia. Asia is a hard market to support without a large partner presence and lots of local staff. So, despite a feature set that lends itself to easy localization, ALBPM was never localized to Asian languages.

That is going to change in the next release of AquaLogicBPM. We will be including built-in localizations for several major Asian languages. From a technical perspective there are more interesting features in the next release. But from a sales perspective, Asian localization are a big deal. The Asian market is obviously very important and up until now we have been neglecting it. With the advantage of being part of BEA, and inheriting BEA's global partners and global presence, we are seeing lot of interest for ALBPM in Asia and this next release is going to let us start addressing that demand.

So, in preparation for that next release, I am off to Asia to do some deep dive training for Asian BEA employees and key BEA partners. I'll be spending the next two and half weeks on the other side of the globe in Japan and China. I have to admit I'm a little apprehensive. I've never been to Asia. I've been to non-English speaking countries a few times. But even in those situations I knew enough of the language and culture that if I could be relatively independent. However, going to a country with a very different culture, a completely different method of writing, a haphazard way of numbering streets, and a language that I know absolutely nothing about is a lot more intimidating. I'm sure I'll be able to get around, but I won't exactly be very independent.

As much as I can, I think I'll keep a travel diary here on my blog. I may or may not get the chance to make business focused posts while I'm away. It depends how busy my students keep me. But, if nothing else, I'll at least be able to share my experiences living a few weeks a very different culture.

Posted by davidogren in Personal | Permalink | Comments (1) | TrackBacks (0)

Bruce Silver has a nice post on his blog about the relationship between SOA and BPM as well as some nice things to say about BEA's product stack and messaging. I think it shows great insight and pragmatism both Bruce as well as BEA's Shane Pearson and Alfred Chuang.

It's one of those conversations that makes you want to say, "Yes, that's what I've been trying to say but you said it much better." I'm currently working on multiple projects where BPM is being used inside of SOA initiatives and this is something that's been on my mind a lot. Bruce's post is also nice because he discusses some of the technical details of BEA's AquaLogic roadmap regarding the SOA/BPM convergence. At a level of detail that actually makes it useful to readers. (And, he's right, AquaLogic is a brand. The AquaLogic brand is becoming more integrated, but it's still not fair to call it a platform yet.)

Posted by davidogren in | Permalink | Comments (0) | TrackBacks (0)

A few days ago I blogged about the how watching blogs.sun.com during the Sun layoffs was an interesting experiment in the ramifications of corporate blogging.

The very next day, Sun's general counsel, Matt Dillon, started a blog and posted about Sun's experiences with blogs.sun.com during the layoff. Very interesting. In addition, perhaps knowing that many of the laid off Sun bloggers would continue blogging, they started a syndication site for Sun alumni. I looked into it, and after a few days of verifying my identity, BPM Blog should now be syndicated over at the Sun Alumni blogs page.

Posted by davidogren in Blogging | Permalink | Comments (0) | TrackBacks (0)

Several of my colleagues and I have been discussing the IBM acquisition of FileNet this morning. Like Sandy I'm not sure what to think. Considering that IBM is already in the ECM and BPM spaces, what does FileNet give them other than a customer base? This, of course, will start a round of speculation about "which products will be killed?". But I don't think we'll find out the answer to that for a while.

Posted by davidogren in BPM | Permalink | Comments (2) | TrackBacks (0)

Corporate blogging is still a largely unexplored frontier. I know that I still stuggle with the etiquette of what to post here. One thing that I'm finding very interesting to observe is the affect of the Sun layoff (aka RIF) on blogs.sun.com. Several bloggers have now gotten the axe and several others have made posts about the day the RIF hit their local office.

I remember companies making sure that RIF'd employees don't have access to email so that they don't send out any negative comments to customers or partners using a company email address. Now, with the proliferation of Sun blogs, we have RIF'd employees with the ability to publicly post to the front page of a Sun website about their "layoff experience". I wonder if PR is watching that site. It doesn't seem like it because there have been a couple of posts I think they would have removed if they had been censoring it.

I think this is a good thing. It shows the professionalism of corporate blogging in general. If you can trust your bloggers in a situation like this, I think that it's a good indicator that bloggers don't need PR babysitters.

Posted by davidogren in Blogging | Permalink | Comments (1) | TrackBacks (0)

A little bit off-topic from BPM today, but I'm still thinking about the announcements from Apple's WWDC conference yesterday. A couple of quick things worth noting for a Mac user such as myself..

Apple didn't make much hoopla about it, but Sun's DTrace has been integrated into Leopard, the next release of OS X. DTrace is one of the things that I miss now that I don't work with Solaris as much. DTrace is hard to describe to people who haven't used it, but it's the ultimate debugging and tuning tool. DTrace lets you peek into exactly what is going on inisde your computer and automatically sift through that data to pinpoint and monitor exactly the data you want. I'm excited that I'll get to use DTrace on my day to day computer again someday.

Another feature that Apple did demo in the keynote is "Time Machine", however. Time Machine is a backup tool that gives you a visual view as you search backwards through backups to find a previous version of a file. Nice from a UI perspective, from the perspective that it will be a ubiquitous part of OS X, and because it will be available for third party applications to integrate with. (Meaning that you'll be able to restore your files without ever leaving your application.) More interesting, however, at least from my perspective, is that Time Machine is built under the complete assumption that you will be backing up to a hard drive. Either to an external hard drive or to a hard drive on a local server somewhere.

I think this is a great thing. One of the reasons people don't do backups today is all of the trouble spanning CDs, DVDs, or backup tapes. If the file I want to restore is on backup CD #37, what are the chances I can find the right CD and that CD #37 won't be scratched/corrupted/list/damaged? Time Machine wont' solve everything: everyone should still do periodic full backups to a separate offsite hard drive in case of fire/flood/theft, but Time Machine will be a nice step forward towards making backups more practical. It's also a complete victory for the idea that "disk is the new tape".

Finally I'd just like to say that I'm completely jealous of the new Mac Pros. With that kind of memory, processors, and disk it's basically a server in a desktop form factor. Makes me want to buy one to run Solaris and ZFS on it. :-)

Posted by davidogren in Personal | Permalink | Comments (0) | TrackBacks (0)

I started typing a comment response to Keith Harrison-Broninski's post "Email is not suitable for business use". But it got long enough that it deserved its own post. In the end, I do discuss how some relevance this topic has to BPM.

In short, I agree with Keith. Email, and its limitations and problems, are something that I've been thinking about for years. Many years ago, I thought that the solution would be "groupware" products. But groupware have been a poor replacement. They've been proprietary, have been lacking in the needed functionality, have been slow/difficult to use, or all of the above.

While I still think the solution is years away, but I think the technological pieces are coming into place. I believe the key to solving the email problem will be Atom. There are two parts to the Atom standard. One is a syndication protocol, similar to the RSS format you may be using to read this blog. Atom allows a client application (either a standalone program like NetNewsWire or a web application like Bloglines) to keep track of a specific "feed" of information. The other part of Atom is a publishing protocol (somewhat like the existing Blogger and MetaWeblog standards) that allows clients to write and publish to those same feeds of information.

People have long speculated that RSS might replace email, but until the improvements provided by Atom, it was hard to see how that would be possible. Not only were there various technical problems with RSS, but without a publishing protocol RSS would be read only. Not very useful for replacing email. :-)

In any case, imagine a server application where each user had their own Atom "inbox" feed. I can connect to my "David Ogren" Atom feed and download articles much the same way that I subscribe to my email using Outlook. And like IMAP, Atom will allow me to store all of my "email" on the server so that I can connect from my laptop, desktop, and phone and access the same inbox. Other people can either send me emails and the server automatically converts then to Atom and adds them to feed. Or, for other people using Atom, they can using the Atom publishing protocol to submit "emails" to my Inbox.

But in addition to "person to person" messages, the server would also allow topic related feeds that would replace mailing lists. Instead of a mailing list for the "Nifty Product Release" or a long CC list on every email, I could just click a link to subscribe to the "Nifty Product Release" and that would be added to Inbox. (Or displayed to me in a separate folder of my client.) If my input was needed for the "Nifty Product Release" the product manager could send me a link to the feed, I could click it, and I would then have access to all of the previous "emails".

The server would even create an automatic feed by subject so if you later need to include someone else into a discussion you can just click a button to invite them into the feed for that subject. "To" and "CC" lists could really just be replaced by sending links to various feeds.

One of the nice thing about Atom protocol is it automatically solves the redundancy problem that this causes by including a unique identifier. If some replies to me regarding the "Nifty Product Release" project I'll probably see that reply in my "inbox feed", "subject feed", and "project feed". But my Atom client will see that that the unique identifier is the same and will only present me with the post one time, marked with all of the appropriate tags.

This Atom based solution solves a lot of the problems with email:

1. It solves  Keith's involvement concerns. As the needed participants change over the course of the project, they can just subscribe and unsubscribe.
2. It solves Keith's sequencing concerns. When I get a message it will automatically be seen in the context of the entire conversation. (Or at least has the potential to be displayed that way.)
3. It solves the filing problem. All of my "email" is stored on the server, automatically sorted into projects and conversations. And it's only stored once, no matter how many people are reading that "email". If I unsubscribe, it's still there, and I can resubscribe later if I need it later.
4. Hope it also addresses Keith's concerns about being overwhelmed by email. I don't have to CC the world, because I can always include them later. Or I can send them a link to the feed and they can decide for themselves whether it is worth following. They might subscribe to the feed, but not include it in their main inbox. That way they could catch up when they have spare time on the airplane, but not clutter their day to day interface.
5. Also, unlike email, it has a standardized way of handling rich content. It's much easier to manage things like formatting and attachments reliably in Atom than it is in email. This, combined with Atom's better way of managing conversations, will hopefully solve Keith's concerns about successfully carrying the tone of an email.
6. It also solves many of the technical issues. Unlike email there are good ways to include security, authentication, spamming, revocation, and other issues that plague email.

It also solves some of the problems with groupware:

1. Atom is an open standard. Even if my company uses different software than yours I can still read and respond to your "email".
2. Atom based "email servers" have a good path for migration. My Atom server can include an email gateway that will allow me to convert my Atom posts into emails for those that aren't using Atom and convert the regular SMTP emails received from others into Atom conversations that I can subscribe to.
3. Atom can work offline. I can download all my conversations to my reader and bring them with me to the train or airplane.
4. Performance/usability. Although many groupware clients are catching up on this as well, none of the Web 1.0 problems should apply. Standlone readers can be lightweight and fast. Web clients can use AJAX to allow for quick response times when browsing through long threads of conversation.

Anyway, this is all still a ways off. The Atom publishing protocol isn't quite finalized yet. Even simple Atom servers don't exist yet, let alone the sophisticated and auto-tagging and auto-converting one I describe here. Not to mention that client applications would have to be developed to make this all easy and transparent to the user. But at least the underlying technology for communication is coming into place.

Bringing the conversation back to BPM, I've seen several projects where BPM has been brought into to replace an email based process. Which is OK. BPM is a lot more auditable, traceable, and manageable than email. Replacing email as part of a BPM process is no different than replacing an a a paper form, a fax form, or an Access database. The times where I see these "email replacement" projects is where they lose focus and try to be a generic email replacement rather than just trying to use BPM for the part of the process where they used to use email. Despite the collaboration features including in many BPM suites, BPM was never designed to be a general purpose email or groupware solution. BPM is much more structured than traditional email and trying to use it in a completely unstructured environment is bound to cause frustration for users.

Posted by davidogren in Other | Permalink | Comments (1) | TrackBacks (0)

Bruce Silver has been posting about some interesting developments regarding Oracle. A while ago I was having a conversation with a potential customer and he asked me how ALBPM compared to Oracle's BPM solution. I answered, much too flippantly, "Well the first difference is that we're a BPM product and Oracle isn't. Oracle is just a BPEL engine." I regretted that almost as soon as I said it. Obviously people have very different definitions of BPM and certainly some people considered Oracle's product a BPM solution. I was just venting a little frustration in trying to compare apples and oranges. Oracle's solution had no business user modeling, simulation, or other features I considered essential to BPM.

But yesterday, Bruce Silver validated some of my thoughts. Apparently he had been having conversation with Oracle (including Edwin K, whom I have a lot of respecdt for) and Oracle recognized that Oracle Process Manager wasn't a BPM solution on its own. So Oracle partnered with IDS Scheer and OEM'd parts of ARIS to flush out their solution.

Which is interesting. I'm very curious to see some of the same details that Bruce is curious about. I've never seen a solution where business users and technical users see different versions of the model be effective. So I'm skeptical of a solution where business users use BMPN in ARIS and technical users use BPEL in Process Manager. The mapping just isn't clean enough yet, even with Oracle's proprietary extensions to BPEL.

I'm also skeptical of OEM relationships in general. ARIS has it's own customer base and isn't going to be as responsive to Oracle's needs as BPMS vendors ability to maintain their own toolsets. But we'll see what happens as the relationship is further fleshed out.

Posted by davidogren in | Permalink | Comments (0) | TrackBacks (0)

I hate to post links that Sandy has already posted in Column2. Since we both eBizQ bloggers I'm assuming that most people that read my blog are also reading hers. (And if you aren't, you should be.) But, because of my position with BEA, the Intelligent Enterprise article was especially interesting to me and I think that I can provide some unique insight.

Several times in my career I have been working for a small company that has been acquired by a larger company. Every time I have always been amazed by how much that transition to a larger company "changes the game". The projects that you work on as a small company are very different than the deals you work on as a large company. There are many reasons for this including increased resources, better support infrastructure, and better executive access. But another key reason, and the one that I think is critical to this discussion, is a broader product line.

At Fuego we were all about BPM. At BEA, even as a BPM specialist, I spend less time talking about "BPM in a vacuum". Certainly I spend a lot of time talking about BPM; BPM is arguably the hottest product at BEA right now. But I'm frequently talking about BPM these days as part of a larger enterprise architecture: BPM as part of a SOA infrastructure, BPM in combination with portals and knowledge management, and generally discussing BPM's role in a larger enterprise context.

As such, I can't help but wonder if the future of BPM will look like Connie Moore's prediction for ECM. In the Intelligent Enterprise article Connie says that "[It is] our long-held belief that basic, enterprisewide content management capabilities would become the domain of infrastructure providers like Oracle, while more complex, industry-specific content management would be delivered by ECM vendors such as Open Text."

Gartner says there are over 150 BPM vendors. My experience has been that there really are only a handful of BPM vendors, but there are literally hundreds of "wannabes" that have a business intelligence tool, content tool, rules engine, workflow engine or some other legacy product that they are trying to move up the stack to create a BPM product. Wouldn't it make sense for all of these niche players to instead add their "secret sauce" on top of an "infrastructure" BPM prdouct?

I obviously have a biased opinion in this matter, but BPM is maturing to the point where companies are trying to make "enterprise" decisions. It's going to be harder and harder for the small vendors to survive in a market that is going to demand global support organizations, partner ecosystems, extreme scalability, and enterprise manageability. I've seen several companies come to BEA recently looking to replace recently acquired BPM solutions that "won't scale" or aren't "enterprise class". With TIBCO, IBM and BEA already in the BPM market, and with Microsoft and Oracle having some of the pieces, how long will the other players be able to stay out of niche status?

Obviously, the independent pure play vendors aren't going away overnight. But wouldn't the pure plays be better off focusing their resources on their differentiators instead of BPM infrastructure such as execution engines? One nice side affect of this possible future. by the way, is that we'd get real industry standards. Either de facto standards from the leading vendors or from the standards bodies.

Posted by davidogren in | Permalink | Comments (0) | TrackBacks (0)