I see more and more, that the usage of models (referring to traditionally used qualitative, often graphical, models and modeling languages) and model building is diminishing in the software engineering (if we can talk about the software "engineering" anymore at all).

The reason seems to be that developers do not want to use the models and therefore making or maintaining these is perceived as "no-value" overhead. Behind the reluctance of developers to use models is often the agile movement's argument that everything could be seen/found from the code, and because in DevOps same team that does the development, does also maintenance, there’s also no need to communicate between different teams.

But actually:

• it is very difficult, if not impossible, to write code so that it all the requirements or high-level design decisions would be presented directly in the code (not to mention being easily readable/understandable for the ones that did not write the code),
• it costs time and money if developers make mistakes because they are not able to understand from the code the requirements it implements and the design intents/constraints, and
• it costs even more time and money if developers go away and need to be replaced by new ones who don’t know anything what has been said "at the water-cooler" (possibly two years ago).

Because additional information (same that has been traditionally represented by the models) is needed and because code isn’t usually very much commented and often also not very readable, so often developers and others, involved in the software development activities, try to find other ways to collect and maintain this additional information, representing it usually in non-formalized textual form in their work-organization tools (e.g. Confluence wiki and in Jira tasks).

Additional reason to drop models in the software development in favor of informal textual descriptions, seems to be the inability to automate anything in software development process apart from the simple "automation" of build tools to manipulate software artifacts in correct succession (thing that has been around already past 60 years) – so there’s no perceived value to have requirements or high-level abstract knowledge about the software to be represented in machine-readable form.

Today still a very big part of the development of business software is solving rather standard/common problems and is filled with the repeating tasks, which are very easily automated (like development of GUIs (where they are not the distinguishing factor), integrations, transformations, reports, etc.), and doing so would economize a lot of development time, but this will be only possible, if the requirements and high-level design would be formally specified and represented in a machine readable form.

So, the main question is "Do we want/need to automate also our software development activities?", or we just want to automate only the various business activities and continue with manual software development?

If we want to automate software development (i.e. digitalize the software development), we need a formal, machine readable, representation of requirements and high-level designs (with the focus on formalization and machine readability, not just some pictures with "boxes and arrows"), in the same way as for example to automate the credit origination, we need formal representation of customer, loan, collateral, sales process, involved business rules, etc.