Just Enough Design and Lean Software Architecture
Design pull vs Design push
A significant source of waste in design is wasting time to predict things that will probably never happen. Design, Implement and maintain code that adds complexity cost throughout the application. In Lean thinking, we try to decide as late as possible regarding critical decisions. In traditional software development, the design sessions always come before the implementation, enforcing the architect’s vision over the application. In Lean thinking, we call this Push strategy. A push strategy is good when the uncertainty is small, but in complex projects unavoidably incurs waste. The best thing would be, to just simply be able to embrace the architecture while happening. Thus a Design pull.
I want first to discuss a basic idea. Lean minimum waste architecture is a vertical architecture. As vertical architecture i mean anything that progresses based on stories. Agile discovered that early on. User stories have a feature that is in the the core of software development - that is High Cohesion
Vertical Architecture allows us to get in touch with all the components of the application in a single story - one must go through from the UI to the persistence just to add a simple functionality like displaying an object. That would seem like it is not Lean, because you should make a technology decision for each and every component. That's not the case, because this is not about technology.Its about fast exploration. This is in accord with the principle of doing the Riskiest Thing First and Architectural spikes
Emergent Architecture
Architecture can be enforced, but most often that we want to admit Architecture happens. And architecture happens, as a response to change. So there is two ways to deal with the Emergent Architecture. The way of lean and eastern thinking, in modern system theory is amazing, because it goes deeper and try to cultivate the conditions that prevent the Architecture creep in the first place.
Just to be clear, lets go to the smaller possible scale of the emergence we are all familiar with namely : copy-paste inheritance . There is a rule that most developers tend to ignore, which says "if you have to copy paste something for third time then you have to refactor it and reuse the code." This is one of the simplest form of emerging design. This simple heuristic of code economics says that if a part of code is needed 3 times then the cost of refactoring in order to reuse it, probably worth the investment and will pay dividends in the future when you will have to maintain the code.And that in its simplest sense is the essence of Just in time design.
There is Hierarchy of Design emergence
- So every refactoring move from the catalog of Refactorings Martin Fowler is step of design evolution
- As it is every Refactoring to Pattern from this Catalogue by industrial logic
- Architectural Refactoring at Different levels that may be e.g refactoring from Layered application to Microservices, or at a smaller scale for example replacing a subsystem with an equivalent CQRS implementation
and probably many more layers in between. To put all the pieces together.
Lean Architecture :
- Embraces Minimal upfront design - deferring architectural commitment - technology commitment is out off the question at this point (do not even suggest using MS server for persistence)
- Embrace Story Based iterative implementation. That is story based development
- Embracing Emerging design by recognizing early on common functionality that appears 3 times in a row and extracting design at the appropriate level (refactoring move, design patter, architectural pattern, component, interconnection of components) we should try to create a new component or layer.
- Embracing Late Design through Retrospective meetings, that will help identify and extract, the new components with the help of the whole team.
Towards a lean Architecture
Read More
Technical Decisions Series - Multitracking And Set Based Design
Technical Decisions Series - Decision Reversibility and Lean Software Architecture
Technical Decisions Series - Riskiest Thing First and Architectural spikes
Technical Decisions Series - Prioritization and Cost of Delay
vb-consulting.github.io
8 å¹´"A significant source of waste in design is wasting time to predict about things that will probably never happen." That is true if you are unable to determine accurately what is your strategic closure and what portions of code should be sealed for changes. That requires as well as experience and good communication with your domain expert. Otherwise you will easily fall in this type of trap: https://xkcd.com/974/
Process Automation Architect | BPM and SOA Systems
8 å¹´As Lao Tse said, "a journey of a thousand features application begins with implementation of a single feature". Having a map is useful before embarking on long journeys so as to cover the distances in the most efficient manner, similarly an ADD document is useful before building large featured applications. Architecture is infrastructural implementations(in layers) of business requirements. The degree of employing the Emergent Architecture and Lean Architecture approaches in Agile programs is more of a business compulsion directly influenced by how well the epics and program increments are defined, with corresponding refined capabilities and features in the product back log feeding into the visibility of the agreed MVP 1, MVP 2... God created the world in 6 program increments, if the creator had sufficient visibility of the fifth and sixth Program Increments at the start, the solar system could have been architected with just one planet earth :)
I liked the article, thank you. It's worth mentioning that the SOLID design principles should be always in your mindset, so that refactoring will be easy. Working with Agile methodologies doesn't mean you can write a spaghetti code and say "we will do refactoring later".
Software Architect
8 å¹´It is indeed a fantastic article which brings the real sense of Just In Time Architecture! This is indeed good for new/ greenfield projects!
CISSP
8 å¹´Dimitri, correct me where I am wrong. Design may emerge in a *new* product. However, for mature products (and with wide deployment base), refactoring architecture may increase risk profile beyond tolerance. For example, would you refactor Windows 10 now?