There are many ways of partitioning an application. Usually, what we do is actually classify the code according to some criteria and organise the code following that criteria.
This chapter of the book explores four criteria:
- Functionality vs. Domain;
- Conway’s Law;
- Geographic constraints;
- Cultural concerns.
All in all, the idea is that we partition our codebase with long-term local autonomy in mind, according to history, standards and conventions, experience and common sense (Coplien 2010, p.91).
Good Software Architecture embodies several Lean and Agile principles, always with the same goal of long-term productivity and lightweight feature development.
Delaying structural decisions will outcome in undisciplined structure, which in turn outcomes in waste. Therefore we must think of Software Architecture as an investment that we need to make now to get medium and long term gain.
The problem is what drives our work, it’s what tells us what needs to be able to be solved by what we are building. It closely relates to use case goals and requirements, but also to the more coarse-grained OKR’s. Continue reading
In my previous posts, I briefly described the stakeholders. However, they are not Lean nor Agile themselves. What is really important, for Lean and Agile, is how they work together: Everybody, all together, from early on. Continue reading
The process of stakeholder engagement is about how people roles connect to the value stream, with everyone focusing in the product final result. As opposed to their isolated place in a production pipeline. Continue reading
Today I finish the writing about the stakeholders:
- The business
- The customers
- The domain experts
There are five major stakeholder areas :
- Domain experts
Both Agile and Lean tell us to break the traditional approach of contacting the stakeholders at a specific moment of the project development, and instead keep a permanent contact with them throughout the project development.