Lessons learned
This have been an amazing project for me, to learn, to get experience and to try the things I’ve learned throughout the courses in real life. All previous experiences being an architect has been more like doing architecture as a lead developer.
The stressors and attractors really helped me find cases I’d never thought about without them, and the residuality index provided me with mathematical proof that one option is better than another. I will definitely keep using these techniques in the future.
Writing about my work has also made me think and reflect, and for the education/certification, that’s probably more important than the actual architectural result. I’m still questioning the decision to write in English tho. The client is Swedish, the certification is in Swedish, the rest of my blog is in Swedish.
Because time to market was a main priority, the development team had to move at full speed at all times, and that made my work a little difficult, since they often implemented stuff before I had the chance to architect it. This caused a couple of rebuilds, and a few cases of putting what the developers did into the architecture. The fact that we now have only one client beta testing the product also made a couple of big rebuilds end up in the backlog. They are not necessary at this scale, but if (when) the product is successful, they will be.
Cloud cost management have been a big deal in this project, and that’s really difficult. I’ve learned a lot. With the small workload during development/testing, the difference between “look at all crawl containers that are deployed, and check the database if their crawl session is done, and if so, shut the container down” and “check the database for finished crawl sessions and make sure their respective container is shut down” is huge, cost wise, because a sleeping database is free of charge.
It’s been amazing to do this project, and reflect back to a detail from the Introduction to modern architecture class. This is how we’ve always done good architecture, but nobody put words and science to it before. I’ve never used the stressor analysis or the residuality index before. I have, however, thought “what if” a million times, and I find that the stressor analysis and residuality index is more or less just a structured and documented way of thinking “what if”.
The classic answer to all (architectural) questions has been “it depends”, but this also gives a very good documentation on what it actually depends on. The ability to handle Time, Change and Uncertainty is, in my opinion, the greatest benefit of using the methods taught in the classes leading up to the Advanced Software Architect-certification. Reminds me of the title of an amazing book.
