How do you handle conflicting solution architecture advice?

My experience of over 3 decades: Stay Calm and Open-Minded: Approach conflicts with a calm and open mindset. Emotions can escalate disagreements, so encourage all stakeholders to maintain a respectful and cooperative attitude. Define Clear Objectives Encourage Transparent Communication Listen Actively Identify Common Goals Prioritize Business Impact Analyze Trade-offs Make the Decision (vs Take the Decision): At some point, being at the Top Management, one needs to make a decision after taking all the above into consideration. That’s what I have been doing. Manage Expectations: Communicate the decision to all stakeholders Document the Decision: Ensure that the chosen architecture and the reasons behind it are documented.

1. Clearly define your goals 2. Promote Open Communication 3. Pay Attention actively 4. Determine Shared Objectives All architects probably have the same objectives, even though their methods may vary: system performance, scalability, security, maintainability, etc. 5. Give Business Impact Priority Analyze the business effects of each solution architecture. Will productivity increase as a result? Cut expenses? Comply with plans for future growth? Examine trade-offs 7. Take the Decision Rather Than make It 8. Data-driven approach: If at all possible, use data to inform your choice. 9. Conceptual Proofs (POCs) Remember your long-term goals as you attend to your urgent demands. The "best" architecture is frequently the result of teamwork.

I usually assess the architecture options depending on Business context Data Lineage and Governance Org structure (Conway's Law) Security compliance Most architecture solutions should work given enough resources and funding. How reliably and toward what business value though is what has to be negotiated with conflicting solutions. This is the challenge as most teams and decision-makers seem to have mostly made up their mind on their version of the architecture by the time the end-2-end solutions is reviewed. Reaching an agreement on prioritized architecture characteristics based on business benefit and value should help negotiate the final architecture. Need solid scenarios to demonstrate this though.

We need to be clear on the following factors before even attempting the solution - What is the current ask - What is the bigger context to what this solution will solve - Who are the key stakeholders in the decision making and their high level understanding ( if any) - What is the understated NFR (Non functional requirements) that would be apt for the solution - Other aspects like scalability, maintainability, cost that will make the solution more viable in the long term. - Last , but not the least, the potential risks/challenges/limitation this solution will carry , and better to call it out upfront to ensure alignment and brainstorming at the initial POC level itself!

Conflicting solution architecture advice often stems from varying perspectives and priorities. To navigate this, consider the specific context, goals, and constraints of your project. Engage in open communication with stakeholders to understand their reasoning and expectations. Aim for a balanced approach that aligns with overarching project objectives. Ultimately, choose a solution that best suits the unique requirements of your situation.

Any solution architecture can be broken down to a set of architecture decisions (AD). Each significant AD should be analyzed with different options on the table against a set of key decision factors. You can put a score against how a given option supports each decision factor. Then you can use a simple or weighted summation of scores to get an objective idea of the strength/weakness of each option. This approach has worked wonderfully for me at an enterprise level at a major international bank as well as at a mid-sized organization.

Rarely is there one single "correct" approach. The decision-making process is a series of decision branches, and each one of those decisions can result in a very different path being taken. Generally I like to explore and present, even if only at a high level, a selection of possible approaches along with considerations, pros and cons, limitations and so on for each of those approaches. Budget and time constraints also play a part here - maybe the customer cannot afford the optimal pathway, or is constrained by some other business factor. OK, in an ideal world you would only use the best solution; but we all operate with such constraints on a daily basis in our own lives and should perhaps be more accepting of them in a business context

There will always be tradeoffs. Evaluate the pros and cons of each architecture advice and see how it impacts the problem at hand. For example, a specific architecture pattern may be exteremely performant but a lot more costly/difficult to maintain than the others. Does the problem needs such an expensive yet perfromant solution or can it be solved reasonably by a less complicated architecture at the expense of some performance penalty ?

No solution is bad or good. It needs to be measured in terms of maximum value benefit it will provide in the prevailing environmental limitations. Its better to do a SWOT analysis of all solution approaches, key parameters to be : Scalability Maintainability Cost benefit Security Ease of implementation tech stacks skills availability ( do we have right skilled developers to take on execution later) Once the analysis is done, its better to present it to the Architectural Forum ( internally or at the customer CTO office) to get the alignment on the best solution possible.

I would also suggest comparing Architecture spikes. There is a huge difference between boxes on a whiteboard or in a diagram and actual implementation. So many Architecture patterns and approaches bear the promise of some long term value, but to get there you have to demonstrate the path to building that approach and learn with the organization the cost and benefits to get there. You will probably give yourself a chance to pivot as well.

Stress test the architectures on the white board with local experts from tech and business. Suggest future scenarios and how the prposed architectures would fulfill the stated needs. Sometimes the choice is between a good and an inadequate architecture. Other times it's among good/better/best. Best is desirable but if the worst choice is "good", it's not a bad outcome.

You should think about the questions you will be asked and prepare yourself. Also maybe additional solution is needed - you can offer a choice and compare. Let the customer choose from your proposals, it works.

Selecting the most appropriate solution architecture is a crucial decision that requires thorough analysis and clear communication. Documenting your decision and being prepared to provide explanations for other potential architectures you've considered will help ensure transparency and alignment with your team, clients, and sponsors.

We all want solution architectures to be future-proofed, but we need to make architectural decisions that consider the forces of Time, Quality and Cost. The context and objectives influence the dominant force, and then the selection of a solution architecture option ultimately follows that.

Choose the architecture aligning best with context and objectives, supported by evidence, criteria assessment, and trade-off analysis. Document decision for transparent communication with team, clients, sponsors. Explain dismissal or adaptation of previously considered architectures based on refined evaluations. This last step of explanation is crucial, people have invested in the process with their time and energy, the last thing you want to alienate them by dismissing their preferred idea(s) without explanation, its a bad start to the project, a bad way to get future honest interactions and just bad form.

A key attribute of a successful architect is their critical listening skills. Architects that constantly try to sell you on their approach or interject a solution before understanding the context are sure signs of a naive or inexperienced architect. Take the time to learn, collaborate and document to a point appropriate for the problem, then share.

In the ever-evolving world of solution architecture, adaptation isn't just a strategy—it's a way of life. It's about more than just tweaking a few lines of code; it's a mindset that embraces change and innovation. Be Curious and stay Informed: Keep abreast of industry trends, best practices, and innovations, seeking inspiration from diverse sources. In the field of technology, it's about continuously learning, adapting, and evolving to meet the ever-changing needs of tomorrow.

Each phase of the solution development and implementation cycle contributes to an ongoing learning process. As challenges are encountered, solutions implemented, and outcomes assessed, there is a constant opportunity for enhancement. Lessons learned from previous iterations can inform and influence subsequent ones, fostering a cycle of continuous improvement. This iterative nature acknowledges that the landscape of technology, business requirements, and external factors is subject to change. Learn and Adapt based on emerging insights and evolving needs are integral to the philosophy of Solution Architecture. Iterative mindset enables agile solutions that align effectively with the ever-changing demands of the environment they operate in.

Though we start with an Intentional architecture, the feedback from the ground implementation to adapt the decisions and evolve, is ignored. It shouldn't be. Solution architects must be at the centre and close to implementation getting feedback from development and operations.

Is it really conflicting? Different architects can have different perspectives. Good ones will be honest about the pros and cons of their designs. Ask them. Then be clear about what you're optimizing for, or at least what your priorities are. - Cost? - Response time / latency? - Ease of use? - Upgradeability and maintainability? Etc.

This is the most important part in dealing with conflicting advice. Setup a few whiteboard sessions with technical support and subject matter experts and work through each scenario. Chances are you will find that some of the options may be technically challenging considering your current state and may require significant investment or rework to achieve the target state. This will help you eliminate some options and focus on least impact with maximum value at the lowest or reasonable cost.

This is an interesting and in-fact bit challenging situation to deal with. Often we get into situations even on client side, where IT-house would like to have the most effective, sustainable, scalable, available and modern architecture for long-term needs. But, the business-side of the house may not be willing/prepared to spend such big $tickets that it takes to. It then gets into peeling exercise and re-visting architecture multiple times to balance keeping in view of both the IT and Business constraints. We have to be clear in getting the 'must' to have objectives (including NFRs) and 'good' to have objectives. Prioritization of the features helps in this exercise. ROI view over time-line helps clients to socialize and get budget secured.

Projeto escalado! Nem sempre ocorre de um projeto vir como demanda e ter esse tempo para realizar os passos acima. Válido lembrar que por diversos fatores, seja por parte de negócios ou pela alta. Temos que desenhar e pular todas essas etapas conforme o texto acima.

Here are some great ways to get started: 1. Ask others if they are passionate and want to be part of the solution. 2. Facilitate a brainstorming session to collect ideas for further discussion. 3. Whiteboard out the ideas, focusing on keeping things as straightforward as possible. 4. Remember, difficult problems can take time to analyze and brainstorm for the best solution, and even then, build your approach to be malleable, flexible, and easy to change if needed.

Some enterprise best practices I found useful are: 1. To evaluate against established criteria, be it scalability, maintainability or cost aligned to organisational goals. 2. Document decision rationale which can be referenced in future due to iterative nature of architecture decisions.

Maturity of the Architecture Practice, Pragmatic Goal Setting, and Management in the Organization plays a critical role, without saying, in letting SA carrying out his responsibility with commitment and enthusiasm ??.

Being a solution Architect , I analyze each perspective, evaluate their merits based on the project's requirements and constraints, seek additional input if necessary, and make an informed decision that aligns best with the goals of the project.

The best thing about solving problems with technology is seeing the excitement and enthusiasm of identifying the solution and watching it evolve and become a reality for the customer. Having fun, enjoying the solution-creation process, and sharing your knowledge and ideas with others is a great and rewarding vocation and career.

Understand that building a system is an engineering process and not a craftsmanship. The goal is to experiment with each well defined user story for each part of the architecture. Do it with small steps for the nearest reachable target, don't try to go the full distance without knowing how your path is built.

These are the 2 methods, I always use: 1. Are their sound rationale presented and there is one that looks more convincing and relevant for the context of the problem? 2. If data or metrics available for the analysis and subsequent recommendations, look at that. Like in other decision making process, it’s an art than exact science and you have to use a mix of the above thought process and your own experience to reach a conclusion. Then always learn and enrich for next one!

In case a careful analysis is needed there is always an option to use one of the standard architectural evaluation methods such as ATAM or SAAD. The essence is to identify critical attributes and scenarios from the context that which the solution is to be used in. The performance against the identified attributes such as performance, resilience etc. in the usage scenarios then forms the basis of the tradeoffs. The right set of tradeoffs in a collaborative way can then become the basis for the selection among conflicting choices. The identification of attributes and scenarios builds consensus

Few recommendations: Understand the situation from all point of views, Evaluate the solution with appropriate weightages liasing the Pros and Cons of the solution proposed. Be open to accept changes and have a growth mindset. The solution proposed should be measured against the problem statement if our solution is meeting the goal . Having good listening skills is the key

One of the technique is Prototyping: Utilize tools that allow you to quickly create prototypes or mockups of the conflicting solutions, enabling visualization and better understanding.