A good example of hands-on architecture work is given by the Microsoft Patterns & Practice group in the article titled CQRS Journey. If the architect isn’t hands-on, he/she is not well equipped to perform assessments thoroughly, he/she would need to go by what is being told in blind faith. Architecting a software solution in blind faith implies that one of the main objectives of architecting a software solution, risk management, becomes weak.
This article by Microsoft Patterns and Practice people is a good example of what I often talk about, that a software architect needs to be hands-on. The credits here show a large number of people, that isn’t necessarily needed to architect a solution properly, this is probably just how they collaboratively put it all together.
Not understanding enough about all aspects of the architecture is often the cause for things going wrong down the road. Such risk is mitigated if teams dive into all corners of the problem and solution domain. As an architect, if folks try to take your ideas in unintended directions you would at least be able to spot that and assess any potential issues or risks that may result.
If the architect isn’t hands-on, he/she is not well equipped to perform such assessment adequately, he/she would have to go by what is being told in blind faith. When that happens then one of the main objectives of architecting a software solution, risk management, becomes weak.
We learn this all the time, testing is a fundamental part of crafting great software – yet it seems to often be relegated for all sorts of reasons. This oldish article by Martin Fowler on LMAX Disruptor shines a light on the value of performance testing, and mechanical sympathy as a crucial skill for crafting great software solutions.
Two interesting take aways from Martin Fowler’s article on LMAX are: the importance of performance testing, and mechanical sympathy.
Testing is actually one of the most efficient ways of learning modern software systems, so if nothing else it’s going to bring that edge to people. Mechanical sympathy, on the other hand, is one of the enduring qualities of great C/C++ programmers, I’d say that in that case the expression covers a combined affinity with the C++ language standard, the vendor compiler idiosyncrasies, and the particular OS being targeted. I could infer this back in the 1990s as I read books by folks like Herb Sutter, Stan Lippmann, or Scott Meyers. At the time I had a good understanding of the x86 architecture and could see how mechanical sympathy played out – though, I didn’t know the expression until I read Martin Fowler’s blog.
I’ve been focusing on actor based programming models last year or so, I think the LMAX Disruptor is definitely a very interesting and exciting concept.