Well it seems like (I'm guessing here) your architect is trying to say that his solution will hold up better in the long run.
In terms of arguing, if you guys are going around in circles one good way is to write down the key points of the argument or merits on a whiteboard/paper. Like solution one offers 1) speed 2)cheap versus solution two offers 1) stability or something. I've always found that people good with talking, but have a vacuous argument tend to break apart when it is laid out in writing.
Yeah a lot of his arguments are for long term solution, the "perfect solution".
Real life example from last week. We needed quick turnaround for a JMS cluster to fix a P1 incident that has been haunting the business for a few weeks. Our other applications use file based persistence store on its own NAS.
I proposed we used JDBC backed persistence store - use our existing DB and just add the scheme. I work in a huge company, so new infrastructure for the NAS takes a while to get.
He was against it, said JDBC store is not performant. He wanted a new NAS, and the JMS cluster had to have its own dedicated resource, and not use the existing one (which my teammate proposed and was shot down by him)
That application would have a max of 10 messages on that queue per day to trigger a process...no performance needed really.
Forward to the next day, when he proposed his solution to operations. He got chewed up by another architect and the operations guy for a solution that requires a whole new NAS. They settled on using an existing NAS.
Quite a bit of details, hope my coworkers don't browse HN.
In terms of arguing, if you guys are going around in circles one good way is to write down the key points of the argument or merits on a whiteboard/paper. Like solution one offers 1) speed 2)cheap versus solution two offers 1) stability or something. I've always found that people good with talking, but have a vacuous argument tend to break apart when it is laid out in writing.