When the architecture of a system starts to show its limits, it’s tempting to throw everything away and start from scratch. But a rewrite has challenges too. The existing software is a value-generating asset and must be maintained. The new architecture is unproven and comes with risks. Reaching feature parity can take years, and the rewrite turns also into an integration challenge to inteface the … Continue reading To rewrite, or not to rewrite?
Marc Hoffmann and I were invited to the 43th Berner Architekten Treffen (BATBern) on “Event-Driven Architectures”. We presented the architecture of the Rail Control System, especially the mechanisms for high-availability. Here are the slides: Continue reading BATBern43
Sometimes, I read an article, and some idea deeply resonates with me and makes a long lasting impression. It changes the way I approach some topic. Fred Brooks’ essay “no silver bullet” was one of the very first article I read that had this effect. The concepts of esssential and accidental complexity are very powerfull, deeply resonate with me, and shaped the way I see … Continue reading Great Articles on Software Engineering
Discussions about monolith vs microservice are hotter than ever. Usually, a monolith is synonym for “big ball of mud” in these discussions. It of course needn’t be so. A modular monolith is perfectly possible. Also, microservices isn’t an entirely new idea either. As some says, it’s SOA done right. The usual argument in favor of microservices is that autonomy is a good thing: teams can … Continue reading Autonomy and Microservices
Architects do typically three things: they own, they coordinate, and they mentor. As an owner, the architect maintains the integrity of the system at a high level. He designs the foundations, identifies tradeoffs, decides on essential changes. As a coordinator, the architect facilitates work and optimizes the exchange of information. He connects people, gather information, and plan activities. As a mentor, the architect provides the … Continue reading Do You Need an Architect?
The central argument of the Mythical Man Month from Fred Brooks is that conceptual integrity is the most important consideration in system design, and that conceptual integrity will only be achieved if the design comes from one, or a few resonant minds. I will contend that conceptual integrity is the most important consideration in system design. It is better to have a system omit certain … Continue reading Conceptual Integrity in Large Systems
If you want to make enterprise integration needlessly complicated, follow these tips. 1. Model poorly A poor model is always a nice way to make things more complicated than they should. Examples: You can name thing badly. You can model everyting as strings (key, list, etc.). Or you can reuse overly generic abstractions in multiple contexts instead of defining one abstraction per context. Or you … Continue reading 10 Tips to Fail with Enterprise Integration
Studies have shown that the productivity of a developer is about 10 LOC/day. Considering that modern software consists in millions of lines of code, this number is appalling. Measuring productivity with LOC is of course a dangerous thing to do. With programming, quality does not correlate with quantity, and it is wise to remember the words of Dijkstra: If we wish to count lines of … Continue reading Lines Spent
After having worked hard on a design I came once to a colleague to ask him his opinion about it. “Do you think I’ve decomposed the problem in the right way?” I said. He look at it and answered “You are mixing elements with different lifecycles”. I came back to my desk confused and worried. What I understood later is that every element in the … Continue reading Thinking in Lifecycle
The only real problem with modern software is size and complexity. If we had a bigger brain able to apprehend and reason about software as a whole without omitting details, we wouldn’t have that many issues. Unfortunately, our mental abilities are limited, and as a consequence, we need to have ways to build software whose complexity is beyond our own analytical power. The same is … Continue reading Taming Size and Complexity