Let's agree to disagree

While doing design or architecture definition projects some clients can afford just one enterprise architect on the team and he is the final decision maker. However the matter complicates when there are multiple enterprise architects or solution architects. As everyone knows, we have wide range of options available in technological landscape; there are multiple ways of architecting a solution to address a business problem. Each architecture design may have different ways, methodologies and practices followed but it can very well achieve the business goal. In Microsoft Technologies itself there are solutions and products that do the similar things. They exist for whatever reasons and we don’t want to go in that discussion here. Those reasons can be valid reasons about their existence e.g. it could be for legacy support etc. The point I want to convey is when I am playing architect role as a consultant in various companies, I come across this conflict very often. Companies spend lots of $$ on discussing and arguing about “build vs buy”, one technology over other, one tool vs other etc. I always ask what are the company standards followed across the enterprise and go from there. But sometimes you need to be innovative to think beyond the best practices that exist because every application is unique. You cannot stop people from thinking differently. So discussion and arguments are bound to happen. It’s a very slippery slope to keep spending time endlessly on such things. 

That is why I see one important quality all architects can have is to “agree to disagree”. In Wiki this is defined as “To tolerate each other's opinion and stop arguing; to acknowledge that an agreement will not be reached”.