Como você justifica os projetos de soluções para tomadores de decisão e partes interessadas?

In my experience, it is important to setup architecture design review board to manage & discuss the solution architecture related points. - Draft solution architecture blueprint - enable reuse from other reference implementation. - Maintain Risk and mitigation trackers - setup change control management process. - evaluate potential Addons sales during discussion with customer. - showcase the value that new solution will bring into the organisation.

No matter who you are presenting to, you need to address the following: 1. Business drivers 2. Domain alignment 3. Current state 4. Target state conceptual architecture 5. Target state reference architecture 6. Capabilities roadmap 7. Portfolio changes (Add/Retire tech stack) 8. ROI 9. Investing for the future (Tech and Business expansion) 10. Provide clear guidance on investment programs overtime that will deliver value incrementally using FIXED capacity budget model. Predictability is key 11. Review quarterly

Unlocking the gates to decision-makers' approval requires a master key: know your audience. Imagine them as unique puzzle pieces, each craving a tailored understanding. As a solution architect, I've discovered that justification isn't just about data; it's a narrative sculpted with empathy. Picture your stakeholders as co-authors, and your design explanation as a shared story. It's not a monologue but a dialogue, where their concerns and aspirations are the protagonists. So, craft your justification as a personalized journey, where every decision-maker sees not just a design but a solution aligned with their narrative.

When presenting to the C-suite, I usually dwell on key areas of interest. One them is technical feasibility, evolution, scalability and backward compatibility of the design. Second, I have to outline the business impact of the proposed solution including the investment required, ROI, the TCO for the client and company and well as projected support and maintenance requirements. Finally, I address the contractual and compliance obligations that arise out of the design. This usually covers the required licenses and compliance with regulators and, SLA with clients and suppliers and well other 3rd party integrators.

Customize Your Presentation Format: Different stakeholders have varying preferences for how information is presented. Some may prefer a formal report, while others may prefer a more visual presentation. Be flexible in your approach and adapt to the preferences of your audience. Align with Strategic Goals: Clearly articulate how your solution aligns with the organization's strategic goals and long-term vision. Decision-makers are more likely to support solutions that contribute to broader objectives. Demo or Prototypes: If feasible, provide a demonstration or prototype of your solution. Seeing a working model can be very persuasive in convincing stakeholders of its feasibility and value.

In creation of the visual materials it is also important to adjust them accordingly to the group of people that will be recipients. That means: - select right amount of details - as different people will be interested with more breadth and shallow view as opposed to deep details. - select the right amount of information on one view - as an example the senior management will prefer more loaded view with many information due to their short attention span - select the right information - as recipients will be interested in information form their field mor than from yours.

Visual Aids Improve Comprehension -- That's a fact!! If you're 30 mins into a discussion with stake-holders and you haven't started sharing your screen... there's a reasonable chance that you lost your audience ~20 mins ago. Im a strong believer of customizing visuals to the audience. I have a framework that goes like this Non-Technical Leaders - High-level conceptual architecture and value-prop bullets/graphics Technical Managers - High-level technical architecture with value-bullets that explain how it helps them and their team Architects - Low-level design diagrams with implementation timelines, value messaging and milestones Engineers - Low-level design diagrams, code examples and demos

Whilst visual aids are a great way to showcase what you are planning to implement, it creates a challenge. The challenge where everyone becomes a designer. Whilst user input is valuable, often users think from their own limited perspective and start dictating design components that are more “good to have” as opposed to “must have” or “fit for purpose”. As long as the narrative around the feasibility of the design and the overall value the initiative will add to the organisation is kept in mind, this is a great way to keep everyone informed, engaged and excited about the initiative.

When presenting solution architecture design, visual charts play a crucial role in conveying complex information effectively. Include the business problem statements, business vision, business capability impact and use standard notations

Visuals are a key part of the solution design. However it needs to cater for the varied audience. Some common standard visuals are, As-Is , To-Be, Capability mapping to the Reference Architecture.

The principle of ‘seeing is believing’ always works when it comes down to building trustworthiness of stakeholders for the proposed solution architecture. Building the proof of concepts (POC) in the system as part of your solution demonstration opens up better feedback loops in the initial stages of solution.

As an evidence you can also use well defined frameworks and tools well known in the industry. Often selection of well known tool will increase your credibility.

Some of the real challenges comes from mapping the data evidence into real value into the stakeholders view- representing such it in quantitative vs qualitative form. Other considerations would be the qualities of data evidence like accuracy, scope, timeliness,completeness,reliability,relevance. Getting reviews across before proceeding to conclude is most essential and often neglected.

Absolutely, providing evidence and data-driven support for your solution design is essential in building a compelling case for your design choices. It adds credibility and demonstrates that your design is grounded in research and best practices. When presenting evidence, it's important to ensure that your data is up-to-date and relevant to the specific context of your project. Citing sources and explaining your data collection and analysis methods can also help your audience trust and understand the basis for your design decisions. This is particularly important in solution architecture where decisions can have a significant impact on the organization's success.

The context and constraints of the solution can vastly change the proposed solution. Understanding the clients’ needs and expressing how the solution fits into their limitations and standards is crucial to successful adoption and exceptional delivery.

Sharing a proper summary of the solution implementation process can definitely contribute to the solution’s overall credibility.

You're absolutely right. Providing a clear and well-structured rationale for your solution design is essential in gaining buy-in and support from stakeholders and decision-makers. It helps them understand the reasoning behind your decisions, the trade-offs you considered, and the implications of your design choices. Being able to articulate your rationale in a clear and concise manner is a valuable skill for solution architects, as it not only justifies your design but also demonstrates your ability to communicate effectively with both technical and non-technical stakeholders. This can be a critical factor in the success of your architecture proposals.

Before you present a solution architecture to an audience consider the following approaches: - if your audience is available before the meeting to you, try to pitch outlines/ parts of your solution to them individually. Especially focus on complex or critical topics for these stake holders in the discussion. That will help reducing lengthy and detailed feedback discussions in a bigger round. - if your audience is not available to you, try to understand their concerns prior to the presentation and run the presentation with peers in similar positions. Ask them to play devils advocate so that your presentation/solution is successful with the real audience.

Feedback is indeed a crucial component of the solution design process. It not only allows you to gather valuable insights from your audience but also fosters collaboration and engagement. In addition to seeking feedback during and after your presentation, you can also consider incorporating feedback mechanisms into your ongoing design process, such as by conducting design reviews, design thinking workshops, or usability testing. This iterative approach to design, where feedback is continuously collected and applied, can lead to more robust and user-friendly solutions.

Inviting feedback is one of the ways to make a presentation interactive. A presentation can be interactive from the very beginning to ensure the best alignment with the audience’s interests. An interactive presentation requires more preparation with options for the different potential directions the audience may want to go.

I think Every solution which we were design for stakeholders are Having some Key benefits, improvements plan, budget controls, and security. In my point of view we should gives the Dry Run to All relevant stakeholders Not Only who raise the initiative because sometimes might be we resolve or solved the direct stakeholders initiative might be our solution impacted to other business processes or stakeholders. Every Process Improvements initiative should be reviewed by Business Steering Committee and the Committee also reviewed the solution jointly not in silos. It's better that Improvement Committee member are different from Process Improvement Committee members. Thanks.

Focus on the Value delivered for your Stakeholders Communicating the design to the Stakeholders it should support delivering value for their individual areas. The Stakeholders will naturally look for gains to their fields. It is a good practice to answer the question: “what’s in it for me?” for each Stakeholder. Understanding the value delivered to each of the Stakeholders will help you gain their buy-in during the Change Management process that occurs with every Architectural Change (at different levels).

Good article. I would focus a little more in strategic alignment and understanding business requirements, this of course result in capabilities mapping and Business process design.

To secure approval for selected solution, precisely define the problem and objectives. List all the design options considered, explaining why others were not suitable, include feedback from Architecture review board (ARB). Delve into your chosen solution, emphasizing its benefits with data & ARB recommendation. Foresee concerns and address them in advance. Mention briefly the long-term advantages. Customise the message to suit stakeholders and decision-makers. Employ visuals, maintain clarity and confidence, and encourage questions. This approach will successfully justify the selected solution and garner support from all parties involved.

Understand the concerns and priorities of different stakeholders. Tailor your communication to address their specific interests and show how the solution meets their needs. Discuss alternative solutions considered during the design process and explain why the proposed solution was chosen. Acknowledge potential risks and challenges associated with the solution.