Wednesday, July 02, 2008
Enterprise Architecture and Avoiding Difficult Questions
Nowadays, many enterprise architects have no clue on how technology actually works and therefore outsource their understanding to industry analyst firms and software vendors who will graciously accept the opportunity to present a thinly-veiled chock-a-block PowerPoint presentation to their constituency. But, what should an enterprise architect do if afterward, questions appear that they have no answer for...
Enterprise architects in many shops have mastered the ability to avoid answering the question. Some of the tactics used are:
Consider, the second bullet and how it can be leveraged when you are clueless. The notion of seek first to understand, then to be understood (Seven Habits) can be used to gain clarification which is sometimes needed but often times used to cover up incompetency. The best way to detect this tactic is to ask the person to provide an answer using a few fictitious scenarios. If they can, then clarification is warranted, otherwise it may be a cover-up.
Providing generic references to some other authority such as Gartner in an IT sense provides an opportunity to not only defer debate since the recipient probably doesn't have that source of information at hand, but you can also count on them probably being too busy to followup. The last approach is especially popular with politicians (are enterprise architects politicians?) in that you can provide an answer to the question you wish you had been asked. The answer should be long enough that the real question is forgotten...
| | View blog reactionsEnterprise architects in many shops have mastered the ability to avoid answering the question. Some of the tactics used are:
- Attack the speaker
- Respond with a question of your own
- Question the legitimacy of the question
- Take a defensive posture and pontificate that everyone knows that
- Attempt to change the subject
- Provide generic references to some other authority
- Terminate the discussion
- Provide an answer but not to the question asked.
Consider, the second bullet and how it can be leveraged when you are clueless. The notion of seek first to understand, then to be understood (Seven Habits) can be used to gain clarification which is sometimes needed but often times used to cover up incompetency. The best way to detect this tactic is to ask the person to provide an answer using a few fictitious scenarios. If they can, then clarification is warranted, otherwise it may be a cover-up.
Providing generic references to some other authority such as Gartner in an IT sense provides an opportunity to not only defer debate since the recipient probably doesn't have that source of information at hand, but you can also count on them probably being too busy to followup. The last approach is especially popular with politicians (are enterprise architects politicians?) in that you can provide an answer to the question you wish you had been asked. The answer should be long enough that the real question is forgotten...
