When will EAs learn traditional approach produce traditional results?

I keep seeing people advocating variations on the traditional approaches to EA that have not worked for a decade or two. Traditional approaches with result in the traditional results.

At best these approaches are often like communism - they sound sensible and if everyone did the right thing, in the right way for the right reasons - they might actually work - but that isn't the world we live in and they just don't really work.

Here are some things that don't work

• EA based on the religious adoption of frameworks (that have been around for decades with almost no examples of success). These frameworks are usually abstract high level methods that in academic sense may be correct but are so generalised that in practice they little more than common sense aphorisms. They may also be taxonomies that claim to be canonical despite the staggering changes in the nature, size, and form of the things they claim to organize. For example TOGAF reminds one of rat pie instructions (http://www.oocities.org/sunsetstrip/amphitheatre/8707/rats.html)
• EA that is a kind of software architecture or systems architecture (with its arcane notations and business alienating terminology). These initiatives are often rife with technical notations from various technical design discplines (data modelling, object modelling, process modelling etc.)
• EA modelling that produces lots of hand crafted pretty pictures and wall art. These things can, often with some difficulty be used to communicate a message, but on close inspection it becomes clear that they semioticaly and semantically inconsistent. They remind you of iconic-graphic art explaining myths or fables.
• EA done by some EA consultants (no the organisation itself). Consultant will tell you it can be done this way. NO it can't. EA can not even be done by EAs alone - it has to be done by the organization, it is an organizational activity.
• EA done for EAs as an abstract ivory activity i.e. it is not intimately connected to where the rubber hits the road. Solution architects treat it with bemusement. BCP planner marvel at its incompleteness. Its relationship to down stream executions (e.g. business requirements which in practice form one the key inputs to any execution) is at best unclear.