Nick Malik poses an interesting question here—are we making things difficult for ourselves by calling Enterprise Architecture Enterprise Architecture? His point is (if I've got it right) that architecture work is kind of crunchy, focusing on very well-bounded and defined outputs, whereas EA work is delivered within a different context. Enterprises morph over time, and enterprise activity can't be controlled or designed in the way that a specific project can. EA teams don't (or shouldn't) define things with hard boundaries: they should attempt to influence growth and change. In the context of our book, our take here would be that EA is much more like garden planning than it is like cathedral design. As any gardener will tell you, unlike cathedral design, gardening is not a one-shot activity.

Moreover Nick echoes many others in calling out that EA work is often compared to city planning and that city planners (or other similar types of entities) don't describe their work as "architecture". He has a great point—ideally EA shouldn't be called EA. It is a kind of discovery, planning, policy-setting and policy-enforcement practice; I'm even tempted to talk about it as a governance-like thing.

However we're hampered in this (as in so much else in the world of IT and business) because the language in this area has already been claimed. It will take a big effort to change the conversation.

Before we can do that, we have to settle on a term that makes sense and reflects reality, and this I think is the biggest challenge. Inertia is a powerful thing (how often do we change our personal banking provider, even though we're frequently told how important it is to consider?).

So—if not EA, then what?