You are correct on the architecture as the most important. Its like a road map for the transaction. As an example I faced here is a question for the readers who have or are developing SOA applications. Can you use a virtual disk or a virtual file to increase speed of access and the validation of ID's and passwords. Some of the better web sites are using this. It can be an investment and a challenge in finding new hardware and software to obtain the speed and transaction processing volume you need for a 5 to 10 second response time. Note: On some sites they tell you that your transaction will take one to three days to process or show up on it web site. This is because they don't update their virtual files until the data base is reloaded. When a change is made it only updates the data base or hard drive files and not the key virtual files. The virtual files are reloaded from the Data Base usually in the middle of the night to minimize the delay effects on real time file access while the system is running live. The experiment or alpha testing of updating the virtual files may be a moot point as it still needs to update the hard disk. And while keeping the two data bases in sync seems a little klunky, it works and will probably be the standard updating technique for a while.

Great assessment of both some bad consulting and some of the problems with architecture in the SOA world. I see a slightly different slant on the problem where it is more pervasive and results from architecture groups that tend to be insulated from real solution delivery. You touch on this with the "implementation" comment. I blogged more about the problem here: http://www.skywaybuilder.com/blog/