Here's how you can navigate conflicts between technical approaches as a software architect.

Truth be told, Technology is a supporting function. To be prudent enough, technology is a tool-set to achieve business outcome. If there is no business, technology in isolation will not count. As an prudent architect, I need to appreciate business outcome and improve empathy what business needs to achieve. Approaches and strategies such as Minimum Viable Architecture, Evolutionary Architecture can be leveraged based on business input triggers.

More often than not, there are multiple ways to slice a cake. Choosing the most suitable approach for the organization or project should not be an emotional decision but a trade off decision made with facts, assumptions and reasoning.

Absolutely, technologies serve needs and needs come from the business we're supporting, from end users. Grasping the business contexts is the first thing to do before taking or changing any technical decision.

As a software architect, you compare and evaluate technical approaches with certain objectivity. You will compare the options on different parameters like Go-To-Market time, tech-debt / potential new tech-debt, NFRs like resiliency, scalability, stability or maintainability, phase-wise approach vs big-bang approach and reusability vs redundancy etc. and based on weightage and score of each parameter you can decide the best option.

Engage with stakeholders to gather insights into what the system needs to achieve. Consider scalability, performance, security, and other non-functional requirements. What works for a small-scale application may not be suitable for a large-scale system. Then you need to evaluate the objective by examining the technical options objectively. Avoid personal biases or attachment to a specific approach. Create a matrix or decision tree to compare alternatives based on factors like performance, maintainability, cost, and alignment with project goals. Assess maintainability. Is the solution easy to maintain, debug, and enhance over time? Avoid overly complex designs that hinder future changes. Evaluate the skillset by evaluating expertise within.

Make an open workplace. People should be open to talk and discuss about their thoughts about the product, technology they are using and features, which they re building. This brings crucial feedback loops and diverse thoughts to the product and team as a whole.

A decision framework is required to remove subjectivity. . This is more critical for architecture patterns / platform evaluations as sometimes all options are correct but we need to arrive at optimal solution with competing pragmatic parameters. 1)Enable and empower customers with evaluation considerations and use case weights 2)Any framework(s) are only point in time and one needs to perpetually adapt due to rapid technological evolution 3)Identify who needs to review architecture - look at consumption persona centric 4) Involve business stakeholders considering imperatives and future proofing strategies . Key is not arriving at a final consensus which can be progressively elaborated without rework or business interruption !

Clarity of communication is crucial for resolving conflicts. One such example I remember is using c4 model for our architecture diagrams. This will communicate the idea of a software system from a high level, which can be understood by a non technical stake holder to digging deeper into minute details.