VBAM — Vision Based Architecture Method

The Vision based architecture method (VBAM) helps to develop an architecture mindset within an agile team and makes this style of thinking a part of the team/organization culture.

>>> “Follow me on Medium and I’ll make sure you get quality content.”

In my previous article, architecture vision, we discussed how architecture vision could help the agile development team to get better at building and delivering software systems, get the software quality and maintainability bar higher and keep the architecture in great shape.

As we discussed in the article ‘Who is an architect’ that today's software is much more complex and multidisciplinary in nature and its whole agile team is responsible for keeping the software architecture in good healthy shape. To understand the multidimensional nature of software architecture, We need to take different roles within the team on board, combine their forces by passing them through a Process and build a Voltron. The architect is not a superman it's a Voltron (combined forces of the whole team. Now the follow-up question is how to make it, what that process looks like?… and the answer is: VBAM

In this article, we are going to discuss that process. I would like to shed more light on the method or process based on architecture vision, I would like to call it VBAM (Vision-Based Architecture developer Methods). The goal is to provide a systematic method to the team that helps the team members to be disciplined and do continuous efforts to maintain the architecture of the application.

VBAM could help the team to have a continuous check on the architecture, refactoring needs, and direction. Such a process could give a tool to the team to proactively do architecture work and bake architecture efforts into the development process where the main focus is to deliver functionality in smaller chunks.

Recap of Architecture vision in the agile world

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.

Graphical representation of the Architecture Vision process

Surely, there are different approaches like architecture patterns, architecture presentation languages, scrum development methods, etc. V-BAM is not a new pattern instead it is a method or discipline to keep a constant check on the health of the application in light of architecture vision and evolving business dynamics.

VBAM (Vision-Based Architecture Method) — The Process

In order to apply architecture vision, we need a process that helps to develop and encourage this mindset and makes this style of thinking part of the team/organization culture. Here we would like to propose this well-needed process to develop the software architecture of the coming releases based on the architecture vision, architecture design document (of any form), and the current state of the architecture.

The V-BAM provides a disciplined approach to planning software architecture development activities. This method helps to maintain and up-to-date the software architecture for different releases while living in the evolutionary world. Considering the iterative nature of the software project, it encourages the organization and software team to spend some time on the software architecture regularly.

This method encourages to develop and maintain architecture vision in a separate document in the form of an ‘ideal world’ that inspires the architecture of every release. For the existing software application, this method provides a series of steps that help and guide the evolution of software architecture to keep applications alive under changing environments.

At the start of any software project or product, the team usually starts by building some kind of architecture design. This architecture design could be in the form of detailed word documents or PowerPoint slides, whiteboard diagrams, or even a high-level architecture or design sketch or idea in the mind of team members. This architecture design mainly represents (and describes) the main components and specifications required to support the solution and ensure that the specific business and technical requirements of the design are satisfied.

The V-BAM consists of the following steps that can run in parallel to any development method like scrum or kanban, it can also be seen as an extension of scrum or kanban.

VBAM

1. Develop (or revise) architecture vision — Regular vision meetings quarterly, mid-year, or yearly
2. Develop the architecture of specific release
3. Run Agile development sprints
4. synchronize architecture with the vision
5. Evolve Architecture vision

1. Develop (or revise) an architectural vision

While building the architecture design, we highly encourage the team to start work on developing the architecture vision of the target application. The team might need to do some short-term architecture design decisions due to different factors in the project but by recording the long-term plans in the architecture vision they have a goal to strive for and could save themselves from technical debt and eventually architecture erosion.

The goal of this step is to build or refine a software architecture vision, preferably in the early phase of the project. One important thing to note is that this architecture vision is developed and refined at the software application or enterprise level and not for any particular release. It is important to clearly communicate the architecture vision to all stakeholders, including developers, product managers, and executives. This will help to ensure that everyone is aligned on the overall direction of the project and can work towards the same goals.

More detail on architecture vision and its creation guidelines could be found here: “Architecture Vision — A critical ingredient in building well-maintained software”

2. Develop the architecture of specific release

The main goal of this step is to develop an architecture design document (of some kind) for a specific release where the total focus is given to release ahead within the given resources and time. This release could be the result of one or multiple iterations or sprints. This architecture design does not have to be too detailed but it just needs to show when we are going to deliver and how the overall structure will be updated by end of the release. The team can decide what extent of detail should be recorded here and this detail could change with time. It is quite possible that every release does not affect the overall architecture of the application, if that’s the case with the current release then it’s good but the important point here is that it should be an explicit decision.

The common inputs of this step are usually the architecture vision, the architecture of the previous release (if it exists), and functional requirements. The output of this step is a release-specific architecture, the design document defines the path on which the software architecture needs to build in the next step. When we do it often (on every release) then it will go must faster but important to run this step and have a good consensus within the team.

Show me some Examples

Here I would like to present a few examples to get the point across:

• Consider a project that has a vision of building a scalable, cloud-native system that can handle a high volume of traffic. In this case, the architecture vision would likely emphasize the importance of designing the system to be horizontally scalable, with components that can be easily distributed across multiple servers or cloud instances. This could influence design decisions of specific releases such as the choice of a microservices architecture, the use of a load balancer to distribute traffic, and the adoption of cloud-native technologies like Kubernetes or Docker.
• Now consider a project with a vision of building a system that is easy to maintain and evolve over time. In this case, the architecture vision might emphasize the importance of designing the system to be modular and flexible, with a clear separation of concerns and well-defined interfaces between components. This could influence design decisions of specific releases (release ’n’) such as the use of design patterns like the dependency inversion principle, the adoption of a modular monolithic architecture, or the use of APIs to decouple components from one another.
• Consider a project with a vision of building a system that is highly secure and compliant with industry regulations. In this case, the architecture vision would likely emphasize the importance of designing the system with security in mind, including considerations such as data encryption, access control, and secure communication channels. This could influence design decisions of the current releases such as the use of secure protocols like HTTPS, the adoption of a zero-trust security model, or the integration of security tools like firewalls or intrusion detection systems.
• Now consider a project with a vision of building a system that is highly reliable and able to handle failure scenarios gracefully. In this case, the architecture vision might emphasize the importance of designing the system to be fault-tolerant and resilient, with mechanisms in place to detect and recover from errors. This could influence design decisions or architecture of specific releases such as the use of design patterns like circuit breakers or retry patterns, the adoption of redundant systems or failover mechanisms, or the integration of monitoring and alerting tools.
• Finally, consider a project with a vision of building a system that is able to support a wide range of clients and devices. In this case, the architecture vision would likely emphasize the importance of designing the system to be cross-platform and flexible, with support for different devices, operating systems, and browser versions. This could influence design decisions such as the use of responsive web design techniques, the adoption of a microservices architecture to support different clients, or the use of APIs to decouple the system from specific clients or devices.

3. Run Agile development sprints

Agile development emphasizes flexibility, collaboration, and rapid iteration. One key aspect of Agile development is the use of iterations, also known as “sprints,” to deliver functional software in small increments. These iterations typically last one to four weeks and involve the development of a set of specific features or functionalities, which are typically defined in the form of user stories or other requirements.

A key point of the agile development method is to continually develop the architecture in every sprint as the business requirements become more clearly understood, rather than front-loading the process with an architecture and design phase.

One risk with this approach is that the resulting architecture may be far from optimal and the technical debt accumulates quickly and may become unmanageable. This can be especially true if the team struggles to meet their sprint goals every two weeks (which may be a result of business pressure or over-ambition in sprint planning) or if the team does not have a sufficient level of architectural expertise.

There are different approaches to how iterations can be organized and delivered in an Agile project. One option is to release each iteration as a standalone software product, with each iteration building on the previous one to deliver additional functionality. This approach allows the team to deliver value to stakeholders on a regular basis, and to respond quickly to changes or feedback.

Alternatively, a team may choose to combine multiple iterations into a single release, with the goal of delivering a more comprehensive and feature-rich product or due to some other reasons. This approach can be useful for larger projects with more complex legal requirements.

Ultimately, the choice between releasing each iteration separately or combining multiple iterations into a single release will depend on the specific needs and goals of the project, as well as the trade-offs that are most appropriate for the team and stakeholders.

4. Synchronise architecture with the vision

As we discussed earlier, it is important to have the architecture vision but it is not that critical that our current architecture is implemented according to the vision. In most software applications, we make many short-term architecture decisions due to time pressure, unclarity, and other parameters that result in introducing technical debt in the applications. In this step, we set time aside to look back at what we have done and where we would like to take our architecture in the future. We record any technical debt that has been made and build a plan and direction, in light of vision, to minimize or remove the technical debt.

We look back at the architecture decisions that we made and analyze if they are still valid or need to be updated based on newly introduced/ changing requirements.

5. Evolve Architecture vision

As the project evolves, it is important to regularly evaluate the alignment of the architecture with the overall vision and goals of the project and other factors that are defined in the architecture vision. If there are any discrepancies or areas of improvement, then we need to update the vision explicitly.

Overall, the process of refining the architecture vision is an ongoing process that requires careful planning, communication, and evaluation in order to ensure that the architecture of the system remains aligned with the overall vision and goals of the project.

Following are the proposed steps to introduce changes in the architectural vision.

1. Review the current architecture vision: Begin by reviewing the current architecture vision to understand its goals and objectives and how it has been implemented so far.
2. Gather and analyze information: Collect data on the current state of the system, the needs of the stakeholders, and any relevant industry trends or best practices.
3. Identify areas for improvement: Based on the gathered information, identify areas of the current architecture that could be improved or updated.
4. Develop/revise architecture vision: Use the information gathered to develop a new architecture vision that takes into account the identified areas for improvement and aligns with the current and future needs of the stakeholders.
5. Communicate and seek feedback: Share the revised architecture vision with relevant stakeholders and seek their feedback and input.
6. Refine the architecture vision: Incorporate the feedback received into the revised architecture vision to create a final version.
7. Implement and review the updated architecture: Follow the roadmap to implement the updated architecture and regularly review and update it to ensure it meets the needs of the stakeholders and achieves its goals.

Final thoughts

The architcture vision is the key that could help the team in guiding their architecture decision during different releases in the software development process. VBAM could be a great method/process for the team that could help them on this journey and use the vision as part of the process. It could help to embed the architecture mindset into the team culture so the team could think and talk about architecture with ease. The goal is to provide a systematic method/process to the team that helps the team members to be disciplined and do continuous efforts to maintain the architecture of the application.

More

Follow me on Medium and I’ll make sure you get quality content.