Do I have to build models in order to do Enterprise Architecture?

Enterprise Architecture is all about PHYSICS. Nothing magic is going to happen and you can’t create something out of nothing… no matter whether you want to hear this truth or not.

Here are some of observations:

1. If you are not building models, you are not doing any design, you are only manufacturing.
2. If you are not building PRIMITIVE Models, you are not doing Architecture, you are implementing.
3. If you are not building the higher Row models, there is NO WAY you are going to produce anything that will be aligned with what management has in mind. (You can build a prototype, but remember that is not "design" and if the prototype becomes operational, you are DIS-integrating the Enterprise at a VERY granular level.)
4. If you are not building Enterprise-wide models, you are implementing "stovepipes," "islands of automation."
5. If you are not building excruciating level of detail models, you are making assumptions about the details and then you will have potential defects… which, will have to be removed at some point and the closer you get to implementation before you find the defect, the more it is going to cost you to get the defect out. (Look at your "Maintenance budget.")
6. If you are not retaining the models you build, your underlying assumption is that nothing is ever going to change… because if something changes, you are going to have to reverse-engineer the models from the running code… IF there is enough information left in the running code to reverse-engineer them.

Sometimes, isn't redundancy and complexity necessary or even desirable? For instance, isn't a large retailer more successful with thousands of redundant stores and massive complexity?

You can have as many instances (redundant retail stores) as you want in Row 6:Operations Instances, but you only want a single abstraction in Row 1:Scope Contexts, Row 2:Business Concepts and Row 3:System Logic. It is conceivable to have more than one abstraction in Row 4:Technology Physics and Row 5:Tool Components, but if you do, you have to keep track of them as they relate to Row 3:System Logic or else you will go out of control- potentially have an entropy problem. They will get out of sync.

That is, you don't want any discontinuity in the Concepts (Row 2) or the Logic (Row 3). It is conceivable that you might want to implement in more than one Technology (Row 4), but now you have a synchronization problem that you will have to manage. 

In terms of Row 6:Operations Instances, there can by "n" of those, but you want each instance to trace back to the Components Transformation (Row 5), the Physics Transformation (Row 4), the Logic Transformation (Row 3), and the Concept Transformation (Row 2), and probably the Scope Transformation (Row 1) as well. That is how you insure that the reality of the Enterprise is consistent with the Enterprise Architecture. And when the "Systems" say there are 423 Employees in stock, there are actually 423 Employees in stock, etc., etc... and when we say the Concept "Employee" (Row 2:Business Concepts), it means the same across the entire Enterprise and that all the Employee instances (Row 6:Operations Instances) obey that authorized Enterprise Concept (Row 2:Business Concepts) definition.

If you did this, you could actually manage the Enterprise.

Why is Rapid Application Development really Implementation and NOT Architecture?

Usually, by its very name, a "rapid application development"- style methodology’s Enterprise engineering design objective is "IMPLEMENT" as soon as possible. The engineering design objective for rapid application development-style methodologies is NOT Alignment, NOT Integration, NOT Flexibility, NOT Interoperability, NOT Reduced Time-to-Market, NOT Quality, NOT Security, etc. Those Enterprise engineering design objectives actually require ENGINEERING. Engineering requires PRIMITIVE MODELS, the "raw material" for engineering. Primitive Models are "analysis/paralysis" relative to rapid implementations… UNLESS, you already have the Primitive Models in inventory, in which case, implementations are virtually instantaneous, a click of a mouse, ASSEMBLE TO ORDER… BUT, the investment has to be made in the Primitive Models BEFORE you get the order for the implementation.

So, if you want the short-term approach, that is, to get to implementation as soon as possible, forget about models, write the code. Build more legacy.

On the other hand, if you want the long term approach, that is, if you want Flexibility, Integration, Reusability, Alignment, Security, Interoperability, etc. forget about the code, start building (Primitive) models. In fact, if you want to reduce the time it takes to produce an implementation to just the time it takes to click a mouse, then start building up an inventory of reusable, Primitive Models.

How do you "cost-justify" Enterprise Architecture?

Technically, you can't cost-justify Enterprise Architecture because Enterprise Architecture is NOT an expense... it is an asset. Cost-justification is an expense-based concept that has to do with saving money in the current accounting period. In contrast, return on investment (ROI) is an asset-based concept that has to do with deriving value in multiple, future accounting periods through reusing an asset in which an investment was made. Enterprise Architecture does not save money in the current accounting period. Enterprise Architecture requires an investment which can be reused to derive value (potentially, a LOT of value – assuming it is engineered effectively) in multiple future accounting periods.