Correctness is normally used to describe the technology side, solution X is more "correct" because it obeys more rules or exhibits better technology pieces. The goal in this mindset is to be as correct as possible, rather than being good enough for he job at hand.
If architecture is to be about delivering what the business wants then there are three things that should be at the front of an architects mind
- Is it good enough
- Can my team deliver it?
- Can we support it?
Convenience over Correctness therefore should mostly focus on convenience as that will help deliver something at a better business price and which more developers (read cheaper developers) will be able to deliver and which more people in support (read cheaper support) will be able to maintain.
Architecturally it is the convenience that represents the best choice even though technologically it is not the correct choice. If I have a team of VB 6 developers and have to build a distributed multi-threaded application then the technologically correct choice might be to architect using REST and Erlang, however the business correct decision would be to architect around the limitations of the team and the platform to enable that team to deliver the solution. Yes it could be argued that hiring 20 Erlang guys with REST experience could have got the job done quicker head-to-head, but not if you factor in hiring time, recruitment costs and the increased salary costs and this was also not the challenge that the architect was presented with.
Architecting from the Ivory tower is easy. Assuming everyone is as smart as you are is easy. The real skill is in understanding the complexities and picking the technologies and approach that is most convenient for the people you have and good enough for the problem being solved.
If architects are to change the perception of IT then we must focus on business objectives over technological correctness. Brunel was right that the "correct" gauge should be wider as the previous one was merely a convenience. That was the engineering and technology view, the business view was that standardisation and the majority was the correct view for economic development.
In delivering business solutions it is the business correctness that matters over the technology correctness this means focusing on the people available for delivery and matching their skills to the architectural proposals and focusing on support to ensure that it will operate effectively.
Architecture should be about making it work in reality, not making it work better on paper.