John Reynolds's Blog

Dyson's Meta-Mail: merging email with business processes

While browsing the news feeds I came across an interesting article by Esther Dyson on the topic of "Meta-Mail". Perhaps I had heard something about this concept before, but the one advantage of my mid-life-memory is the thrill of discovering new ideas each and every day... but I digress... "Meta-Mail" is Dyson's term for melding business processes and email.

Simply put, email needs structure. Without structure there is not much that can be done to categorize email beyond the results of text searches. In Dyson's words:

"Text search can catch topics (or nouns, what something's about), but it can't catch the implicit 'transactions' (or verbs, such as commitments, deadlines and decisions)."

This begs for a real example from my exciting life:

• One of our consultants (Srikanth) discovers that he cannot file a support incident with a vendor. Our service contract has lapsed, and he is stuck.
• Srikanth sends me (John) email, asking me to get the service contract renewed. He is stuck, so he marks the email as "urgent".
• My inbox is relatively empty, so I actually read the email (within an hour or so).
• I reply to Srikanth, and forward the email to my boss (Sam).
• Sam replies to me, and directs a request to the head of the group that "owns" our contract with the vendor (Amy).
• Amy sends email to the team member who works regularly with the vendor (Mary).
• Mary sends email to the vendor.
• The vendor replies to Mary with terms for renewal.
• Mary forwards the terms to Amy for purchase approval.
• Amy approves the purchase, and emails our purchasing department (to issue a purchase order).
• Our purchasing department issues the PO to the vendor.
• The vendor emails Mary the new support keys.
• Mary emails Amy, Sam, John, and Srikanth the new support keys.
• Srikanth uses the keys to file the support incident.

The point of this example is that a business process is being conducted via email. Each message is a step within our ad-hoc "renew a support contract" process. I am certainly not bragging about the details of our process, but it should seem pretty familiar (and pretty scary). Each email is distinct and unrelated to the others except for the likely inclusion of the email thread within the body of the message. There is no easy way to track the progress of the process (except to send follow-up emails), and it doesn't take much for the process to stall.

Dyson's solution is to identify messages as process steps by embedding meta-data within the email. Meta-data can add meaning to email, and this meaning can be used "to look for and manage processes, activities, transaction threads and the like by what often matters most: links between events and activities, timing, state of doneness or dueness, attributes that have to do with the state of interactions among objects and people."

The "killer-app" that will enable all of this has yet to appear (Dyson calls this application "Visi-Process", and homage to the first successful spreadsheet "Visi-Calc"), but many are working towards this goal (IBM's Remail, OSAF's Chandler, etc.). Personally, I doubt that a "closed" application suite will do the trick. Process meta-data must be standardized to work across a wide variety of tools, or it won't really make much of a dent in the way we work.

Pretty cool stuff.

Update: Thanks to a reader for a link to Roundup, an Open-Source tool that incorporates some of the concepts of meta-mail.

Comments

• Ad hoc workflows, roundup
  While this looks a lot like some commercial people-based workflow systems (as opposed to process-based workflows, where the process is prescriptive) there is a tool out there that does a lot of what you describe: roundup.

  http://roundup.sourceforge.net/doc-0.6/overview.html

  Roundup was Ka-Ping Yee's winner of the Software Carpentry competition for issue tracking. The thing that sets this tool apart from others, is 'nosy lists':

  New items are always submitted by sending an e-mail message to Roundup. It replies with a tracking number in the subject line, and Reply-To set to Roundup's address, Subsequent mails to roundup with this tracking number in the subject are logged with the original, and roundup relays the message to the people on its address list for that issue. So far, so much like req and other issue tracking tools.

  The extra step is this: the address list is a "nosy list" and constantly changes. any addresses on the From:, To: or CC: fields are added to the list. (There's a web interface that allows you to remove people from the list) The effect is like each item having its own little mailing list, except that no one ever has to worry about subscribing to anything. Metadata like process state and priority can be assigned to an issue, and searched for, but that is done at the tracking website.

  Roundup strikes me as hitting the same sweet spot as Wikis; they both lower the bar to participation by removing things that get in the way - like a process states preventing any further communication on an issue, for example.

  Where Roundup falls short is that only one organisation on the list has access to the website. (as far as I know - they may have introduced "peer" roundups to do this.)

  While roundup if great, there's a downside: recent usability advice is no longer "where possible use email", its "where possible don't use email" - because users are overloaded with information (and spam).

  Posted by: ba22a on July 20, 2004 at 07:56 PM

• Ad hoc workflows and Java
  Thanks for the link. I will certainly check it out.

  Does Roundup put any constraint on the recipient's mail client?

  It occurs to me that Java's original goals are very conducive to implementing a distributed ad hoc workflow. Java's sandbox was intended to give a user confidence to run an application that was "mailed to them". if a "proclet" (I think I just made up that term for an "applet" that implements part of a process) is embedded in an email, the recipient could participate in a distributed workflow regardless of their mail client.
  

  Posted by: johnreynolds on July 20, 2004 at 11:54 PM

• The most important thing you left out...
  Yes, its a business process.

  But somehow you've overlooked that it is actually not one, but *three* business processes (possibly more, pedants, start your engines)! *At least one* of which is an external process that you have little (or no) control over.

  You have your 'renew contract process', but the vendors have their own process... and it is the interaction of the two processes which is the heart of the system.

  Actually, I can now think of four processes:
  You: get support
  Vendor: give support
  You: renew support contract
  Vendor: sell support contract

  Ironically, in many situations, the 'sell support contract' (which gives the vendor resources) process is more complicated and difficult than the 'give support' (which consumes the vendor's resources) process.

  Of course, the 'give support' process has a little hurdle, the dependency on you having a valid, up to date, support contract.

  So even if you only have two organizations, and four processes, the possible interactions and dependencies between them are quite complex.

  Now... what happens if you introduce a second organization... they might not even have a 'sell support contract' process, or their 'give support' process might not be well defined. In any case, it is highly unlikely that their process will be the same as the other organization.

  Case in point:

  One place I worked had this great desire to throw lots of money at Borland. So at one point we got the latest JBuilder (8) 'hot off the press'. (I don't think they were freebies either, I think we had to pay for them)

  Now, in order to actually use a Borland product, you have to have a licence. In order to get a licence you have to download it from their site. In order to download it from their site, you need to sign up some membership thing. Since you do this rarely, you will have lost your last membership details, which is on a person by person basis (which meant all sorts of calls/emails to their tech support when a developer left (the one whose shoes I filled), because we had to convince them that the organization which paid for the licences should be able to allocate them to whichever developer it wanted to.)
  Anyway, at some point you actually manage to persuade them to email you the key to activate the licence to enable the software which you paid for.

  (Hopefully) This is about the most difficult sign-up process out there. I certainly hope it doesn't set a trend!

  So even if you have well organised and consistent processes, and the organisations you deal with themselves all have well organised and consistent processes, if they all have different steps for their process, then your 'one size fits all' solution will fail.

  A truly generic solution to the problem will not be trivial.
  

  Posted by: rickcarson on July 21, 2004 at 01:46 PM

• And the process keeps growing, and growing...
  You've got the picture Rick,

  Most processes aren't cast in stone, and each step can spawn processes that spawn processes that spawn... (Oh dear, I think this could be an infinite loop).

  I don't think the Meta-mail concept is meant to be a full solution to managing processes... it's a tool for of making sense of the whole mess from the perspective of one person's inbox.

  I'm thinking that when you author an email, you include meta-data that indicates what sort of response you are seeking. When you recieve an email, you (figuratively speaking) scan the meta-data to determine what action the sender expects. When you forward an email, the original sender's desires (in the form of meta-data) go along with it.

  User interfaces that mere mortals can understand are a going to be a big problem: How do I easily indicate that this email requires one of the addressees to make a decision?

  Meta-mail standards are another big problem:
  It's not going to do me much good if I send meta-mail to someone who doesn't have the tools to process it.

  Somehow solving problems like this seem more interesting then reinventing EJB persistence mechanisms ;-)

  Posted by: johnreynolds on July 22, 2004 at 12:01 AM

This work is licensed under a Creative Commons License.