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”.
