In enterprise architecture the "framework" holds a special role. In my opinion this is because enterprise architecture practice began with competing vendors in system integration, not in academia. Each participating company produced some competing conceptual model, and later this practice was adopted by government to conceptualize various parts of the practice. There are different types of frameworks, applicable to different levels and layers and mechanisms in the scope of enterprise architecture:
Frameworks for solution architecture (DODAF, TOGAF)
Frameworks for enterprise level architecture (ZIF, FEAF)
Frameworks for segment (Line of Business) architecture (FSAM, DODAF tailored)
Frameworks for enterprise architecture maturity (EAMMF)
Frameworks for sequence, such as an SDLC (INCOSE SDLC, IEEE SDLC, DoD SDLC, DHS SELC)
Frameworks for data or information architecture (Martin's Information Engineering, Oracle Case Method tm)
Frameworks for business architecture (Hammer's BPR...)
Frameworks for software architecture (Booch, SEI, UML)
Frameworks for standards and infrastructure (COBIT)
Frameworks for shared services (ITIL)
(Some believe in the ultimate "uber-framework", a mythical super-method like the "theory of everything" in physics. Personaly, I do not think frameworks should be expanded from their focus, where they are excellent, into areas of mediocrity. For the moment we must use multiple frameworks, or parts of several. I suggest picking a minimum set and using them with improving maturity. Standard, public frameworks are superior to proprietary frameworks for which one must pay: Avoid being held hostage by vendors of frameworks with recurring fees or mandatory services.)
"If you do anything long enough, you eventually get good at it." MK