Some additional Pros/Cons

Kai Klostermann
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

--

--

Kai Klostermann

Kai is a front-end engineer for an expensive cars company. When not occupied with computer stuff, he thinks a lot about company culture.