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)

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)