In this previous post, I shared what I called The four cardinal points every senior software engineer must follow to progress in their career. One of these is Prioritization by Business Value, which invite you to take decisions driven by their impact on the business, simplicity and flexible are key to do it.
The More Flexible, the More Value
“A good architecture makes the system easy to change, in all the ways that it must change, by leaving options open.”
— Robert C. Martin, Clean Architecture
A flexible architecture allows you to deliver early and long-term business value more easily. One tip for your career as an Agile Software Architect is to prioritize decisions that enable you to delay defining specific architectural details. This includes delaying choices related to frameworks, protocols, databases, configurations, message brokers, and other external dependencies.
By delaying these decisions, you leave room for better choices when you have more information, avoiding premature commitments to technologies that could limit your solution’s adaptability in the future. Clean architecture, for example, helps you abstract these details and focus on core business logic without being tightly coupled to specific technologies early on.
The Simpler, the More Value
“Everything should be made as simple as possible, but not simpler.”
— Albert Einstein
As Agile Software Architects, our goal is to deliver value in the simplest way possible. Design decisions should focus on reducing unnecessary complexity, especially early in a project. For instance, instead of diving straight into complex architectures like microservices, consider simpler solutions that meet current needs and allow for easy evolution over time.
In my experience, I’ve seen projects that started with microservices from the beginning and failed because this architecture introduced unnecessary complexity. Managing service coordination, network overhead, and data consistency added more challenges than benefits at that stage. A simpler approach, like a monolithic architecture, would have saved time and resources, allowing the team to focus on delivering value earlier.
While microservices are great for scaling when necessary, starting simple and evolving as your system grows keeps your architecture flexible and easier to manage. By avoiding premature decisions, you prevent technical debt and ensure smoother progress.
Let me know your thoughts about this.
-Carlos.G