Thank you for your opinion Sebastian Waschnick! I see your point and thoughts and just like to clarify some of my thoughts from the article.
I think our industry changes quite quick and inventing a new role name for the change in Software Architect vision which is not yet even a new industry standard is a bit premature to me. In think what Software Engineer is doing today is quite different from the past but we keep the same naming. The role of classical management is shifting towards servant leadership but we still keep the role name as Engineering Manager e.g. In my view, the Software Architect role still focuses around the global picture and what is commonly named Software Architecture, thus I would still call those people Software Architects.
Regarding the 2nd point, I was implicitly referring to the Theory of Constraints (https://en.wikipedia.org/wiki/Theory_of_constraints). It’s not at all about improving one of the disciplines (Frontend/Backend). It’s about improving the weakest property of the whole system. Example from the article: resilience. Assume we have high MTTR and high change/failure rate and this is the biggest reason for money loss which prevents e.g. from entering new markets. Assume we have a few cross-functional autonomous teams working on the different parts of the same system. Software Architect can point to the generic weakness (high MTTR and high change/failure rate) and think on the global solution which could be a) changing the data center topology to add more redundancy b) switching to more async decoupled architecture c) suggest and work on process improvement to reduce MTTR d) improve testing strategy to reduce fail/change ratio
Would be happy to hear more thoughts from you if my answer is helpful!
