Remove Legacy Roadblocks with Architectural Clash

The modernization of existing software is becoming increasingly important in the development ecosystem. Quoting Forbes: “Now Every Company Is A Software Company”, but a large part of enterprise software is not ready for the swift changes companies need now.

Flowing is currently helping many companies struggle through their path to software modernization. We are usually called to help development teams when they are stuck with a new set of features that seem unfeasible with the current codebase/framework/architecture. Other times, our purpose is to help refactor a codebase in bad shape that is not letting the team bring enough value to their core business.

We developed a dedicated brainstorming format called Architectural Clashfor both of these use cases.

Architectural Clash

Architectural Clash is a two-day workshop to help clients remove the roadblocks with which our clients are struggling. As an example:

“We would like to build a mobile version of our desktop application, but our desktop clients are directly connected to the database.”

“Our codebase is a big ball of mud, and we are struggling to add a new set of features to it. We want to start working with microservices but don’t know where to start.”

“Our front end is based on AngularJS. We want to stop using it and think that the only solution is to rewrite everything from scratch. Are there other options?”

The main advantage of Architectural Clash is that it is an extremely practical format. We don’t waste a lot of time on analysis and hypothesis, but we start working immediately on the existing codebase. Half of the workshop is hWorkshop with our team mixing with the existing client’s team to tackle problems.

An Architectural Clash is divided into three phases: Sense-Making, Clash and Decide.

Sense-Making

The first phase of an Architectural Clash is called Sense-Making, and its focus is to help everybody (our team and the client) better understand the boundaries of the problem. For this phase, the presence of all the interested stakeholders in the product is required.

The main purpose of this phase is to understand how technical problems are related to business problems. Most of the time, refactoring processes fail because they are not directly connected with business goals.

When a developer team complains about working with old technologies or a very confusing (or untested) codebase, we ask, “What is the real problem?”. We do that with the stakeholders to find hidden connections between code and business. As an example, we try to clarify that having an untested codebase would lead to dangerous bugs that could be disastrous or the connection between a big ball of mud and the team's throughput.

We do that by asking the client about the business's goal and then trying to understand the technical roadblocks to reaching that goal. One of the exercises we use in this phase is the Elevator Pitch.

After the definition of the goal of the product, we start to identify the roadblocks and how to tackle them. However, there is a caveat when proposing a solution. All the proposed solutions to roadblocks should be written as an experiment. As an example:

We believe that by using Cypress, we could add an end-to-end test suite to our product in a short time.

Notice that you add an expectation to the task of adding Cypress. This forces you to analyze your results after the experiment, comparing them to your expectations.

So, the outcome of the first phase of the Workshop is a workshop experiment that will be the main ingredient of the next phase: Clash.

Clash

There is another important difference between an experiment and a task, a timebox. During the Clash phase of the workshop,** tWorkshopse of the team is to run the greatest possible number of experiments**.

The eight hours of the second phase are split into eight one-hour slots. For every slot, some experiments run in parallel, dividing your team into several small teams. Every team can work for 45 minutes. At the end of the 45 minutes, all the small teams gather together to share what they learned running the experiment in the remaining 15 minutes of the slot. To help the team track down and share their results, we use a simple document.

Experiment Outcome Template

After the slot ends, a new cycle begins until the time runs out. After every cycle, the teams could be mixed up, and each team could decide to go deeper with another experiment on the same topic or to start with something new.

As Flowing, we don’t just provide a facilitator for this workshop but a team that can work in the clash phase with the client’s team. This is quite important because developers should be biased towards their codebase when dealing with legacy code. Reasoning and writing code with somebody who doesn’t know anything about that codebase and its history can help see things in a new way, finding new and unexpected solutions.

Decide

The last phase of the Architectural Clash is “Decide”. In this phase, we take all the information about the business goals analyzed in the “Sense-Making” phase, with the outcomes of the Clash phase. Trying to define and prioritize a roadmap that will, in time, remove most of the roadblocks that are causing problems to developers and the business of our clients. In this phase, a possible exercise to use is called “Options Board”. In this exercise, all the actions extracted from the outcomes of the Clash phase and put on a cost/value graph.

Lean Change Management Options Board v1.0

From this and other charts, we categorize and prioritize the actionable, creating a roadmap.

If you think that Architectural Clash could be useful for your company, or if you have any questions, feel free to contact me at [e-mail].