The Peter Principle and Enterprise Architecture

It seems to me that many Enterprise Architects have been promoted from technical and design roles they were excellent at to knowledge management roles and business transformation roles that are poor at. The poor at these roles because they lack both the skills and  the inclination.

They make not even be aware of what Enterprise Architecture is really about - that is to say they may not realise:

• Enterprise Architecture is about the business - so an understanding of business products, services, capabilities, plans, goals, strategies etc. should be their initial focus (if you don't get those right the details don't matter)
• Enterprise Architecture is NOT about Architects - and can't be done by Enterprise Architects per se. 
• Enterprise Architecture is about managing and applying knowledge about the enterprise across the enterprise i.e. it is an ongoing process 
• most methods advocated for Enterprise Architecture haven't worked, don't work and won't work.
• Enterprise Architecture is not SW Engineering (or SW Architecture) - it is in essence not even design or architecture per se. The "A" word describes the knowledge NOT an activity.

So you turn a wonderful technician - whose main interest are in technology i.e. not business; design i.e. not planning; having knowledge not managing knowledge; in what they do i.e. not what other people do, (not in changing the behaviour of the organization) - will struggle.

They will struggle even more if they think

• Enterprise Architecture has worked well in the past, so they should keep doing that
• Their role is to design (i.e. to architect) not to establish a approaches and solutions which allow architectures to emerge, be recorded, be analysed by a disparate community

This combined with no concrete objective (i.e. business relevant bottom line influencing measures) means that they survive happily with their "emperor's new clothes" artefacts based on the lastest abstract framework, method, etc.

They will skill fully apply Dawkin's Law of the Conservation of Difficulty - by advocating new "frameworks" and terms e.g. "viewpoints" and referencing people to abstract academic discussions rather than just using simple terms, plane english, simple approaches and just get on with what is in fact quite a simple exercise - if approached with the right mind set and solutions.

• Peter Principles: see: http://en.wikipedia.org/wiki/Peter_Principle

• Dawkins's Law of the Conservation of Difficulty states that obscurantism in an academic subject expands to fill the vacuum of its intrinsic simplicity. Theoretical physics is a genuinely difficult subject. Envious disciplines, which I shall not advertise, conceal their lack of content behind billowing clouds of deliberate obscurity.."

What is wrong with TOGAF in practice.

TOGAF is like a religion, so one has to be very careful about saying anything against it. But ...

There are no real facts to suggest it works in practice. Most TOGAF initiatives fail, and have failed for a decade, but everyone pretends else-wise and says the next version will be better.

TOGAF has hang overs from its origin, originators and vendor sponsors - most of  whom want to treat EA as if it is a super solution architecture (or even SW Engineering approach) which it is not.  So they suggest iterations - which make perfect sense so projects/SW - but are ill-suited to architecture and governance activities which are processes (i.e. continuous and incremental not cyclic and iterative). This is also to mistake EA for EA implementation (which is obviously a different thing entirely) just as using/applying knowledge management is a different thing from implementation a knowledge management solution/approach.

TOGAF places  requirements at the centre (which makes sense) but provides almost no information on how they should be dealt with (or what in fact they are); etc. And I suspect in their hearts they mistake business for SW requirements like most of the industry.

But putting all this aside the real issue is that TOGAF is just too abstract to be useful. What it says is often true, but is so facile as not to be useful.

If one wanted to implement Accounting one could:
a) implement an accounting system and immediately have a way to generate invoices, track debtors, apply tax codes, and have many reporting options (as starting points). One could then extend and adapt the system to meet any unique or specific needs.
b) read tomes on the locally applicable accounting methodology and tax codes and create an accounting practice using a mix of word documents, spreadsheets, etc. and perhaps creates one's own database. Then would could try and develop charts, reports etc. The system might work well for an individual who understood it well and it would keep teams of book keepers (often employed as consultants or contractors busy).
c) read an abstract method that encompasses the principles of all accounting methods globally with a set of abstract high level steps and building blocks - expressed so as not to relate to any country, organisation, domain, sector or system. It would be full of abstract aphorisms and concepts most of which make sense at some level - but provide precious little practical and pragmatic advice on what to actually do tomorrow.

The same is true for EA. As architects love abstraction, anything to get away from the business and business value, they always seem to favour c). Which is why they gravitate to TOGAF.

The challenge for many with a) is that it demystifies EA and makes it a prosaic thing anyone can use without needing to read a foot of paper on abstractions, frameworks, taxonomies, reference models, etc.   What architect will go for that?