Why Enterprise Architects are vital for Change Management - Part 2: OCM & EA

Organizational Change Management assignments often occur in large IT transformations, which are normally devised, planned and implemented with the help of EA (Enterprise Architecture). How does that title relate to other organizational architecture job titles (I am linking to the wikipedia definitions for easy access, and as a starting point, however, some of them have improvement potential)? And what makes close cooperation with an Enterprise Architect invaluable for me as an Organizational Change Manager - in order to ensure the success of the project?

Architecture job titles in blooming season

Enterprise Architect - plans & implements an organization's IT strategy. This may include all of the activities/designations below.
Business Architect - develops and aligns the business capabilities with corporate/business strategies & plans, frequently included in either EA or Sr. BA and/or OCM positions.
Solution(s) Architect - sometimes used as a synonym to EA, or acts as a go-between the strategic and operational players in programs, projects and architecture teams.
Software Architect, Applications Architect - basically the same, even though two different definitions exist in wikipedia. Lines up and aligns the landscape of applications in an enterprise.
Data Architect - defines and plans data storage, usage and management in systems and applications
Information Architect - does the same, additionally works with websites, intranet, taxonomies, and borders on the enterprise's knowledge management strategy.

A huge problem in transformation projects are legacy data, software, systems and, of course work processes.  
Metaphor for the lay person: If you have a TV, sound system, video recorder, CD player, game consoles for TV and handheld (different ones for each child) and maybe even a record or cassette player, some of which are connected to your PC or MAC, and you look at the CDs, DVDs, records, floppy disks and the cable salad behind your unit, upscale it to a 1,000 - 10,000 people organization, you might get a feel for what technology resources are dealing with.

A huge problem for organizations is to divide up the architectural work before the project, since the terminology and the boundaries between fields can be fuzzy. In the projects that I've been assigned to, I mostly had to do with Enterprise Architects (rather than the other titles listed above).

 

Close cooperation with Enterprise Architects to maximize success

I thoroughly enjoy working with Enterprise Architects, here's why:
When you hit the ground running on a new project, nobody can give you the low down on the lay-of-the-land as well as a good EA. Because (s)he has the eagle eye view, the EA can give you invaluable tips on peculiarities of this organization's specific environment regarding
- systems
- data
- processes, and, most importantly,
- stakeholders and sponsors
It won't take ages, because they can be as high-level as possible and as detailed as necessary. Enterprise Architects are usually pioneers and explorers, there is no better source for learning about technology and systems. A good EA knows tools & apps but is not fixated on them. 
Ideally, they are sounding boards and communicators, too. Most of the time, Enterprise Architects don't object to - and even enjoy - follow-ups further into the project, listening to the people side of the change and discussing patterns, systems and strategies. And if the Enterprise Architect says "she gets me" or "awesome work", you know you're on the right track.
Why does that make the project successful? The organizational strategy and change strategy need to be aligned to create authenticity, and, at the end of the day, be believable to the users. When the Change Manager knows the high-level perspective it is always possible to get "into the weeds" from there, the requirements, the processes, the communications, the feelings of resistance etc. etc. etc. Vice versa? Not so much..

Please do not hesitate to comment. Thank you.