Sanity in project processes - back to reality pleassseee

Sorry, cynical mode today....

Ah, I succeeded again... Finding myself suddenly being pulled into a, well, project from Hell.
We all know them. The ingredients are simple:
Mix:
- Not enough time
- No formal proces for requirements, design and build
- No test tools
- No issue tracking procedure and supporting tool
- A strict deathline
- No recording of decisions and knowledge
- Changes in project staffing

And within no time, everybody is running around, trying franticly to discuss, rediscuss, implement, change, discuss, test, discuss, report delays, etc. Working software? I think not.

Key ingredient is, I think, a recurring thing. Let's do a short parabel:

Company A wants a new building as headquarters. They approach a architect and a builder and tells them: well, we want a building, we don't know what we want yet, but why don't you start architecting and building already in parallel, we will test in parallel, so we can move on magicaly date XX-YY-ZZZZ, which we have promised to everyone in the world (and our heads will roll!) without knowing the scope of our demands or any knowledge of timelines for buildings anyway. Make sure it's on time, on budget, and to the right quality!
And what would the architect and builder tell them? Simply: "interesting, but no thanks. Good luck trying to find someone crazy enough to go nuts together with you. And when (or if) you come to your senses, don't hesitate to contact us, so we can tell you how you architect and build buildings for real, with lasting succes and sanity"...

But what do IT companies do? They say - sure. (because O my, it might go to the competitor).

It reminds me of a funny story (happened really!) I heard when working in Sweden.
The king wanted to build this great warship. So, he invited a shipbuilder (dutch, like me :-)), who promised to deliver a 3 deckship. After some years the king visited the king in Danmark, and oh my, saw that his ship had one deck in addition. King back to shipbuilder: I want an extra deck! Shopbuilder, knowing his stuff, tries to scope down, but the king insists, it's the extra deck or the shipbuilder's neck... Easy choice. The ship is delivered, and within about 15minutes of her maidenvoyage it sinks.

My lessons:
Projects should have:
- Realism in scope, cost and time
- Clear processes

Back to work, cleaning up :-)

BPM technology - what happened to two-phase commit?

Between Mid-80's and beginning 90's, when distributed databases and client/server applications began to become mainstream a great technology was introduced: two-phase commit. It basically meant that when a client (or middle tier) wanted to perform a data transaction (create, update, delete) over 2 or more separate databases, it was able to do this in a safe way: either the transation succeeded in all the involved back-end databases, or the complete transaction was rolled back. Various databases started to support this, using the (if I recall correctly) XA standard.

Now I find myself wondering what happened to that great transaction model.
In the current world that we call SOA and BPM technology, suddenly we talk about calling services, hoping everything goes well. And if not, well, there is Compensation. Which, by the way, might fail too. Ouch!

It's amazing - I've seen client/server development tools mature, until they provided a quite stable development and run-time environment, including transactions, debugging, etc.
Then, boom, came the webmodel, and we started all over, with buggy development, debugging ("println("I am at point X and variable Y has value:", y).
And now we have the BPM technology development and run-time environment, and I find myself once again missing all these things that used to be normal....

Anyone knows if there are BPM technology suites that support a two-phase commit like transaction model? Has any of those WS-* standards reinvented this yet? I hope so.
At least than we can think up a new technology to start all over again :-) Mobile?