How do you foster a culture of software architecture evaluation in your organization and team?

In my experience, you can follow these 1. Training and Workshops: Conduct regular training sessions and workshops to enhance the team's understanding of software architecture principles and evaluation techniques. 2. Gamification Strategies: Implement gamification elements, such as challenges or competitions, to make the evaluation process engaging. 3. Peer Reviews and Collaboration: Foster a culture of mutual learning by encouraging team members to participate in collaborative code reviews and share architecture insights with each other. 4. Incentive Programs: Introduce incentive programs that recognize and reward individuals or teams demonstrating excellence in software architecture evaluation, motivating continuous improvement.

It's important here not to fall into the trap of creating a super fancy comprehensive evaluation system but clearly define a bare minimum you need.

Architecture decisions often involve trade-offs. For instance, optimizing for performance might impact security, and vice versa. Teams need to weigh these trade-offs consciously. Having open discussions about pros and cons helps us make informed choices. Trade-offs are inevitable, but they shouldn’t be surprises. By discussing trade-offs transparently, we build trust and ensure that decisions align with our overall goals.

If we are in an environment far from the software architecture evaluation culture, this task can become challenging, confusing and difficult to carry out, because if we do not have this autonomy this can become something delicate, as such an initiative can be interpreted as a distraction and waste of time. We don't want to interfere in something that isn't our business and end up being misunderstood. So, in this case we will start to define the objectives and evaluation criteria for our own work and then we will start to discuss this with co-workers. This will help identify enthusiasts and they are key to promoting the most appropriate culture for the entire development environment. That said, balance high priorities and long run goals.

3 big questions that is really important to define are 1. Where are we 6 mos ago 2. Where are we now 3. Where do we go next. Answering this 3 will provoke the stakeholders and team to give more importance to the evaluation. For example, you are at 1k users 6 mos ago, 5k users now, and goal of 20k in the next 6 mos. This immediately shows the importance of evaluating of the system is still aligned with company goals.

The choice of tooling impacts the team’s progress. Therefore, the direct or indirect participation of the entire team in this process is important.

We adopted the ATAM for architectural evaluation and supplemented it with tools like SonarQube for code quality assessment. These methods and tools have helped us maintain a high standard in our architectural choices and keep the technical debt in check.

ATAM (Architecture Tradeoff Analysis Method): is primarily focused on analyzing the trade-offs among quality attributes (such as performance, modifiability, security, etc.) in software architectures.It involves a series of steps including defining quality attribute scenarios, evaluating architectural approaches, identifying architectural approaches, and analyzing architectural approaches.The outcome of ATAM is a set of trade-off analyses that helps in making informed decisions about the architectural design.

When selecting methods and tools for promoting software architecture evaluation, it is essential to consider the following criteria: - Align them with the organization's business objectives, system complexity, and team expertise. - Utilize formal methods like ATAM for complex systems and lighter approaches for simpler ones. - Prioritize iterative methods and tools that can be integrated into CI/CD pipelines, such as SonarQube or Structure101, to facilitate continuous feedback. - Choose tools that provide measurable insights, engage stakeholders, and adjust methods based on the system's life cycle stage. - Strive to balance flexibility for innovation and rigor for critical systems to ensure practical and ongoing architectural evaluation.

Select appropriate methods and tools for architecture evaluation that suit your organization’s size, complexity, and specific needs. Methods such as Architecture Tradeoff Analysis Method (ATAM), Scenario-Based Architecture Evaluation, or Cost Benefit Analysis Method (CBAM) can be useful. Tools might include software design modeling tools or static code analysis tools that help in assessing the architectural quality. Choosing the right methods and tools is crucial for effective evaluation and achieving meaningful insights.

It’s hugely beneficial to have a cross functional review team / arch board in addition to engineers, architects , delivery leads , product managers it’s extremely vital to have security experts, production services , operational process experts in the mix. From practical experience, I can say with such a cross functional and right participation the product or programme gets rich and diverse insights and perspectives which greatly enriches the outcomes.

One common mistake for hundreds of organisation - excluding technical team and developers from stakeholders list. Development Experience, cognitive load , maintainability , likability of tools and attractivnes of tools and technologies is all part of architecture and tech strategy

Involving the relevant stakeholders ensures diverse perspectives, promotes transparency, and enhances collective ownership of architectural decisions. This inclusive approach not only improves the quality of evaluations but also cultivates a culture of continuous improvement and learning within the organization.

We made it a point to include not just our dev team but also operations, support, and marketing in our architectural discussions. This holistic approach ensured that we considered a wide range of perspectives, which led to a more resilient and market-aligned architecture. The challenge here is to make sure that everybody is on the same page and have the same understanding of what the current goal is

Encouraging stakeholders to promote a culture of software architecture assessment involves the following steps: 1. Identify relevant stakeholders, including technical teams, business units, and executives. 2. Communicate the value of assessments that align with their concerns, such as reducing risk, improving quality, and meeting business goals. 3. Engage stakeholders via workshops, feedback loops, and demos, utilizing collaborative and visualization tools to ensure clarity and active participation. 4. Provide training to fill knowledge gaps and align assessments with organizational objectives. 5. Recognize and reward contributions to foster engagement and establish a collaborative culture around architecture evaluations.

When communicating the results of software architecture evaluations, it is essential to consider the following points: 1. Tailor the message to suit the audience, i.e., providing detailed technical insights for technical teams and focusing on business-oriented outcomes for stakeholders and executives. 2. Present the findings using visual aids and data-driven metrics, emphasizing actionable areas for improvement and the resulting impact on system performance. 3. Encourage open discussions via workshops and Q&A sessions, document the results, and provide frequent progress updates. 4. Recognize team efforts and utilize success stories to demonstrate the long-term benefits of evaluations and emphasize the importance of architecture assessment.

I think that transparent and clear communication of the results and corresponding actions fosters a culture of accountability and learning within the organization. Sharing outcomes, insights, and follow-up steps promotes awareness, encourages constructive feedback, and reinforces the importance of ongoing software architecture evaluation as a collaborative and iterative process.

Transparent communication post-evaluation is key. We use dashboards to share results and planned actions across the company. This visibility has fostered a sense of ownership and understanding across all levels, from developers to executives.

Once evaluations are completed, clearly communicate the findings and planned actions to all stakeholders. Use meetings, reports, and presentations to discuss the outcomes, justify the decisions made, and outline the next steps. Effective communication ensures transparency and fosters trust in the evaluation process, encouraging more engaged participation in future reviews.

Communicating results and actions from your software architecture evaluation is key. For example, if you find security gaps, explain the issues—like outdated encryption—and recommend fixes, such as using AWS Cognito. Document the rationale and share with stakeholders, inviting feedback, especially if decisions impact budgets or timelines. Track the implementation and monitor how changes—like a shift to microservices—affect performance to ensure you meet your goals.

I propose below as an overall process for an organization. Promote Awareness and Importance Provide Training and Resources Encourage Collaboration and Discussion Establish Architecture Review Processes Provide Constructive Feedback and Learning Opportunities: Recognize and Reward Contributions Choosing appropriate architectural practices and embracing those into the projects and product development will be the leadership's responsibility. Refer to the below criteria when assessing the ROI 1. Type of the project: greenfield development, maintenance project 2. Life Cycle of the project - which stage the project is 3. Lifetime of the project 3. Scale of the project 4. userbase 5. 80:20 rule

1. Don't try to embrace the whole world at once. Cherry pick the goals and criteria. Once achieved, they can expand. 2. Costs and customer experience are good metrics for evaluating architecture performance. 3. A realistic roadmap and frequent alignment of expectations would help us understand the trade-offs and risks involved.

To foster a culture of evaluating software architectures, a framework-based approach can be leveraged. Key elements of such a framework can be: Architecture Foundations, Static & Dynamic Analysis tools, Alignment with business goals, Architecture Review board, Technology trends, dependency mapping, NFR's, architecture review methods

Encouraging evaluation of software architecture is essential for integrating it as a critical part of the team's workflow and enhancing system quality and decision-making. The process involves the following steps: 1. Educating teams through training and sharing success stories. 2. Establishing a standardized process with clear evaluation milestones and templates. 3. Fostering a collaborative review culture by involving cross-team reviews and stakeholders. 4. Promoting continuous feedback through automated tools, retrospectives, and DevOps integration. 5. Recognizing and incentivizing evaluation efforts and ensuring leadership actively supports the practice by allocating time and resources.

In my experience, you could benefit from setting up a feedback loop: -Reframe architecture as something that is continuously changing. -Ensure there is a continuous feedback loop that provides measurements such as defects, issues logged, deployment pipelines etc. etc. -Measure only what you can and what is necessary for making arch changes. -Establish a cross-functional architecture team to assess the measurements on an ongoing basis and suggest what, where and why to incrementally change the architecture. Finally, you implement the changes and the feedback loop continues. The end result will be a culture of continuous( self-)evaluation of the architecture because this organization has a built-in feedback loop.