How do you improve your software architecture quality?

Architecture review peocess ensures that it meets the short term business objective and also aligned with long term organizational strategic objectives. Regular review helps to identify the leaks if any. It also helps to identify and addresses potential risks, ensures that the architecture is feasible, improves the quality of the architecture, and promotes communication and collaboration.

Software is never done, so you need to track your metrics to prevent architectural regression. Besides metrics for cohesion, coupling, and functional performance, architects must also keep an eye on the DORA metrics from the DevOps domain. According to Conway’s law, every decision on the structure and interfaces of an organisation has an impact on your software’s structure and interface and vice versa. That means that the improvement of the software architecture goes hand in hand with organisational evolution.

In my experience, one of the biggest reasons for reviewing architecture is to insure it still aligns with the strategic objectives of the business. Develop a plan that takes your architecture from its current form to one that better matches the direction the business wants to go in (e.g., from one that favors rapid change to one that favors efficiency). Help the business understand the impact their plans will have on the systems you’re building, and the trade-offs of each approach.

- always do the post-mortem review of architecture after successful pre-sale with team - ask stakeholders once a year about expected product/solution growth, then take this numbers with team - always include team-leads in architecture reviews, and if you have opportunity team members that would be implementing functionality.

Software Architecture should always be a team effort, and not a one/two person responsibility. Regardless of how "theoretically" efficient a "stack" is, implementation, expertise, and deployment to live will always tell you whether you are actually getting the benefit of it. Most of the time, we tend to "over-architect" everything, for the sake of "being in-compliant with the industry". However, this could cause a friction between the developer and administrators.

Adopt Architecture Design Records from day zero. This way, you can set a great example that people should consider more things than just best-practice architecture principles everywhere and explain decisions.

For me the main two principles are high cohesion and low coupling. And that based on “Domain” (separation of concerns) The other principles like modularity, abstraction, encapsulation are ways to achieve the low coupling and high cohesion. Using the ISO 25010 as quality guides.

Adherence to software architecture principles is essential for developing robust, scalable, and maintainable software systems. These principles enable easy adaptation to evolving requirements and emerging technologies. They also help prevent common pitfalls and anti-patterns, ensuring the integrity, performance, and security of the software. By guiding efficient problem-solving, these principles contribute to a well-organized and long-term maintainable system, laying the groundwork for higher-quality software products.

Applying software architecture principles offers a structured approach to enhancing the quality of your software architecture. These principles, like modularity, cohesion, coupling, and encapsulation, guide the design process and decision-making. They ensure that your architecture is easy to comprehend, modify, and test while preventing common pitfalls and anti-patterns. Ultimately, they contribute to creating a more maintainable, reusable, and higher-quality software system.

Flexibility emphasizes the importance of accommodating future changes, while orthogonality minimizes dependencies and promotes clarity and maintainability. Consistency ensures uniformity, and scalability ensures the system can handle increasing loads effectively. Performance optimization maximizes resource usage, while resilience ensures the system can gracefully handle failures. Evolvability enables the system to adapt to evolving requirements, while integrity ensures data and operational security. Finally, prioritizing user experience and usability is essential for ensuring the software is user-friendly. By adhering to these principles, developers can create software architectures that meet the evolving needs of users and stakeholders.

Effective documentation should be: - Clear - Easy to understand writing and presentation. - Findable - Easy to locate and surfaced proactively. - Actionable - Empowers task accomplishments. - Relevant - Focused on readers' needs and goals. - Accessible - Considers diverse user needs. - Trusted - Accurate, complete, and timely information.

Automate and version control your architecture! * Use tools like Terraform to document and VC your cloud resources. * Kubernetes and Helm deployment config files will document your microservices. * Do you find YAML files hard to read? Use tools like cdk8s to document your k8s as source code, and make sure to throw that into your git repo! * Use tools like ArchUnit to ensure your application architecture is being followed. * Treat these artifacts (ArchUnit unit tests and configuration files) as if they were documentation. * Use embedded mermaid.js diagrams within markdown documents version controlled in your code repo or a dedicated docs repo. Good documentation defined in config files, source code files, and version controlled is a win!

Always start small with documentation as code and use at least ADRs for key components of your system. Automations like automatic diagram creation from your cloud infrastructure are super helpful and allow you to keep changes in check and control what is going on. Tools I used are Brainboard and Firefly for overall control. And unfortunately, sometimes you will not be able to escape Architecture Review Board documents :)

Documenting your architecture is essential for several reasons: 1. Communication: It serves as a means of communication between stakeholders, developers, and team members, ensuring everyone understands the design and decisions made. 2. Onboarding and Training: New team members can grasp the architecture quickly, accelerating their onboarding process. Documentation aids in training and knowledge transfer within the team. 3. Maintenance and Updates: It provides guidance for maintaining and updating the system over time. 4. Risk Mitigation: Documenting potential risks, trade-offs, and design decisions helps in evaluating the impact of changes and mitigating risks effectively.

Documenting is one of the most often misunderstood concept in the software architecture, development, and deployment. It is both boring, felt unnecessary, but on a certain situation, becomes critical when catching some issues. Having a simple but decent documentation, where developer can refer to easily understand and able to use to trace-back a scenario is more valuable than a super-fancy when the use of it is for reference, and not as a public document.

Refactoring typically involves enhancing the design of existing implementations or capabilities and adjusting their functionality. The primary objective is to address issues related to capability design or implementation. This process varies in complexity but is aimed at remedying any undesirable attributes, redundant implementations, fallouts, or leakage in capabilities. However, if there's a realization of the need for a transformative shift in business processes or a significant technology upgrade to enhance the company's capabilities and scale of operations, re-architecting may be necessary. The focus should be on enhancing business value chains by strengthening both technology systems and capabilities.

Be extremely careful with architecture and refactoring on the projects that are a few years old, because it might be time to consider previous decisions, check ADRs and maybe start some parts from scratch and with a different stack.

Refactoring your architecture is crucial for several reasons: 1. Maintainability: It improves the architecture's readability and organization, making it easier to understand and maintain over time. 2. Scalability: Refactoring can eliminate bottlenecks and architectural constraints, allowing your system to scale more effectively as demands increase. 3. Adaptability: It enables your architecture to adapt to changing requirements, technological advancements, and business needs more efficiently. 4. Reduced Complexity: Refactoring helps in simplifying complex structures, reducing unnecessary components. 5. Performance: It can optimize system performance by addressing architectural inefficiencies or bottlenecks.

It is very important to keep in mind that businesses will sometimes evolve in different directions, and in some rarer cases, even the strategies may change. For that reason, there is an excellent case for checking periodically if a given architecture is still meeting the requirements that once made them come into place as well as if there is any new requirement that should be taken into consideration. Architectures should always be able to evolve, thus, refactoring them is as important as refactoring code itself.

Architects need to balance refactoring and progression on features. You often come to a point where it’s better to rebuild a part instead of re-wiring. Your ability to do so depends on how well you have modularized the system. For instance, with micro services your chance are better to change parts without impacting the unchanged ones. Sometimes, you can only disrupt from a beaten path by a pattern where you wrap the old into new, which is called a strangler fig.

- Ask your peer architects for an informal review of your architecture. - Keep your ego at check, and do not hesitate to ask for feedback from the team that implemented your architecture down the line. You will get some bashing and will make better decisions in the future. - Attend industry events in different stacks so you will be aware of what is going on with the front end, etc. - Meet new people at conferences, talk to the speakers of talks that you are curious about, and follow them

Learning from others is one of the best teacher, maybe much more than a structured lesson / guides you see all over the internet. Yes, each scenario is a different one "no same shoe fits all". Adapting to the best practice is not always the right answer, but can definitely deliver value to the product. You will never know if the scenario you are currently encountering is an isolated case if you keep a close-minded approach. Be open to suggestions but don't trust blindly.

Refactoring your architecture is essential for enhancing its internal structure and quality without altering its external behavior. By making small, incremental changes, you can reduce complexity, eliminate duplication, improve cohesion, decrease coupling, increase modularity, and enhance readability.

If a team is unfamiliar with new technologies, and the opportunity allows, use smaller projects to try out, review and evaluate these technologies. Not only is it a safer space to experiment, the cost of failure is lower. If you shy away from experiementing and learning new technologies in these scenarios, one day you may be faced with the harder challenge of being forced to learn and implement them on a core part of a system if the old technologies reach their limitations on functionality, scale or performance.

Experiment with new technologies, yes. Try them out in isolated environments and only incorporate them when they’ve been validated, yes. Chase the latest fads, no. Launch a new architecture without vetting it, no. It’s also important to note that any tool becomes another thing to integrate and maintain. If you’ve ever seen a system that has three ways of doing things, it’s because two new methods were introduced without deprecating or transitioning the old ones.

Be playful with new technologies, they are your chance to overtake where others will remain in a grey past. But you need to watch out for risk of a hype and the challenge that you won’t find employees for a bleeding edge tech in the beginning. Still, experimentation is important even though you might not adopt a certain piece of technology eventually. The learnings that you experience in the process are still extremely valuable.

Exploring new technologies is a great strategy for enhancing software architecture quality. By delving into fresh frameworks, languages, or tools, you open doors to innovative solutions. Experimentation through prototypes or proofs of concept helps assess feasibility, benefits, and drawbacks before implementing them in your main system. This approach keeps your architecture current, innovative, and competitive, ensuring it remains adaptable to emerging trends and capable of leveraging the latest advancements in the field.

Experimentar significa conhecer, conhecer por sua vez exige a prática, o que ao fim gera conhecimento. Ou seja, temos um ciclo de aprendizado que leva à finalidade de inovar e otimizar. O ato de experimentar novas tecnologias segue esta filosofia, fazendo com que seja possível aprender sobre novas formas de solucionar problemas do passado, atuais e futuros. A inova??o é fruto do estudo e do compartilhamento de informa??o; ao experimentar o desenvolvedor necessita sair de sua zona de conforto e buscar novas práticas, pessoas e consequentemente tecnologias, o que faz com que novas arquiteturas (muitas vezes melhores) sejam criadas, ou arquiteturas existentes sejam refatoradas. é um ato contínuo de Desenvolver, Experimentar, Testar.

Keep any reference architecture in sync with the actual systems. Because that is often difficult to do, we could explore architecture-as-code, where architectural specifications generate code.

Don't create architecture in a silo. Always brainstorm or review with a team to spot gaps and ways to improve. Consider how your architecture will scale through the years and whether it's dependent on a vendor. What happens if your vendor quits supporting this service? Can you plug and play, or will you have to decommission and start anew?

Look for variety with projects out of your comfort zone. Implementing the same type of software over and over will make you a high specialist, but won't give you the flexibility you need to handle curve ball projects thrown at you or the fast evolution of architectures and technologies.

Consider the impact of non-functional requirements such as security, compliance, and data privacy on your architecture. Implement metrics and monitoring to gain insights into system performance and user behavior. Adopt practices like Continuous Integration/Continuous Deployment (CI/CD) to streamline development and deployment processes. Finally, foster a culture of continuous learning within your team, encouraging them to keep up-to-date with the latest architectural practices and tools.

Differentiate between software architecture and software design because they are different and the impact to the end users also differ. For example, an UAT for a refactoring of codes for a particular business logic within a feature (software design) is different from an UAT due to adding of Redis to your design to reduce database calls (software architecture). The former will trigger a regression test and most probably extensive re-testing by end users while the other typically requires less time from the end users if cache expiry has been communicated to all.