I worked on CASE, and generally agree with this. I think it's important to note that there were a couple distinct markets for CASE: 1. Military/aerospace/data

I worked on CASE, and generally agree with this. I think it's important to note that there were a couple distinct markets for CASE: 1. Military/aerospace/datacomm/medical type technical development. Where you were building very complex things, that integrated into larger systems, that had to work, with teams, and you used higher-level formalisms when appropriate. 2. "MIS" (Management Information Systems) in-house/intranet business applications. Modeling business processes and flows, and a whole lot of data entry forms, queries, and printed reports. (Much of the coding parts already had decades of work on automating them, such as with WYSIWYG form painters and report languages.) Today, most Web CRUD and mobile apps are the descendant of #2, albeit with branches for in-house vs. polished graphic design consumer appeal. My teams had some successes with #1 technical software, but UML under IBM seemed to head towards #2 enterprise development. I don't have much visibility into where it went from there. I did find a few years ago (as a bit of a methodology expert familiar with the influences that went into UML, as well as familiar with those metamodels as a CASE developer) that the UML specs were scary and huge, and mostly full of stuff I didn't want. So I did the business process modeling for a customer logistics integration using a very small subset, with very high value. (Maybe it's a little like knowing hypertext, and then being teleported 20 years into the future, where the hypertext technology has been taken over by evil advertising brochures and surveillance capitalism, so you have to work to dig out the 1% hypertext bits that you can see are there.) Post-ZIRP, if more people start caring about complex systems that really have to work (and fewer people care about lots of hiring and churning code to make it look like they have "growth"), people will rediscover some of the better modeling methods, and be, like, whoa, this ancient DeMarco-Yourdon thing is most of what we need to get this process straight in a way everyone can understand, or this Harel thing makes our crazy event loop with concurrent activities tractable to implement correctly without a QA nightmare, or this Rumbaugh/Booch/etc. thing really helps us understand this nontrivial schema, and keep it documented as a visual for bringing people onboard and evolving it sanely, and this Jacobson thing helps us integrate that with some of the better parts of our evolving Agile process.