If you are puzzled about what the title stands for - read on. If not, you may as well read on.
The use of acronyms is now everywhere in written language. It gets to a point that you have a hard time understanding what is being told. If you eager to find out you will try to look them up, but in most situations you will feel left out and so you leave.
We all understand that acronyms in systems makes sense. Why use lengthy words or descriptions if you can express it in few characters. Back in the fifties when IBM was building the handful mainframes the world needed, it made perfect sense to use a maximum of 6 characters for a variable, procedure, function, macro, subsystem, part, mascot. At some point that phase was over and a committee designed COBOL (COBOL = Common Business Oriented Language). COBOL was set up that if you want to add 1 to a variable you had to write something like "ADD 1 TO COUNTER"
Having said that, what does this mean for an IT architect? It means that use of acronyms causes your most important stakeholders to leave you. And I mean the stakeholder that pays for your contribution. The stakeholder that realizes your solution, who will not be able to understand the essence of your views.
What should the IT architect do? Use plain language as much as possible when communicating with your stakeholders. The use of visuals is powerful, but they can also tell the wrong thousand words. All visuals should be supported with language. Don't be so afraid that your text is to lengthy, even if business people seem to have so little time to read. Write down what has to be said. Put the essence in the beginning of your story, if you feel that your audience won't read it all. If they are really interested they will read it. And last but not least, don't use any acronyms.
DAHWCTM = Do Acronyms Help With Communicating The Message?
© Peter Bodifée 2009. All rights reserved
