The practice of enterprise architecure is not much different from other disciplines with respect to the fact that it has to be 'sold' to decision-makers in addition to being practiced. Project management, software development methodologies, and specific types of business and technology/business analysis face the same sheet of music in this regard. The short answer is that the folks allowing and funding such activities need to be convinced that they are making sound decisions and investments, and nothing substantial happens along these various lines without it.
Actual work output produced by enterprise architects can be generalized into two categories: output (primarily documentation and other artifacts) that support the 'what' side - as in 'what we're going to do about ..."; and the 'how' side - "how we will accomplish ..." and the actual results themselves. I'm using ellipsis here because I want you to think and fill in the blanks with items relevant to your specific situation or ones you've been in previously.
Although the two divisions of 'what' and 'how' definitely overlap (obviously, they must at some point), I've always found it helpful to make that distinction between the two so that the focus of whatever the deliverable is primarily meets the objectives of one of the categories, but not the other, or touches on where that interface to the other is without over-elaboration. Why? Because most of the time, you wind up with a magnum opus that nobody will read or use.
Other EA bloggers and I have noted previously that a proper balance must be struck between 'what' and 'how'' activities and deliverables. There is no magic formula here as that balance is unique to one's organization and the specifics of the situation at hand. Enterprise architecture frameworks such as Zachman, FEAF, TOGAF, etc. are useful at framing the 'what' side of EA issues. They have little or nothing to say about 'how.' That's up to the architects and what kind of alignment and concurrance they achieve with the business. While that last statement may sound a lot like 'buy-in,' from the business, it''s very difficult to get one's 'how' activities funded without it.
Let's talk about 'how' for awhile, since it gets short-shrift most of the time when we're discussing enterprise architecture. What I've seen too much of with respect to 'how' is those efforts becoming very narrowly-focused on development at the expense of other critical 'how' components, such as data administration & stewardship, interoperability, IT infrastructure, global services definition and categorization, IT process alignment and orchestration, among others.
It is not sufficient just to state "We'll use agile methods and deliver X with Y use cases (i.e. features) in time Z." That view, from an architecture perspective, is too narrow not only because its development-centric, but its overly focused on one application or set of them. That's more application team lead/design work, not enterprise-related. While that function is certainly necessary and must be performed by someone, its not enterprise architecture because most of what is produced cannot be applied across the business. EA's have to look at 'how' in the larger context, and development is only one of the components.
For example, I recently spent a significant portion of my 'how' time with data modelers. In this case, the modelers were reinventing the wheel for each new project - the definition of 'customer' or 'contract' could be synthesized to a generalized enterpise view of these entities, but for various reasons, they kept being re-modeled for every project that came into their offices. However, once they sat down and were guided in developing a sufficient and comprehensive enterprise definition of these entities, they now 'plug-and-play' the work they developed into logical models of new projects and free-up time to concentrate on the modeling more specific to the system under development.
This exercise and its outcome has a very positive effect on development because the data architectures are clearer, re-usable, and project-specific models and physical databases are produced much faster in tempo with development. And not one line of code was written to support this effort. There are other areas of IT where similar efficiencies can be achieved, and tied together, unifies most of various IT components such that application development becomes more productive regardless of the development methodology used.
I and others will most likely have much more to say about this, but for now, start thinking about 'how' more in enterprise-centric terms as opposed to 'development- or application-centric and see what type of clarity you achieve with your architecure.