Architecture Speak
As I sit down to blog for the first time on the Enterprise Architecture blogs, a very fundamental question crosses my mind. That is how do architects speak, or communicate in general.
A very common occurance is to use a lot of buzzwords. I once encountered an architect who said "issue A and issue B are orthagonal". He meant A and B are independent of each other. Architecture patterns too - be they singletons or facades - can be confusing explanations to IT management and customers.
The main issue I wish to raise is that does our language need to be so threatening to outsiders. No wonder many times architects are described as out of touch or too abstract.
My experience is that messages to people outside the architecture community need to be in simple language. Business executives who often are sponsors of IT work, and hence of architecture projects, business operations managers, IT project managers are all interested in understanding the recommended course of action and the rationale for it.
While the rigour of architecture formulations is a necessity, very often architects use complex language to impress each other. Over a long period of enterprise architecture engagements, I have settled on simple and clear working and final deliverables that do not require translation before being tabled to the stakeholders
I will like to know your experience. What parts of the architecture speak, in your opiniion, are complex by necessity and need the relevant rigorous terminology? Do you or people you work with use long words just to impress each other? Or, as in the words of my above mentioned architect friend, need and practice are othagonal to each other?
See you around.
Rajeev Arora
Melbourne. Australia
