I've had a few discussions recently where people have gone on about using approach X (o r R) because it would give "full security", "massive scalability" or some other non-functional nirvana. This is normally said without actually asking what the requirements are and a response from me of "but it doesn't need that sort of security" or "its only got one user" is met with "you must prepare for the future, what if it goes on the internet tomorrow?".
This is a classic technical argument, and one that is hugely divorced from business reality. Having the perfect solution for a business problem does not mean that the solution has the "best" technical architecture, it means that it is good enough for the job.
Scalability is the easiest place to over engineer solutions. Back in 2001 I architected a solution that used stateful web services, I did this as the web service provided a security session into the back end application (basically if you didn't authenticate then the service wasn't connected to the backend). It worked a treat, scaled fine because there was only one consumer of the service they were a call centre and they had a single point of interaction with the service and all their requests went through that one session. It worked, it went live. Would it scale to 10,000 users? Nope. But then that was NEVER in the business case and was NEVER going to happen.
By separating the backend from the information exchange it then becomes possible to have different interfaces on the same logic that provide different scaling approaches. All to often however people want to architect the whole system based around that information exchange.
Split information exchange from the business services, and worry about the scaling that is appropriate for your information exchange. Don't worry about technical purity and some "wonder" architectural approach. Don't over engineer because if you do X (or R) then it will scale to 100,000 users, but your requirements say "6".
Business requirements should drive your decisions on scalability, not a technical discussion on what is possible. Scale to what is needed, not to what is dreamt.
Obsession with technical purity is a major challenge in IT, and its unlikely the business will take IT people seriously while they continue to obsess about things that don't have business requirements.