Enterprise Architects don't exist in every organisation. You'll typically only find them within enterprise scale environments. Even then, not every enterprise has one. Kinda sad but in an ideal world, an EA or an EA team are basically the true interface between the business and IT. I am a big believer that EA is a true enabler of good IT practise but more than that, good business practise too. I believe that security architects, security analysts, security managers, should all be working with their EAs in their business.
I will attempt to explain why - but firstly I will state this article makes a lot of assumptions. So most of this is based on theoretical best practise EA. Bad EAs or bad enterprise environments can easily screw this up but then again, same applies for security too.
Without further ado:
1) EAs have access to the C-level executives
Typically they deal with the CIO (at least they should be). This means they understand what is happening at that level. If they have the CIO's ear then they know what their concerns are, what their future goals are or possibly future direction. All useful intel to any security professional.
2) EAs understand the business
One of the earliest activities an EA does is deconstruct the business down to a series of key business processes. They also map out what infrastructure, applications and environments these processes use. This is critical information to any security professional looking to deconstruct the business and map out the security architecture. It can also be useful for determining high risk business processes, disaster recovery, business continuity planning, etc. The value of these artefacts cannot be overstated.
3) EAs have oversight of a lot (if not all projects)
A lot of the time, they are members of an Architecture Review Board - which can often mean they have access to any project going through a Project Management Office. Alternatively because of their acess to the C-level, they might be privy to rumors on the horizon for projects with rather scary security implications (e.g. transformation projects, outsourcing projects, etc). If you can, Security should have representation on such a board. Even at an informal level, they might just let you know what changes or projects are on the horizon - and why you should be concerned.
4) EAs recognise the value of security
Most EAs recognise that security is simply another architecture domain that requires specialist skills and knowledge. They should be engaging you and likewise you should be engaging them. A security architect that is a member of a EA team is able to see the business at a higher level, see the same things the EA team does and better able to align security with business need.
5) EAs can champion security
Closely related to point four, even if security is not adequately represented within an EA team your input can influence their decisions. You might be able to sit on an Architecture Review Board. They might be able to raise your concerns to the CIO. They might be able to incorporate your requirements and feedback into their designs.
6) EAs set (or at least influence) the technical direction
As EAs review the technical landscape within the business, they will often seek to consolidate around a series of applications, infrastructure components, etc. They will define technology stacks, roadmaps, etc. This can be invaluable to an savvy security analyst looking where to focus training (not just for themselves but other staff in key areas) but also investigate security solutions, guides, documentation, etc - utilising those same technology choices.
In summary, the forward thinking that EAs do every day can be invaluable service and value add to any time strapped, operationally focused security analyst. Even if you are the most strategic minded security architect, you should still be aware of the value Enterprise Architecture brings to the business. And when I say 'business' I mean information security too.