#3: Early Stage Architecture Matters
Early Stage Architecture Matters
🕰️ 1 min reading
How complex is it to change software architecture after the first users come? Should it be changeable, though?
Good architecture gives you opportunities, opportunities to be flexible and agile. Depending on the company’s culture and maturity, we might see software systems that look like a big ball of mud. But what exactly was wrong? Why did we get this state? Probably, because there was no consistent strategic vision of the product. Probably, because there was not enough attention to architecture and conventions at the early stages, new people randomly made some decisions without a full understanding of what is currently available and why.
Architecture maintenance is based on the reasoning behind changes and the current state. It would be great to have a unified approach to record the most critical changes in your architecture for evolution tracking and analyzing problems of the early days, not to meet them again. Architecture Decision Records (sometimes Any Decision Records) solve that problems. The approach focuses on unified documentation of the changes and enforces alternatives analysis. The hardest thing with ADRs is their maintenance. There should be a force that drives ADR application because otherwise, people will constantly forget to record decisions that I usually see in practice. However, it is fair to say that this problem is natural for every non-generated documentation type.
Displaying the current state of architecture is relatively simpler to maintain and, partially, that might be generated from app presence. For example, definitions of RabbitMQ might be transformed into the Exchange → Queue connectivity diagram. Also, there are a lot of nice tools and methodologies to display a state of architecture. UMLs and the C4 model help you to build a unified approach to visualize architecture. For example, plant uml might generate diagrams from text definitions. That might be embedded into AsciiDoctor docs, so fully building docs on Documentation as a Code approach. Still not perfect. Code might differ from documentation, but docs changes are trackable, and developers work in well-known git-based environment.
Architecture requires maintenance even in the early stages. Documentation will help you in communication and even in your understanding of what is happening.
The Architectural Battel: Orchestration vs Choreography
New episode in devtower! We discuss two different approaches to organizing process management in your system
Useful links:
https://github.com/adr
https://plantuml.com/
https://c4model.com/