You have a legacy system and you want to know what to do next. We start by identifying the specific problems in your crisis. We explicitly and systematically assess your system by means of auto-generated views. These views are created specifically to match your problems and they replace the typical slides and views produced through manual inspection.
Why is that important? Because you are spending the largest chunk of your budget on that implicit manual inspection. By generating custom views, you free energy to actually solve the problem.
The outcome? An assessment that informs your path to action. A custom tool that can guide your actions. And a process that is repeatable.
Mapping strategic assessment
Crises present many risks. Through our systematic approach, we decrease those risks by adding transparency. This Wardley Map depicts what we bring different into the game.
The core proposition revolves around replacing manual views created through manual inspection by vews generated automatically. The generation is created specifically for the problem. It's much like data science, only applied to software.
This is important because we replace the single largest cost and the most important source for unnecessary risk. Your system is too large to be understood manually. As a consequence, pictures produced manually do not reflect the reality of the system. They constitute beliefs rather than accurate engineering tools. And beliefs are not appropriate for any decision making. Beside reducing risk, transforming the primary means by which information is gathered from the system frees energy that can be used for experimenting and acting.
How it works
You have a legacy system and you want to know what to do next. Before you can decide, you first need to assess the current system. We build custom tools to let you estimate and observe the impact of your decisions on the reality of the system. And we guide you through the whole process, from the technical aspects to the business part.
A strategic assessment situation appears rarely and it tends to be described broadly, in a not quite quantifiable manner. These problem look like these:
- The system is slow.
- Why does it take so long to adapt the system?
- How to move away from the mainframe?
- How to split the monolith into well defined bounded contexts?
These are broad problems. The first step is to make them concrete and split them into smaller pieces that can be approached separately through spikes.
Looking at the system can tell you how the system looks like it, but it cannot tell you why. Only the people around the system can do that. It is imperative to both identify and include all relevant stakeholders, both technical and non-technical.
And there is another reason why stakeholders must be involved. Often, a strategic assessment has a high visibility in the company, and during the inspection the imperfections from the project tend to become larger than ever. This can induce a state of anxiety in the team. This is not desirable, because in the end, it is the team that should carry the project forward. For this reason, assessment should be positioned as support not as policing.
For an accurate assessment you also need appropriate data. Because strategic problems are non-technical, it is often not straightforward to know what data is appropriate. Furthermore, even when you know what you want, it might be difficult to get your hands on the data.
For example, when assessing a system that is outside your organization, it might get politically difficult to get access to all data pertaining to the system. There are various reasons for it. On the one hand, there are political and status reasons (e.g., who are you to check me?). Positioning the assessment project as a service is a good path to get acceptance. On the other hand, because of lack of experience, people might not understand what data you need even if you ask for it explicitly. Ask again. Fight for data. The quality of the decision depends on it.
An assessment effort usually ends up involving highly technical details. For example, a performance problem might involve analyses of various logs, and a monolith splitting might involve a deep dependency analysis. However, at the end, the results must be presented in a way that non-technical stakeholders can relate to and incorporate into their decision. This is a critical step.
What you get
First, you get a report. We are consultants after all. In our case, a typical report contains:
- Description of assessment questions and their relevance for the business.
- Answers to the assessment questions.
- Description of the process through which we got the answers
- Implications and next steps
Second, our findings are based on custom tools we create specifically for your problem. And you get these custom tools, too.
This means that you can reproduce the analyses yourself. Thus, beside the concrete path to action to address the current issues, the report and the tools also helps you validate whether assessment is a strategic skill worth internalizing.
What happens after? Steering agile architecture
An effective assessment always leads to action. Once we decide on the path, we have to take it, but taking it might take a longer time. How do we change our system while still dealing with business as usual?
That's the realm of steering agile architecture.