The concept of a stream of events with sources, sinks, and processors is one of the most powerful abstraction in computer science.
The software architecture metaphor puts the emphasis on the structural properties of software systems. Other metaphors - city, garden, or biology - can help explain other properties of software systems better.
The slides from our talk at BATBern, focused on « event-driven architectures ».
You might need an architect to have a clear owner of the architecture, to coordinate, or to mentor. But maybe, you will be just fine without one.
Large systems are collaborative effort and it's a challenge to maintain the overal coherence. Some techniques might help you scale consistency, but some inconsistencies are also inevitable.
Too much up front design is a waste of time, but some design up front definitively has its place.
Implementing once a calendar app is a great design exercise, because this domain is simple enough for an exercices, but also subtely tricky.
You can abstract functionality, but not performance and failure modes.
Building the thing right is as much important as building the right thing. For this, you need domain expertise.
Software design is a fractal activity, where you aim at components that are small, composable, and replaceable at each level of abstraction.