Collaboration Design Pattern?

A couple of months ago I wrote about the difficulty I was having with project collaboration. Mike Sax referred to that post (scroll down a way), saying that I should send everyone I work with a copy of “Getting Things Done“. Well, I bought the book, read it, and in fact - yes - it is changing the way I work. However, the book doesn't really say anything about collaboration and when I mentioned this to Mike at TechEd last month he said “well, I only read part of it“!

I've since talked to a number of people who have said they have the book, but “haven't had time to read it“. So, for those of you don't have time to read the book, the way to apply Allens' advice is - as far as I can see - to manage other people's calendars. And that is a very difficult thing to do. The best thing I've come up with so far is to put all requests into “appointments“ with a reasonable reminder (which, alas, has to be the same for everyone). Also, I have to put all the context information into the message otherwise they will never get around to searching that out (unless they are using X1, in which case they're already ahead of the game).

So, what I have is a one-to-many, asynchronous request with enough context information for the recipient to carry out the request <fingers crossed>. The problem is, I can track whether they _say_ they're going to do it (by “accepting“ the appointment), but beyond that I have no visiblity. How do I know if/when they've actually done the work? How do I know when they have all done the work?

Here's the funny thing: I really need a distributed service oriented architecture (SOA) for collaboration. The parallels to the world of software architecture based on design patterns is striking: Obviously there's a Command pattern, I need an Observer to find out when the work is done. But a brief trip through Hohpe & Wolfe's recent (and excellent) “Enterprise Integration Patterns“ turns up a bunch more: Recipient List, Aggregator, possibly a Content-Based Router if we're overloading email with this stuff (like we overload other common communications protocols), and so on. As with any service architecture, I need this all to work asynchronously. Of course, I'd also like this to be dynamically configurable. <g>

So...is there anybody already working on an SOA implementation of “Getting Things Done“? If nobody comes up with something, I'm going to start fleshing this out as a sample that I can use in presentations. A brief Google search for “Collaboration Design Pattern“ turned up a “Mediator Collaboration Design Pattern“ (see “Architecture-Centric Object-Oriented Design Method“), but I want something that's service-based and I don't really care if it's object-oriented under the hood (that's a convenient implementation detail <g>).

Of course, for this to be a recognized design pattern it has to be observed in three separate places independently. Which is why Ron Jacob's “Last Man Standing“ pattern (which I would use to know when all the requests were satisfied) isn't an “official“ design pattern. Still, I think there's some justification here for a meta-pattern around collaboration. Comments?