Visualization Driven Migrations, a Cobol Story (Part 2)
In this episode we focus on specific views that allow stakeholders with deep domain knowledge and us to have a shared understanding of risk, value and progress of the migration - early and continuously.
Steering on value and risk
Stakeholders need to understand what we are doing and what is difficult. Showing our progress and problems every day is an excellent way to do that. At the same time, we often need to do technical things that are difficult to visualize and explain. There are things that stakeholders see as key, and things that they see as difficult to get right. This may differ from what we see as key and difficult to get right. How should we prioritize the work we do?
When we started, there was lots of uncertainty in all of us. It was therefore important to focus on delivering something quickly. We decided to take the customer data as a subject. Trivial, but useful to go through the migration process and show something that all stakeholders could easily recognize. That built up confidence in all of us, and we were able to identify other parts that would be easy to migrate too. That way we could provide value early and continuously.
With all the uncertainty, planning was of course difficult. We needed to reduce risk and increase predictability by tackling the highest risks first. From a business point perspective, the product breakdown structure of sales items was seen as the most difficult part.
Not only because that was a complex structure, but also because the structure in the new ERP system was different. After the simplest parts, we focused on this, to show that we could tackle the most difficult parts too.
Doing the high risk tasks first, allowed us to gradually improve predictability. Predictability late in the migration process is much more important than early, because the actual change over from the old to the new system requires the effort of many more people, and therefore a relatively quite period for the organization. In this case an Easter holiday weekend, just after the finishing of the 1st quarter. It also would have allowed us to abort the project early, if we had run into insurmountable problems.
A Rational Migration Process, How and Why to Fake it
As we learned from Parnas about design [2], the order in which things have actually been done is not the same as the way it should be presented to the different stakeholders. MOOSE provided us with easy to use tooling to build inspectors and browsers, and we created specialized ones. This is the one for developers, now showing a visualization of the complexity of the migration source code.
On the left hand side is an index of the migration process steps for the developers to follow. The next one focuses on how the migration could have been done with perfect hindsight. It is optimized for a stakeholder with detailed domain knowledge, who can make sense of the view presented, and unlike us, quickly verify that the data is correctly migrated.
With these different browsers, showing a specific view on the migration for each stakeholder, we could easily reuse the views and browsers and show or customize them to create a compelling story for each stakeholder.
To be continued...
[2] https://users.ece.utexas.edu/~perry/education/SE-Intro/fakeit.pdf
