One can meet it from time to time in some government organisations, but the actual fad is over I think, and - as usual - the original purpose very often has bee

One can meet it from time to time in some government organisations, but the actual fad is over I think, and - as usual - the original purpose very often has been replaced by some kind of cargo cult. Architecture frameworks have relevance in a system of systems context, to keep track which systems are part of it and how they contribute, what the interfaces and integration technologies are, who is responsible for these things. They have less relevance in a single system-of-interest development context, where the surrounding systems are best represented by interface specifications or control documents. Systems Engineering always had and still has (even if they are more and more forgotten) established methods for functional analysis and allocation of the functions to "systems" and "system elements" (see ISO 15288 for definitions), including interfaces, which allowed systems to be incrementally specified by interleaving analysis and design (see "Systems Engineering Sandwich"). This process works for all lifecycles and on all levels, also for system of systems (an "enterprise" is just a system itself). A good reference is Jeff Grady's "System Requirements Analysis" (preferably the 1st edition). Architecture frameworks came later, often "invented" by people not (sufficiently) aware of the existing System Engineering body of knowledge, and presumably more aimed at system users and operators than system developers.