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.

Why Enterprise Architects are vital for Change Management - Part 1: What is EA anyway?

As a Manager of Organizational Change I have come to appreciate working with technology sources tremendously, in particular with Enterprise Architects. In my previous career as an expert for Organizational Communication & Development - working in lighthouse/pioneer projects and transitions of large corporate M&As long before this was even called change management - I had known IT people from some assignments facilitating teams, or teaching MBAs. When I got deeper into the IT world some 10+ years ago I remember thinking two thoughts:

• Wow. This is a completely separate culture within companies, much different from all other departments, you won't get anywhere in here without speaking what I affectionately call 'Geekspeak' (Watching 'The IT-Crowd' does help to overcome the culture clash, though..).
• And secondly, among my colleagues & friends or the (IT) Change Management Group at gpm-ipma, Germany's largest PM association, we absolutely agreed: If Change in Organizations goes wrong, it's almost always a "people problem".

I would like to reflect my view on this world back to you, maybe provide you with some fresh insights, and I'll start with the definition of Enterprise Architecture. There should really not be too many problems here, one could always look up wikipedia (how I dread the day I find out wikipedia is blatantly incorrect - always cross-check, boys & girls), or use common-sense.

Do companies know what to look for in an Enterprise Architect?

Flipping through companies' job postings, however, on the requirements side, one finds some must-haves that clearly display lack of ability to think on a metalevel. Partly, to be sure, because it makes measuring or filtering candidates' skills difficult.

Taking the term 'Architect' as a metaphor might be helpful. An Architect plans & monitors the building process of a house, she needs to know about plumbing or electrician requirements, yet doesn't have to be a plumber or electrician herself (*or himself - men are obviously included ;). Of course some time way back in her learning phase there might have been an internship, apprenticeship or practical studies field.

Back to Enterprise Architects and the metalevel. If an EA only needs to know ABOUT administrating systems, writing code etc. how can one assess if her skills are enough for a sophisticated job such as planning a business, its processes and technology?

I hear "Ask an expert" from the 3rd row. I am thus flinging this question to you, the experts among you. What criteria for skills and methods of Enterprise Architecture are indispensable to you, which parts do you value most? Is it more business or more techie or 50:50? How would you separate myth from reality? What are the obstacles in the daily routine? What difference does project management methodology contribute, scrum or waterfall?

 

I'd appreciate your input, to get a discussion going. Cheers!

And since I love thinking in terms of questions, here are the ones the next part(s) will revolve around: How does Enterprise Architecture relate to the many other Architecture job titles that seem to be in blooming season? Solution(s) Architect, Data Architect, Information Architect, Business Architect.. And what makes it invaluable for Change Managers to work closely with Enterprise Architects to ensure the success of the project?

Tune in..