Keep it Simple, They Aren't Stupid

System Architects like to draw pictures. Pictures often convey technical concepts much more clearly than words. This is because pictures have a way of dumbing down the details of system architectures to a level of understanding of most non-techies. This may sound a bit patronizing or pompous, but it's actually the opposite. If system architects spoke in clear language without overindulging in jargon, we wouldn't need such devices as graphical diagrams to get our meaning across.

I find that when I stop trying to impress my fellow techies by speaking in Acronymonish or Comptecheze, the business folks actually listen. And when they listen, they understand better the proposed approaches and or issues I'm trying to communicate. And when they understand me, they are in a much better position to trust and agree with me. Win-win, right? I think so.

I'm extremely lucky to have a straight talker as a mentor and role model (my dad, of course.) He is a civil engineer, and I always liked his no-bullshit approach to discussing problems and solutions with his construction clients. Instead of trying to make himself seem smarter by confusing the non-engineers, he would make them feel smarter by getting them to understand engineering concepts. And I've never met anyone that didn't respect that about him.

So, in order to help me get my ideas across to folks that don't have a technical background, I use props. A good diagram here, a carefully articulated metaphor there can make even the most computer-shy executive understand the concepts that may impact his projects.

Here is a real world example:


This is a very simple overview of the system integration between the various components of an Argus Insight Safety Data Mart. It shows the Oracle Database tier, the Cognos Reporting tier, and the Insight UI tier. The overlaps are the integration points, which is really the focus of this diagram. The key is to keep it simple, cover only the points you want, and leave the unnecessary details off the page. In this diagram, I was interested in showing how Insight leveraged the reports through logical groupings based on the Cognos packages. I also wanted to show how the table joins were Cognos constructs and not stored in Oracle. Finally, the red arrow was one of the key points: Insight queries the database when creating Case Series, and does not go through Cognos when doing so.

The why for the document was to set groundwork for explaining our recommendations for enhancing the reporting system, which is in the diagram still in my toolbox. Hey, gotta keep some things for the paying clients, ya know. ;)

This approach was much better received by the business than one used by another technician I know. The man had an ego the size of a Manhattan skyscraper, and never passed up an opportunity to drop big, scary techisms whenever he's with anyone. He thought if he sounded important enough, people would just defer to his wise and valuable judgement. Nothing was further from the truth. Inevitably, he insulted and angered the users and business folks, who stopped listening to him, and opposed his ideas just out of spite. Whenever he'd diagram out a system, he tried to throw as much detail as he could into it and it would become unreadable. He justified it by saying he wanted to be as thorough as possible. But this is just silly. A diagram will never truly represent a computer system in the level of detail he was attempting. Diagrams work only when they are simple and easy to read. They fail miserably when they aren't.

I have to admit, if you haven't guessed by now, this guy drove me nuts. But he was actually very important to my growth as a systems architect. By watching how business users reacted to him, I was able to learn how to avoid speaking down to them, and how to keep my thoughts, words and diagrams clear, simple, and to the point. And I've cashed in on this lesson time and again.