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?
The “best” thing at TechEd 2004 San Diego was undoubtedly the cabanas. It was like an extended “Ask The Experts”, except that - confusingly - the sessions were actually caled “Meet The Technologist”. The a/v support was abysmal, which lead to some creative solutions:
This image shows Rocky Lhotka and Ted Neward "debating" during a GAPP team session at the Architecture cabana. About 30 people were clustered around them so tightly that there wasn't room for a 3rd person in the center. Rocky and Ted - both with strong presentation voices - were continually turning around at the center to address people on the outlying edges. Attendee David Romig summed it up well: "an interesting mix of technology & theatre".
Yesterday I did a workshop on “Best Practices for .NET Enterprise Architecture” at the Enterprise Architecture Summit 2004 in Palm Springs. One of the questions I asked the 30 people in my workshop was “How many of you are familiar with WSE?”. About 10 hands. Then, “How many of you are using or are planning to use WSE”? Zero hands. Whoa! Then, “How many of you are not going to use it because of something the Indigo team has told you?” The same ten hands. Which pretty much confirms what I heard at TechEd, which was customers telling me that the Indigo team had told them to “hold off“ on WSE.
Great. Organizations are going to hold off on implementing SOA using .NET today because of some vague promises of a future technology. Please, somebody just shoot me now.