Some additional Pros/Cons
1 min readApr 6, 2020
Pro
- Better use-case fit of tooling
- More general knowledge in the environment as opposed to somewhat routine-blinded framework dedicated knowledge
- Enforces best practices (generally consumable APIs, decoupled modules etc.)
Con
- Developers might need to learn new frameworks several times (new ones get added, people change products, others get deprecated etc.)
- Landscape architecture can be confusing
- Merging of products(/landscapes) is in the best case costly but in the worst case even impossible
- Interfacing architectures might not be compliant with other frameworks (e.g. product uses F1 and thus OData BE API, and this might not work well with F2)
- Culture is fragmented (F1-Developer, F2-Developer etc.)
- Analysis of all the available stacks needs to be done before each new bit and takes (more or less “wasted”) time
- Even though the report revealed that a particular framework is best, the result might still be inferior due to less experience/knowledge of the developers compared to another framework
- Architects and devs need to be super careful all the time to not create an isolated solution and might tend to overengineer