Arthitecture Process
Why a process?#
Software architecture is not only about high-level structures or technical choices of a system. Instead, it is a continuous process, connecting all stakeholders, including end-users, customers, business entities, developers, and the operation team, towards its vision.
Furthermore, Software Architecture isn't a single person's responsibility. Instead, it requires support from different team members to establish the strategy and drive the execution.
Different stages#
Inception#
When building any software product, architects should be involved from its inception to Identify high-level requirements, understand the domain, market competition, and project constraints and risks. In addition, it helps identify the quality attributes like security, performance, compliances, and functional requirements that have a significant impact on architecture.
And the architect should give an active contribution in setting a clear vision and road maps for the projects and establish a good communication strategy within the team and other stakeholders to continue the project without any bottleneck and miscommunications.
As a part of this exercise, the architect establishes high-level architecture documentation that includes diagrams, coding standards, and best practices.
And setting main architectural and design goals for the project based on the above functional, non-requirements, and delivery deadlines are crucial in this stage.
However, it isn't necessary to re-invent all these. Referring to existing practices, knowledge, and frameworks documented will play a significant role in the project's success.
For example, you can use the 99x well-architected framework that captures a collection of industry-proven best practices as a reference to establish an effective architecture process.
Well-Architected Framework: https://architecture.99x.io/docs/99x-well-architected-framework
Drive#
Today, we hardly follow "Big Design Upfront." Instead, we look at setting up the necessary architecture with a deep understanding of the "Architecture Runway." thus giving more agility to the designs because future functional and non-functional requirements changes, technical trends, and known/unknown risks, cost, and delivery deadlines.
Here mainly need to focus on the architecture style the project will follow, initial design choices and patterns, set of standards (coding, dev process, etc.), technology, platform and hosting options, release strategies, third-party frameworks, tactics for non-functional requirements.
A more collaborative and iterative process needs to be followed to identify the most suitable architectural candidates for architectural and design goals set in the inception.
Maintaining a decision log for all significant decisions and the basis for these meeting minutes for all discussions will be more useful in the long run of the project.
The template used for decision logs and meeting minutes can be found in the following link on the site.
Decision template: https://architecture.99x.io/docs/templates/decision-logs
Meeting minutes template: https://architecture.99x.io/docs/templates/meeting-minutes
Every software project will start with a goal. However, while achieving these, some technical debts could be left behind, which need to be addressed in the future. These could be gaps in following design, coding, testing, releases, deployment, or other operational work on time.
There should be a defined process to track these technical debts and address them soon. Depending on the team size, nature of the delivery cycle, some techniques like one day per sprint, the rotating role can be followed. Whatever the method it is, addressing the technical debt should be a continuous and iterative process since it is unlikely any active software project will be with zero technical debts at any given time.
The well-established dev-ops culture with a value-driven product management approach to the implementation and operation of the software project will be a definite added advantage to the project's long-term success.
Review and Evolve#
As mentioned earlier, the software architecture is not a one-time activity that will be done and completed in the project's initial phase. Instead, with the nature of modern software delivery and dev-ops process, it has become a continuous process until the end of the product's retirement.
With the rapid change in technologies, hosting platforms, functional and non-functional requirement changes, market and industry demands, and uncertainties, architectures need to evolve so that such external changes can replace, refractor, and extend without much of a cost.
Continuously monitoring the architecture health is essential in this stage to proactively identify the bottlenecks and issues in advance for the long run of the project with a given set of architecture/dev checklists created with the help of experienced architects and product experts. And the review process will be more periodic, and in each cycle, more improvement points will be discussed and planned for implementation, considering both current and future trends.
And multiple discussion and knowledge sharing forums like weekly architect sync up, monthly open discussions, and sessions with timely topics will give a definite boost to put every project into the correct technical and business direction.