What is the best way to update and maintain your system architecture after deployment?

Regular Software Updates and Patches - Assessment and Planning - Backup and Recovery - Apply Software Updates - Testing and Quality Assurance - Monitoring and Feedback Scalability and Performance Optimization - Performance Monitoring - Scalability Planning - Resource Optimization - Code and Database Optimization - Capacity Planning Security and Compliance Management - Vulnerability Assessment - Access Control and Authentication - Security Updates and Patches - Security Training - Compliance Monitoring By following these three sets of steps, you can maintain and update your system architecture effectively, ensuring that it remains secure, efficient, and adaptable to changing needs.

The most important aspect of architecture documentation is that it explains what quality goals are addressed by which architecture decisions. Diagrams of your AS-IS architecture can be generated from code or runtime traffic. What cannot be generated are the intentions and assumptions you had when designing the system. THESE must be documented as Quality Scenarios (e.g. via Gerkin syntax) and Architecture Decision records (ADRs). WHY are these ADRs so important? Because they help you evolve the system by revisiting decisions at a later point in time e.g. when new options arise or relevant context parameters changed.

Documentation is up-to-date and detailed when it is easy to keep it current and accurate. It is a good idea to have developers keep the documentation in sync with changes to the code, and this can be part of the Definition of Done (DoD) for user stories. Ideally, code and documentation should be stored in the same repository. Diagrams as code are a good way to make maintenance less frustrating. Using a developer portal like Spotify's Backstage is a good way to accumulate repository-stored documentation in one place. The C4 model is a good way to visualize software architecture.

I found the easiest way is to use ADRs ( architectural decision records). It helps you see why a certian approach was favorite, and how the system evolved in time.

Documenting architecture is not the same as documenting code. Architecture is described at a higher level and the teams need to have the discipline to update the documents when architecture changes. We had people assigned to do this, literally chasing the architects to obtain information to properly document. We managed to keep the documentation updated per release. Regarding code: documents, models, code need to be kept in the same configuration management and it is up to the developer to do that. We had models as the source and generated code and docs from the models. This led to very few hand-written code and increased code quality (very few bugs, easily caught). And we ensured that code and documentation were kept in sync.

It is not a necessity to incorporate sophisticated architecture frameworks like RUP and ADM for small to medium solutions. On the other hand, it is so important to have such processes in place for large to huge solution architecture and strategically critical solutions regardless of the size. While some solutions may require maintaining few or tens of pages describing the overall solution architecture; large and strategically mission critical solutions require a depth of details that might count for hundreds or may be thousands of pages. The larger the documentation stack the more complicated becomes the process of maintaining that set of documentation. In such a case, having a well defined process becomes a necessity.

In today's dynamic business landscape, adaptability is essential for organizations, just as software development teams follow Agile methodologies, emphasizing collaboration. RUP, ADM, and the Spiral Model can adapt for flexibility, especially in architecture-driven projects. Their suitability depends on project specifics, team preferences, and organizational goals. Customization or blending may be needed for a precise fit.

This should be at every team's latitude. Whatever works best. Any prescription could potentially hurt. Exactly how one would approach Scrum vs Kanban

Every existence that we architect should follow universal principles of harmony or Harmonism. Every existence is born from a seed, creates its own new seed, consumes and creates consciousness, connected with universal limitless quantum knowledge of sense and experiences with the universal limited actions of the sense. Quantum Computing can achieve this. The lifecycle of existence is determined by its function to the parent. Once the seed is matured for its function than it should take responsibility. Like Human Civilization. When you design software, you create seed implementation that should have the maturity ability that adapt, learn, communicate, exchange, and unite.

Consider storing your service connections manifest (and other related data) alongside the service code. It allows to support: - Tracking connection updates in tandem with the code. - Mapping the system's connections by just scanning the code. - Enforcing connection policies, enhancing system security, and ensuring teams keep the manifest updated.

It is always a very good helpful idea to use version control such as Git or SVN. being able to revert back to an older version might become needed when a released version of the solution is rolled back. As we said before, the solution design and software components need to be tightly coupled to the solution documentation. Version control also can be good as a historical analogy tool for other solutions in the future.

Version control is essential for storing code and documentation, as it allows you to track and manage changes over time. Configuration management is more challenging, as it can involve a variety of different types of data, such as application configuration, secrets, rules, and infrastructure as code. Some of these types of data can be stored in version control, but others may not be appropriate. Architectural Decision Records (ADRs) can be stored in version control if you use a tool like Log4brains, which is designed to manage ADRs.

IaC and/or Configuration Management tools allow full traceability of infrastructure changes and evolution. Tooling and technologies can be diverse, CloudFormation, Ansible, Chef, Terraform, ARM, Bicep... Nowadays the trend is Terraform, which works great and is more intuitive and flexible than other technologies. Now the important part is what is known as GitOps, besides using some technology mentioned above, the code developed in that technology should be placed under version control (Git please, not old-fashioned solutions). I would not stop there, but creating a pipeline that allows code (infra) changes verification and execution will make life easier and will remove human mistakes drastically, as well as provide top efficiency.

Version control is useful in the release management process. You will be able to track releases and customization. Working with numerous developers makes your job easier.

Architecture reviews should be applied at key milestones during the solutions lifecycle, early on in the design phase to avoid architecture decisions that are difficult or impossible to change, and then before the go-live date. The outcome of any review is a set of actions that should improve the experience of a customer using the workload. Many or even most decisions are reversible, two-way doors. Those decisions can undergo a lighter weight review process. One-way doors are hard or impossible to reverse and require more inspection before making them. After solution goes into production, the workload will continue to evolve throughout its natural lifetime, as new features are introduced and changes are made to the tech implementations.

If your organization is applying some maturity model such as CMMi audit reviews should be part of that model imposed processes. Even if your organization is not imposing any maturity models; incorporating internal audit should be considered to make sure that the latest solution documentary set matches that if the operational solution runtime.

There's no need to configure complex checks and configurations. By using IaC and storing it under Git, a pipeline should be configured that treats the IaC as any other regular code. That means, the IaC can be changed by raising a PR which includes a SonarQube analysis step.

Having reviews and assessments will assist you in producing cleaner code and reducing the amount of technical debt. It also assists developers in adhering to best practices for secure development.

Architecture patterns and principles...not sure how to comment on this, if we start this conversation speaking about MVC and and..KISS and and...it clearly says that there is something lacking. Reusable this patterns and principles may be, however I still believe that we need something that fundamentally can be used as a common foundation in addressing what we all perceive to be "common", else this is all but subjective on what works well.

Philosophically speaking, applying architectural patterns may look to be limiting to teams and organization creativity and innovation. I personally prefer coming up with the right solution to an in hand problem based on organization capabilities and capacity regardless of architectural patterns being used. I know, many will disagree with that and they are welcome. A bottom line - in my humble opinion - is to apply architectural patterns whenever you can as far as your organization has the capacity and capabilities to do so.

Architectural patterns, Enterprise Integration Patterns, and principles serve as a universal language for conveying system behaviours and expectations since they are familiar to most engineers. Offering recommendations, especially in the early stages, can provide a clearer framework, reducing the need for speculation and potentially preventing architectural deviations. Enhancing the design by refactoring solutions to incorporate these patterns can not only enhance the solution but also render it more understandable and manageable in the long run.

Initial system design and improvements are guided by the hypothesis that specific approaches will positively impact business or technical KPIs. Changes should ideally enhance KPIs, but it's crucial to verify these assumptions. Comparing KPIs post-change to a baseline measurement is a reliable way to assess effectiveness. AB testing, commonly used for this, applies not just to UX but also backend systems.

Incorporating a comprehensive monitoring and testing strategy is pivotal for maintaining a resilient system. My advice is to not just focus on tools but also emphasize creating a well-documented process for implementing and interpreting the insights gained. Additionally, consider periodic reviews of your monitoring and testing protocols to ensure they evolve with your system's complexity. This proactive approach will contribute to the long-term stability and efficiency of your architecture.

A good architecture is fairly restrictive, and as a result, it's resilient. When clear functional separations, API contracts, dedicated points of data access are present—and these, along with other principles, are enforced—the chaos is typically contained and doesn't spread beyond a specific service or subsystem. Another point to remember is Conway’s Law. Following this principle, an organization's structure has an impact on the stability of your architecture, both positively and negatively.