You have a legacy system and you want to know what to do next. Should you migrate? Should you split it? Or how to go about adding that new crosscutting functionality?
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.
How it works
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.
- How to migrate to the cloud?
- 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.