Architectural risk management

The advent of agile principles brought thinking such as:

"Continuous attention to technical excellence and good design increases agility."

"The best architectures, requirements and designs emerge from self-organized teams."

— Agile Manifesto

As a consequence of these principles, there is an understanding that teams do not need the architect role in the agile world and all architectural decisions should be decentralized and under the teams' responsibility. Despite agreeing 100% with these principles and their interpretation, we cannot deny the existence of a gap between the theory and practice. As a result, most architectural decisions are misaligned with business. So, how can the organization ensure that technical decisions made by teams are in accordance with the business goals?

In the Agile Architecture Risk Management (AARM) methodology, the architect is responsible for evangelizing the teams and training new architects. It comprises four phases:

1. Product/business strategy: identify the product's strategic goals.
2. Prioritizing architectural characteristics: define architectural characteristics to support business needs.
3. Risk storming: identify the risks associated with the architecture.
4. Architectural stories: create architectural stories to be developed by the teams.

The product/business strategy consists of collecting strategic plans for the products. The PO (Product Owner) is required to answer these questions:

• What is the product's vision?
• What is the product's mission?
• Among the features below, choose five that should be priorities:

Here is an example:

What is the product's mission?

To create conditions that allow the Payment Gateway to capture every opportunity, scaling the business faster, maximizing results while valuing clients and protecting the core business.

What is the product vision?

To ensure a fluid payment experience focused on the user experience, generating new revenue streams for the company and increasing order conversion through a global and scalable transactional platform.

What are the main strategic goals for the product at this time?

• Increase profit
• Improve customer retention
• Improve security
• Improve time to market
• Diversify or create new revenue streams

Prioritizing architectural characteristics consists in mapping architectural characteristics from the answers. Involving the most experienced people in architectural practices is crucial, as trade-offs can be complex and subtle at the same time. Properly defining key architectural characteristics is critical to the product's success. 

For the Payment Gateway example, the following characteristics have been mapped:

The next step is to prioritize the architectural characteristics. A meeting is held with product leaders to discuss which are the most important features at the moment, given the context and strategic direction of the product. 

The goal is to identify the main architectural characteristics that drive decisions, following the following steps:

1. Identify the first seven main architectural characteristics;
2. Among these seven, choose the top three;
3. Then, identify implicit characteristics, meaning characteristics not specified or determined by business goals. It is important to map them since they can become guiding characteristics depending on the moment of the product or changes in business goals;
4. Finally, highlight the architectural characteristics that were mapped and are not considered priorities at the moment.

For the Payment Gateway, the prioritization is illustrated in the figure below.

Once the architectural characteristics are mapped and prioritized, it is time to identify the risks within the architecture. To do so, we use Risk Storming, which is a collaborative exercise to determine architectural/system risks within a specific characteristic. Here, it is essential to note that each risk storming session should analyze a single architectural characteristic at a time, allowing participants to focus on a particular dimension and avoiding confusion with multiple risks identified in the same area. With the risk storming results, the team can create the architectural stories and add to the team's backlog in the architecture coding phase.

It is crucial to note that Agile Architecture Risk Management connects the strategic goals of the product/business to the most relevant technical decisions of the product within the team's daily routine. This way, we ensure that all decisions made by the technical team are directly related to strategic goals. 

Additionally, the risk management vision allows us not only to manage the adherence of our architecture to the business goals in a collaborative, structured and prioritized way but also to identify and communicate important risks in advance. As a result, the business gains better visibility into technology and architecture, while the product team earns autonomy and technical excellence.

References

• Richards, Mark, and Neal Ford. Fundamentals of Software Architecture: An Engineering Approach. "O'Reilly Media, Inc.", 2020.
• ​​Hewitt, Eben. Technology Strategy Patterns: Architecture as Strategy. O'Reilly Media, Incorporated, 2018.