Ask a couple of people what they think Enterprise Architects do and you will get greatly varying answers.
If you want to better understand the scope of Enterprise Architecture and if one or more Enterprise Architects can help you and your company in any way, please keep on reading.

Enterprise Architects Help Navigate Through Change

If you look at your company‘s organization, its processes, customers, employees, partners, market opportunities and so forth and see no requirements for any change as your world looks good as it is and no change seems to be coming up, then what would you expect an architect to do? Probably nothing. (Yet, in all my life I have not seen a single company, which has not been faced with changing circumstances at some stage, so this scenario is probably a bit unrealistic.)

If you plan no change, Enterprise Architecture is not required and would only cause costs.

Reduce Costs

Talking about costs: if they are too high and you want to reduce them, you would need someone to make transparent, where and how you can reduce costs. This would probably need an architect to first create an overall picture of your processes, the organization, technology and the relationship between all these things.
Someone would need to identify or even develop the company‘s strategy, so that you can cut off costs, which don‘t support your company‘s strategy and focus more on relevant changes which enable growth following your strategy. This can be done by Enterprise Architecture or other departments like Portfolio/Program Management, Governance, etc., but Enterprise Architects need to know these things at least.
In many organizations lots of energy is wasted on projects which don‘t support the company‘s strategy, and EA creates the transparency, which initiatives are going into the wrong direction, so that you can steer your company in a better way based on facts.
This way you can either adapt the direction or organization of an initiative or even stop some or start new initiatives.

Optimize the Organization

Other changes where EA can help are organizational changes. Let‘s say you want your company to be data-driven, manage IT in a better way, build up an Enterprise Architecture team and build up a product organization which puts the customer in focus and drives innovation.
You hire the first smart people to build up all these things and then they develop their own strategies to build up their departments and try to apply industry-accepted frameworks. COBIT might be used as a framework for IT management, TOGAF for Enterprise Architecture Management, any data-related framework to become data-driven, and Scrum for your product organization (maybe even LeSS or SAFe if you plan big).
If you let all these initiatives develop their own paths and apply the frameworks without adapting them to your company and without merging them into one common organizational approach, your organization will become overly complex and slow with far too many people blocking each other‘s work.
EA‘s task in this scenario would be to prioritize the different initiatives and their tasks against each other and reduce them to an organizational and technical model which serves the company‘s strategy best.
E.g. if you make approval by Enterprise Architecture, Security and Data Governance a requirement for your Scrum team before any new feature can be used in production, this would create complex and long-running processes which would delay your feature development. This is no major problem if these things are a regulatory requirement and apply to all your competitors as well, but they are a serious problem if you are the only company in your market segment which becomes slow due to all the organizational complexity.
EA can align the initiatives with the company‘s strategy and make sure that the relevant parts of these frameworks will be integrated with your company‘s roles and collaboration approaches, while the not so relevant parts of the frameworks will be ignored.

Define Future Technical Structure

In many companies EA is supposed to be responsible for the IT architecture, which for most people is the technical structure, not so much the organizational structure of IT.
Again, as mentioned above, it‘s not about the current state. If nothing needs to change, you don‘t need an architect. It‘s more about “What should our technology landscape look like, and how do we get there going which steps? Where will we be when?“.
Enterprise Architecture develops a target technical landscape as well as a roadmap how to get there. This implies that at some stage you need to understand where you start from, so you will need to collect how your technology landscape looks like today.
As Enterprise Architects collect technical information, too, in many environments EA is seen as a pure IT thing. Yet, EA aligns all IT things with the company‘s strategy, its organization and processes, so I would say, EA is about 50% IT and 50% business (if you can separate the two at all).
Still, some general technical architecture patterns can be developed by the EA team, like domain-driven design approaches, event-streaming, etc.

What‘s the Difference between Enterprise, Domain and Solution Architects?

Thanks a lot for asking, this is one of the common questions I get.

Let‘s say your organization develops a handful of software applications, which enable other employees to do their job. Each application is being developed by a dedicated product team, which has all the team members it needs to develop the product.

A Solution Architect would develop the architecture of a single product. This includes defining non-functional requirements as well as balancing all the incoming requirements when developing the architecture of the solution. The Solution Architect needs to be very-well educated regarding decision-taking, so that the proposed solution aligns with the company‘s strategy as much as possible.
The Solution Architect communicates with POs, Business Analysts, Requirement Engineers, UX Designers, Data Governance, Enterprise Architecture, etc. to understand requirements and with the development team to discuss what the proposed solution shall look like.

While the Solution Architect is responsible for a single product, a Domain Architect is responsible for a collection of products. E.g. a domain architect might know everything regarding media management and therefore define solutions for multiple product teams which deal with this topic. The domain architect might have the role of a Solution Architect in multiple teams, or – when each team already comes with a dedicated Solution Architect – the Domain Architect connects the dots and makes sure the overarching structure across the teams in his domain supports the company‘s strategy, while the Solution Architects define the individual products in more detail. Domain and Solution Architects need to be aligned.

While not every organization has domain architects, it‘s common to have Enterprise Architects to align all Solution Architects. Enterprise Architects are responsible for the overall architecture, which means, they need to create an environment which builds the right architecture.
They set up a central EA repository and processes to let the Solution Architects populate the central repository with information about all products, connect these to processes and business capabilities, etc. so that for each product or project you can draw a line from strategy across business capabilities and processes, people, etc. so that for any major change in one of these areas you can easily identify affected segments. This allows you to find out what happens when you fade out an application or modify some important processes.
Enterprise Architects are responsible for Enterprise Architecture Management (EAM). This means they develop processes to improve the architecture of your company. They can follow mature methods like TOGAF‘s ADM (Architecture Development Method) or define their own approaches. Whatever fits best into your company‘s environment. In conjunction with portfolio or program management they define roadmaps and processes to keep them up-to-date.
One important aspect of the EA‘s work is to build up common knowledge regarding decision-taking, architectural methods and architecture guidelines and principles across all architects within the company. One way to do this is by building and managing a community or guild which shares knowledge and takes decisions whenever more than a single initiative is affected.
A more conservative approach would be to govern the domain and solution architects by introducing EA quality gates. Yet, this doesn‘t scale as much as common ideas, so in larger environments with little regulations this approach might be a bit outdated. In environments with much regulation having EA quality gates still makes sense.

Enterprise Architecture and other Departments

If Enterprise Architecture is responsible for the architecture of a company, this can easily overlap with the responsibility of other departments.

To develop products with Scrum, you would take a domain-driven design approach to identify a business domain and build a product team which builds the appropriate solution. Designing the organization is the task of a dedicated department in many companies. Identifying the technical domains is usually a task for the Enterprise Architecture team.
If multiple product teams share a technical platform, the technical dependency has an impact on the organization above. You need to consider both technical and business domains to build a great organization.

At the same time an EA team can have specialist members like infrastructure architects, which might raise discussions with your security department.

In all these cases you can either negotiate and define RACI matrixes (who‘s doing what), or you simply accept that you all serve the same purpose to improve your company. Then we just need to make sure that we all understand the strategy of the company, the methods how to take great decisions, and then we decide who takes over a task, depending on availability and skills.

When it comes to distributing work across your company, it‘s not about “Who gets the power to take decisions and over-rule other stakeholders?“ It‘s about “Who has the skills and the time to drive a topic?“

Responsibility means you need to make sure that all relevant interests have been collected and considered and that you find a solution which trades off all the interests into an action everyone commits to.

Typical Questions

My company is quite small. We‘ve been growing a lot lately and plan to continue so. But aren‘t we too small to hire an Enterprise Architect?
Good question. Enterprise Architecture as a department usually exists in larger companies with thousands of employees. Aligning architecture with the company‘s strategy can be done by a single person, if it‘s possible to understand the strategy easily and you run a handful of applications only.
If you have so many applications, processes and business domains that you need more architects, usually at some stage they specialize into Solution, Domain and Enterprise Architects.
To understand at which stage hiring an Enterprise Architect makes sense, more aspects than your company‘s size need to be considered.
Is the company‘s strategy clear? Do you need help with aligning strategies spread across your company? Is it clear which parts of the company support your strategy? Are the processes across the departments defined and effective? How do you want to organize your company to deal with expected growth? How can you move decisions into the future? How can you secure data?
Once you grow and need to employ more developers and architects, how do you find appropriate employees? Is the technology you are considering future-proof? Are you working on the right things?
A good Enterprise Architect can help you with all these things, so getting an Enterprise Architect onboard can be helpful at a much earlier stage than you might think.

Do Enterprise Architects Configure Servers or Develop Software?
The quick answer is no. The longer answer is: most probably your Enterprise Architect at some stage has developed software and/or configured servers, but has not done that in production for quite some time. Enterprise Architect is a role most people take over at a later stage in their professional life. Before that lots of us have had experiences as developers, systems administrators, business analysts, requirements engineers, product owners, product managers, technical writers, speakers, process designers, project managers and so on. This means EAs are able to do a lot of things, but don‘t expect that they are world-class in everything they have done.
People say EAs are T-shaped, meaning they have very broad knowledge (the horizontal bar of the T), but can go very deep whenever necessary (the vertical line of the T). Most EAs have gone very deep in certain areas and might have been world-class at the time, and have collected very broad knowledge over the years. When you ask them to configure a server or develop some code, they might be able to do so, but they probably won‘t be as quick as dedicated systems administrators or developers. (Or they might be much faster, depending on the EA :-))

Conclusion

Enterprise Architects know a lot about business and technology and can provide you with context and methods whenever you need to take great decisions to develop your company to the better.