The concept of an enterprise architecture (EA) will differ significantly from organization to organization, IT shop to IT shop, and from IT professional to IT professional.
An entire discipline for defining enterprise architectures exists for large IT shops, particularly in the federal government space. John Zachman is widely consdiered the father of this science with the Zachman Enterprise Framework which he introduced while with IBM in 1987. This was followed by the DOD’s Technical Architecture Framework for Information Management (TAFIM) and then The Open Group Architecture Framework (TOGAF). Some IT managers may have a current and published enterprise architecture to latch on to, but most either do not have that or if they do, it is outdated and/or not relevant to their daily lives.
Regardless, most IT managers do not require a formal EA, but they do need some type of understood technical blueprint from which they can take directions and make decisions. It provides cover and rationale for design choices, a structure for technologists to plan within, information for service providers, and a roadmap for the future.
Now, for managers in larger IT shops, the term “Enterprise Architecture” itself may be highly political. It may only be reserved for the planning group at headquarters or “architects” who publish papers and sit on IEEE boards and other industry consortium. Thus, a manager over a Unix department might want to have a Unix Architecture document, or even the more benign Unix Engineering document. But in practice, the name of the document is not as important as its existence.
The IT manager may be tempted to completely delegate compiling and drafting the EA document to their architect/engineers or, for larger organizations, technical writers. Resist that temptation. This is strategic.