Couldn't find the post to which I orginally replied, so I don't know why I made the "not IT" statement. Probably because that acronym gets bandied around so much, it makes my head hurt.
The only place, in your example, that 1) and 2) should disconnect are at the subscription servers. I'm not sure, but I've been getting the feeling that they're done by a group external to development recently - so that's not in their control, and therefore the ONLY thing the developers can't be held directly responsible for (although, since it's their butts on the line, you'd figure that they'd be pretty damn insistant that it's a robust system).
I don't know how the technical departments at Verant are divided up, but I've always found it a big mistake to distance the software engineers and the DBAs. Generally speaking, since the programmers are the ones initiating database connections, they should be part of the database design process. At least, I've found that if the DBAs are free to design and optimize a system without input from the developers, you wind up with a middle-tier filled with bloated code and dead code trees - functions that are left in "just in case" the DBAs change things again - and other similar anti-patterns.
And again, though I'm not sure how Verant is set up, I imagine that the 1)s and 2)s sink and swim together - so I'd imagine they'd want to play nice, and work together to insure that neither 1) nor 2) fail.
While designers (not developers) at VI (Verant, VI is easier to type) might not have control of the subscription servers, it's such an important piece of Day 1 that you'd think they'd have their fingers in as much of it as possible. But they DO (AFAIK) have control over such things as the login servers and preparing backups for whatever fails on Day 1 - so you'd think they'd make it as robust as possible.
I don't see how you can pin ALL of the blame on SOE - yeah, they're responsible for pushing the game out of the door regardless of its state (as well as whatever part of the sign up/connection process they do), but VI is AT LEAST as responsible for whatever goes wrong.
You're right that most of the technical people shouldn't be shouldering the blame - IMHO, that is the primary responsibility of management. Management should be there to do their best to make the project succeed, but they're also supposed to shoulder the responsibility for failures (though I rarely see this - I generally see the developers being blamed for whatever happens).
But as a guy who does both the hardware and software side of things, I argue that they are not *totally* different skill sets