Deutsche Übersetzung folgt in Kürze.
A recording-monitoring default system is a labor-intensive and complex beast. I imagine it's like that in every bank. After all, the system is built on extensive Central Bank requirements. Requirements that are demanding and extensive.
In our bank, this was probably the most complex system I've ever been involved in working on. And, of course, it was impossible to account for everything right at the design stage.
Just as it was impossible to foresee the avalanche of changes to come, and to make the architecture even more intricate.
Sounds familiar, doesn't it? I've written about something similar before. In the article about default committees. Although "similar" here isn't "the same."
This project taught me... slightly different lessons. Maybe even obvious ones. But I absorbed their truth through practice. "Trust, but verify" - a good Russian saying that fits here perfectly.
The first thing I learned - time.
And not just "time," but time given in sufficient measure. Without it, you simply can't plan, implement, test, - and do all of it well. Suitably well.
The second simple truth - team.
It shouldn't be way too big. Not even the classic "ten people is the limit" - fewer. Three. Four. You see, it's easier to hold the complex, big picture in that many heads.
The third - information.
The big picture needs to stay synchronized - in all the heads. For that, long ago wise ones devised a system - diagrams. Once drawn, it's important to update them. And it's important, very important, to follow what's drawn.
The fourth - data quality.
From day one. Not when the system starts showing miracles (especially for a system of this scale) - from day one. Looking at our default recording-monitoring system, I can say with some bitterness, that many problems could have been avoided, many hours could have been saved, if we'd done validation from day one.
And the last, but not least - SLA (Service Level Agreement) on data quality.
Signing it with data providers is no less important than your internal checks. If peculiar unwanted things are at input - even the coolest, most brilliant system will eventually fall victim to "garbage in — garbage out."
In the end.
We managed to create a good system. Not perfect, of course, but functional. Pretty good, considering the complexity. And along the way, I enhanced my expertise and gained invaluable experience - knowing how and where to improve, and what mistakes to avoid if life ever throws me a challenge of a similar scale.