- getting on the same page with respect to terms : what do we mean by application, process, product, service, etc.
- getting to grips with how we talk about change : what do we mean by current state, baseline, target architecture, building block, etc.
- getting to grips with terminology in different segments and domains in the enterprise
The list goes on and on. One of the top 3 things that people list as being a succesfactor for an architecture project is "help us talk to the other guys". Indeed, in many cases we see the intension is there: people want to talk to their peers in other departments, projects etc. If we all agree that this is a good idea, then how come it doesn't happen?
This brings me back to a previous claim: doing architecture - even with standards (like TOGAF) that people tend to think of as being IT-centric - is about the people. Helping them talk to and understand each other better will improve enterprise effectiveness.
Question to the reader: if you have any good approaches, examples, workshop forms, or other ideas to do these, let us know!