Architecture Vision — A critical ingredient in building well-maintained software
The previous article, Software architecture — Paying the Price for Neglecting it, discussed the trap of successful software and how the evolution of software could put it on the road of danger if we don’t take its architecture as a first-class citizen and key ingredient in the daily routine of an agile team. We touch base on how architecture vision could help the team to keep the architecture in a healthy shape and to continuously meet the business challenges.
>>> “Follow me on Medium and I’ll make sure you get quality content.”
In this piece of writing, I would like to shed more light on architecture vision as I believe it could be a great way to build and maintain software systems. In addition, I also provided a kind of template to develop an architecture vision where the main components of the vision are specified, though it can be tailored according to specific needs. So let’s give it a start.
Architecture vision in the agile world
Vision is usually described as the ‘power of imagination’. It allows us to create a mental image of the future, which can serve as a guide to direct our actions and provide a sense of purpose. In this way, vision plays a crucial role in shaping our future and helping us to achieve our goals.
“In order to carry a positive action we must develop here a positive vision. ” — Dalai Lama
The architecture vision represents an ideal architecture of the system that satisfies functional and quality requirements in an ideal way. This ideal picture serves as a goal to inspire and provide guidelines and motivation for the architecture in the next release(s). Architecture vision in an attempt to ensure that subsequent releases have a positive or not at least have not negative impact on software architecture. During each release an effort is included to come closer to the ideals defined in the architecture vision, thus theoretical soundness of the resulting architecture should be sounder than the previous one.
Architecture vision is ideally created early in the development process. It serves as a reference point for the development team throughout the development process to ensure that the system being built is aligned with the original vision. It should be reviewed and updated as needed throughout the development process to ensure that it remains relevant and accurate. It serves as a guide to which changes can be related to, which helps to maintain original goals and helps to avoid any pitfall that leads to problems of architectural erosion and architecture drift. An architecture vision helps to keep the architecture document up-to-date and to increase the ability of the architecture to fulfill its goals for the next release.
Whether it is actually possible to achieve architecture vision goals is not that important; at least we have some ideal goals to strive for. It serves as a reference point against which implemented architecture is reviewed and updated and increases the ability of the architecture to fulfill its goals for the next release.
During the initial stage of software development, architecture vision helps to get the commitment of high management of the organization and to take them in confidence. In addition, it helps to align the architecture team at the start of the project and during the development and management phase. Moreover, at the organizational level vision helps to develop broader support of the architecture. Architecture Vision support software architecture to define the scope of the system. It guides to structure and manage decisions.
Architecture vision is always written based on the business vision. As the business evolves and the environment and technology change, we need to keep the architecture vision consistent with the requirements and business vision, and thus we need to update and evolve the architecture vision.
Surely, there are different approaches like architecture patterns, architecture presentation languages, scrum development methods, etc. Architect vision is not a new pattern instead it is a technique or discipline that could run within agile process to keep the consistent and iterative check on the health of the application in light of business goals and past and future requirements.
“Good software architecture provides a clear, shared vision for the team, enabling them to work together towards a common goal.” — Jim Highsmith
Architecture Vision Creation
Now we have an important question, how to create an architecture vision, what are the steps that we should follow, and what are things that are important to consider?
There are no hard&fast rules or techniques to create an architectural vision. It all depends on the business domain, organization, or project needs. On different types of business domains and organizations, different things need to be considered while building an architecture vision to get the maximum benefit out of it.
It is important to involve key stakeholders in the development of the software architecture vision, as they will be impacted by the chosen architecture and can provide valuable input and insight. These stakeholders may include business leaders, technical personnel, and end users. Of course, it's of great value if all key stakeholders including the agile team, management, and customers know about the importance of architecture vision or should be educated and its importance should be open to them.
Here are some common guidelines in form of a checklist:
business and technical goals: Architecture vision should be created by having long-term objectives and goals in mind. The business and related architecture goals and the objects to meet those goals should also be documented here. It (development of architecture vision) is a very critical step where you have to focus and write an ideal but realistic picture of the target application.
User needs and requirements: The architecture should meet the needs and requirements of the users who will be interacting with it. The software architecture vision should also take into account both functional and quality requirements, such as performance, scalability, security, and maintainability.
Existing systems and architecture: It is what we have today and I would insist to start small and avoiding over-architecting from the beginning. The architecture vision should consider the current state of the system and as well as how the new architecture will integrate with or replace these elements.
Industry trends and best practices: It is important to consider industry trends and best practices when developing an architecture, as they can inform the design and help ensure the architecture is effective and efficient.
Architecture constraints: Architecture constraints need to be fulfilled during the development, maintenance, and management of the system architecture. Usually, the constraints are defined at different levels like enterprise-level, project-specific constraints (like resources, time, money) etc. The presence of these architecture constraints in the architecture vision ensures that the software architecture should not violate any of them in any release.
Architecture principles & framework: The targeted frameworks along with the architecture principles that are planned to be followed during the development of the software architecture and development cycle. It assists release architectures to follow these frameworks and principles in a consistent way by getting inspiration from the architecture vision. In my experience, it is a great help if the team goes through the architecture principle of the company or domain and includes the one they feel is relevant and important and defines those in a more concrete form in architecture vision.
Application Standards: The application standards that need to follow throughout the development cycle can be defined in architecture vision as it can make easily followed during different releases. These applications standard includes coding standards, naming conventions, code documentation standard, architecture standard etc.
Architecture style: The architecture vision can contain the architecture style the architects want to adopt for the architecture of the application. Whatever architecture style that architects used, it’s important that these styles should be followed throughout the application during different releases. The violation of these architectural styles leads to architectural erosion. The presence of these architecture styles in architecture vision inspires each release and chances to get violated these architecture styles are low.
Technologies used: The technologies that architects are targeting to use for the development of applications, can be documented in architecture vision. In many cases, software architecture is built by having target technologies in mind as these architectures contain many technologies-specific things. So by documenting the technologies used in architecture vision, the later releases can be designed by having these things in mind.
Budget and resources: The budget and available resources will impact the scope and complexity of the architecture. It is important to consider these constraints when developing the vision. The information of current and future available resources much helpful for architects while designing the architecture of different releases.
Architecture design decisions — It helps to structure and manage the architecture design decisions throughout the life cycle of the software system.
Activities
Communicating vision
Communicating the software architecture vision is an important step in the process of realizing the vision. This involves presenting the vision to relevant stakeholders and obtaining buy-in and support for the vision. It is important to clearly and effectively communicate the benefits of the vision and how it will support the goals and objectives of the organization.
I would recommend spending some time identifying all key stakeholders who will be affected by the software architecture vision, including business leaders, IT staff, and end users. Each of these groups will have different needs and concerns that should be addressed in the communication process.
The architecture vision workshop
The main purpose of this workshop is to draw the ideal architect of the application(s) according to the business vision. The team gets a common understanding of where the business wants to go in the future and how to build technical capabilities (applications) that follow those business goals. It is a workshop where the team gets together and discusses the current shape of the application and where they want to take it in the future.
Agenda
The following could be the agenda of the meeting:
- Follow up on previous action points.
- What is our current implemented architecture
- What is our current ideal architecture and where we want to move forward based on short and long term business needs
- Do we need to make any changes in the current ideal architecture based on the latest business goals?
- What new steps could we take future to get closer to the ideal architecture?
- New action points
- Open discussion
Output
The following are a major output of these workshops
- Common understanding and documenting the ideal architecture of the application(s) or platform.
- The current state of the application(s) architecture.
- The steps or action points to take to get closer to the ideal architecture.
- Shared and revised understanding of business goals
Frequency
- The proposed frequency of this meeting is once a month or at least once every quarter.
Responsible:
The whole team is responsible for this workshop and to make this activity effective.
The product owner needs to prioritize some action points from this meeting or the team should have some mandate to book some time aside in each sprint to work on these action points.
It is very important that the business is on board to support/sponsor these meetings and the outcome of these workshops. Without business support, it’ll not much effective.
The architecture vision activities followup
The task list, the output of the vision workshop, usually contains two types of tasks:
1) implicit (intrinsic based) 2) explicit or activity-based
Implicit (intrinsic): These are the tasks that don’t need to be created explicitly, they are more about ongoing tasks or the way of working that team members need to start working with. There is no need to create a specific story/task about it in the sprint. Examples of such tasks are following specific coding styles/standards, following architecture principles or patterns for newly coming business requirements (story), etc. The team needs to find a way how to measure the progress of these tasks and what is ‘definition of done’ for these tasks is.
Explicit: These are the tasks that are more like activities that need to be planned, estimated, and performed by team members. Examples of such tasks are refactoring the codebase for better design/ architecture, configuring new support tools/libraries, starting using a new framework, a new and better deployment strategy, etc.
The team needs to take the activity-based task list from the vision meeting and put them in the product backlog. It is crucial that the team and stakeholders need to keep eye on these task lists and prioritize them together with other stories in every sprint.
Final thoughts
Vision is an essential aspect of our lives, and there is no denying that. However, irony is that we often overlook or forget about our vision when facing various challenges in life. Just like daily life, I think there is great value if your team shares a vision. My view is that most individuals and teams have a vision that guides them, but it is often implicit and not clearly defined or articulated, and it is the main reason that we drift away from our true spirit or values when we are out there in the field and the wind starts blowing in a different direction and we need to deliver.
There is a great power and magnetic effect to make our vision explicit and discussed, opposed and defend and built together.
Agile teams win big time not only by working on architecture vision but also make the vision a key component of their daily team rituals. The most important thing is nobody could give you a vision, of course, they can offer you some ideas but the team needs to build and own its vision and build it further based on their need, environment, and challenges and make it a critical component that drives every decision.
Nobody gives you vision, it’s the team who builds it, and owns it as that is the only way to live by it.
Your Choice:
Follow me on Medium and I could make sure you get quality content.
