You're faced with conflicting opinions on software architecture. How can you steer towards the best approach?

Mostly business and technical teams are focused on fast delivery and focused on latest developments trends and overlooking the nonfunctional aspects which becomes the after thoughts. These mistakes are very expensive and need a lot of migration efforts to fix these problems. Hence finding the performance and transaction needs the initial phase of the project to avoid expensive correction

Exactly. Understanding the user requirements is the key. What value we are trying to deliver and what would be the scalability required going forward would be pivotal. In the world of ease, seamless integration of different services, ease of use, zero downtime are essentials. All the architectural decisions should be based on these deliberations.

Key to such a problem is gathering as much data as possible. Understand and capture functional and non-functional requirements in detail. Sometimes it is non-functional requirements which impact your architecture more than your functional requirements. Consider all possible options on table, come up with pros and cons of each architecture style. Talk to various stakeholders to make sure all possible requirements are met. Document your possible approaches. Create a prototype and evaluate it against your non-functional requirements. Learn and adapt from each iteration of prototype.

It is quite easy to get lost in the sea of "best practices" and be lured to go with the current industry trends. I have personally witnessed people enthusiastically pushing for Microservice architecture without considering the return on investment (software costs money!), tradeoff between architecturally significant requirements and finally going back on the decision after wasting quite some time and effort. Understanding the target user, environment along with requirements is key to easily evaluate different architectural opinions. Sometimes the best of options may not be suitable to our needs.

É essencial fomentar um ambiente onde as pessoas se sintam livres para expressar suas preferências e opiniões. Embora o consenso seja valioso para o time, há momentos em que alguém precisa assumir a responsabilidade pela decisão. Mesmo que uma sugestão não seja escolhida, a pessoa ainda se sentirá parte do grupo, desde que esses princípios sejam respeitados

I completely agree with this perspective. Every architecture is a balance of trade-offs, and no solution is universally optimal. The key lies in understanding the specific priorities of the project. In short, this approach emphasizes pragmatism and alignment with long-term goals. By evaluating trade-offs in the context of the project's immediate and future needs, you can make architectural decisions that best support its success.

In my experience, software is all about tradeoffs. Be it technical tradeoffs, organizational tradeoffs, regulatory tradeoffs or financial tradeoffs. Each and every architectural decision must be based on the thorough evaluation such tradeoffs. Designing for security from ground up could be a non-negotiable ask for a banking software, whereas a search engine might consider performance as its top priority. What helps to keep in mind is that each Software Quality Attribute (SQA) has an effect on the other. For example, enabling security will almost always cost some performance. Therefore, it is not only essential to evaluate tradeoff, but also paramount to keep in our mind that any SQA will have positive or negative interaction with another.

It's not just about recognizing what you gain or lose, but about understanding how those trade-offs will impact the system’s evolution. A good architect must look beyond immediate project requirements and forecast the long-term effects. For instance, choosing a microservices architecture might seem beneficial for scalability, but it could introduce complexity in deployment and inter-service communication. The key to successful decision-making is to prioritize trade-offs that offer flexibility for future modifications while keeping core system stability intact. By conducting regular reviews and iterating based on changing user needs or technological advancements, architects can ensure that their design remains robust and adaptable over time.

Tradeoffs are often a very good way to understand which requirement weighs more over another one. In my experience, choices of the architectural design are always done based on the core requirements or business values.

Seeking expertise is a great suggestion, but the question is - from whom? There are many people out there self-titled xxxx architect (yes I'm one of them). However, the challenge is to find someone who really does understand your business and technical problems, and brings real experience from the field as opposed to armchair/ivory-tower views. Do some research into your potential consultants - price is not the only factor. And consider crowd-sourcing as a possible information feed (polls on LinkedIn, questions on StackOverflow, etc.).

One of cornerstones of software architecture - architectural patterns, is based entirely on the fact that someone has solved a given problem with a context in a better way. As developers or architects, we have to be open to seek advice from experts or communities to minimize our blind spots. The best of designs can lead to pitfalls and one of the best ways to mitigate is to involve industry experts during architectural reviews. Qualitative architectural review techniques (Active Design Review, Architectural Tradeoff Analysis Method, Industry Practice) also called Experience Based reviews can provide meaningful insights to "am I designing it right?".

To leveraging external expertise isn’t just about resolving debates; it’s about enhancing the depth of understanding in areas you may not have direct experience with. By bringing in domain specialists and cross-functional experts, you gain access to a broader range of design patterns, failure scenarios, and scaling strategies that have been tested in similar environments. Expert advice can prevent costly missteps by exposing blind spots early in the process. However, it's crucial to approach this knowledge with an open mind while tailoring it to your project's specific constraints and goals. Expertise should be seen as a guiding light that informs your decisions without overshadowing the unique requirements of your system.

Seeking expertise is itself a skill also. Its quite logical that if someone already solved a problem we can seek help to understand their perspective and build our solution from there.In architectural terms we call this concept as Architectural pattern where we can reuse the solution which saves lot of resources.

Consensus building is a fallacy that extends decision-making time. If you have done the above, it is time to get decisive about where to start. If the conflict about the approach is between people of roughly equal seniority and authority, allow someone much more junior on the team to make the decision based on who can communicate it better; The solution may not necessarily be the platonic ideal, but if everyone contributing has viable ideas, the critical solutions will be obvious to someone who has less experience and the ability to communicate the idea will be essential to execution long term, making the idea fundamentally better.

Melvin Conway in 1967 described the synergy between communication in an organization and the designs they produce. In our case, it loosely translates to - "your architecture is doomed to reflect the communication in your organization". Creating a safe space in the team where everyone can freely express disagreements is important to foster collaboration and bring out the best ideas. There may always be non-negotiables (e.g. geo redundancy for database or high availability for military or aviation software), however, such decisions or ideas should be fully explained and backed by architecturally significant requirements or other constraint (e.g. regulatory).

Consensus building is essential,but it’s not about compromising on every decision, it’s about driving towards a shared understanding and commitment. As an architect, facilitating discussions with structured frameworks like architectural decision records (ADRs) can document key choices and the rationale behind them. This not only provides clarity but also creates accountability. Moreover, using consensus-building techniques such as the ‘Gradients of Agreement’ model allows the team to express varying levels of support for a decision, ensuring all voices are heard while avoiding deadlock. Ultimately, fostering consensus is about empowering the team to take ownership of the architecture while ensuring alignment with the broader business goals.

I believe prototyping is a powerful way to evaluate conflicting architectural choices. It transforms discussions from "what might work" to "what works best for us," providing clarity and confidence in making decisions.

Prototyping isn’t just about building a basic version of the architecture — it’s about stress-testing your assumptions in the harshest conditions your system is likely to face. It's critical to simulate not just typical usage but edge cases that may challenge the system’s resilience and performance. Prototype testing should include scenarios like peak load, network failures, and security breaches. Additionally, leveraging automated testing tools to simulate these extreme cases can expose latent issues that may be missed in typical testing environments. The insights gained from this rigorous approach to prototyping can often mean the difference between a system that functions under ideal conditions and one that thrives in the real world.

Consider the difference between refinement and rearchitecting. Rearchitecting has much greater implications, so be mindful of the scope of changes.