Chapter 13: The Message That Kept Its Address

July 1998 through May 1999

Sarah walked into the GroupWise lab expecting an architecture presentation and found the system already moving mail.

Two test accounts sat in the same domain. One post office was still served by NetWare. The other was running under UnixWare, on a machine she recognized from a hallway conversation months earlier that she’d assumed was still theoretical. A message crossed from one post office to the other and appeared in the recipient’s ordinary desktop client — same address, same login, same folder it would have landed in either way. The routing log recorded both operating systems involved in the delivery. The message itself carried no sign that it had crossed anything at all.

Half the whiteboard behind the test machines was still covered in failure cases nobody had crossed off yet, and the UnixWare agent was running against a copied test store rather than anything a customer would be allowed near. A hand-lettered legend in the corner sorted the remaining cases into three columns — reproduced, suspected, closed — and the closed column was the shortest of the three by a wide margin. This wasn’t a launch. It was a long way past a kickoff, too — the GroupWise team had clearly been working this for months, on its own time and its own budget, while print services and whatever else was moving through Provo that year had proceeded without needing to wait for any of it.

Sarah understood, standing in front of the whiteboard, exactly what kind of meeting she’d actually walked into.

Diane Osei, GroupWise’s engineering director, ran through what her team had already done before Sarah had finished taking her coat off: a full inventory of every NetWare-specific assumption buried in the server agents; early UnixWare builds of the core processes; a test domain already exchanging real message traffic with a NetWare domain; storage and locking experiments run against both NSS and a native UnixWare filesystem; a client-compatibility matrix covering every supported desktop-client version still in use; and preliminary estimates from the Internet gateway team and half a dozen smaller component owners who reported to Diane rather than to anyone in Sarah’s group.

She delivered the inventory the way Sarah had seen other engineering directors deliver a defense — fast, unembellished, daring anyone to interrupt with a question the list hadn’t already answered. Nobody did.

“None of this came out of your budget,” Diane said, not quite a question. “It came out of mine. Sarah and Eric gave us interfaces to build against and a certification bar to clear. They didn’t run this project, and I’d like the room to remember that when we get to the part where I need something from them.”

Sarah didn’t argue with it, because it was true, and because arguing would have undercut the exact point Diane was making. Clustering and the management-console group were doing the same thing on their own dependency lines, reading the same evolving standards, answerable to their own leadership. None of it had waited for GroupWise, and GroupWise clearly hadn’t waited for any of it either.

What had actually risen past Diane’s own authority to settle were three questions, and she named all three before anyone could soften them: whether the first certified UnixWare release would require the licensed Novell Services foundation and NSS underneath it; how long Novell intended to support customers running NetWare and UnixWare GroupWise systems side by side; and whether GroupWise’s own release schedule should bend to answer Microsoft’s sales pitch on Windows NT Server bundled with Exchange, which was getting louder in exactly the accounts Novell most needed to keep.

Gordon, sitting near the back of the room with the same patience he brought to every meeting he hadn’t called himself, made the boundary explicit before Sarah had to. “This team owns its product and its budget,” he said. “It always has. What it doesn’t own by itself is a commitment we make to every customer at once, or a support duration, or a claim that goes out under the company’s name instead of this department’s. That’s the room I’m here for.”

The architecture review that followed spent most of its time taking apart a phrase everyone in the building had started using too loosely: the common database. It had meant something specific and hard-won when it described eDirectory. Left unexamined, it was exactly the kind of idea that would happily expand to swallow GroupWise too, and Eric wasn’t going to let that happen in a room he was sitting in.

The diagram Diane’s team put up separated GroupWise into the pieces a customer experienced as a single seamless product without ever thinking about the seams: domains and their routing and configuration; post offices and the mailbox data inside them; the Message Transfer Agent moving traffic between domains; the Post Office Agent serving users directly and doing the actual work of a post office; gateways reaching the Internet and other outside systems; and the desktop clients themselves, with whatever local settings a given user had accumulated over years of using the thing.

eDirectory’s role stayed exactly where Sarah had already spent months of meetings, going back to the directory work itself, defending it: it identified the user, and it stored the administrative relationship between that person and a GroupWise account. It did not store a single message, a calendar entry, an attachment, or a delivery transaction, and nobody in the room proposed that it should. The common database engine from the directory work remained precisely what it had always been — one engine, across supported platforms, for directory data. GroupWise kept its own application databases and its own recovery rules, because they’d never been the same kind of thing to begin with.

Someone near the back — one of Diane’s junior engineers, new enough to still ask the question everyone senior had stopped asking out loud — wanted to know why GroupWise couldn’t simply store its messages inside the common database engine too, now that one already existed and ran everywhere the directory did. Eric didn’t treat it as a foolish question. “Because a directory answers ‘who is this and what do they own,’ and a mail system has to answer ‘deliver this reliably, in the order that matters, without ever applying the same thing twice’ — and those aren’t the same consistency rules,” he said. “We can’t promise a message gets delivered exactly once no matter what fails along the way. Nobody can, honestly. What we can promise is that every transaction carries an identity durable enough to survive a retry, that the receiving side always knows whether it’s already seen that identity, and that a repeat never gets applied a second time. That’s reliable delivery. It isn’t the same claim as guaranteed, unconditional, exactly-once — and we shouldn’t tell customers it is. Building one engine that’s honest about both jobs at once is a harder project than porting GroupWise ever was. Maybe somebody builds it someday. Not with what we’ve got in front of us right now.”