Picture of Wisdom

Pictures convey a thousand words. But sometimes, the words may be in another language. For example, there is an article about knowledge management that describes the progression of data to information, knowledge, and wisdom that I liked. Here’s the URL: Data, Information, Knowledge, and Wisdom

Now, I figured that these concepts could be useful in describing the value of a business intelligence system to a group of business users (in this case, Medical, Clinical, and Regulatory folks.) After all, they know what data is, and they have systems that store information about each of their respective domains. They even shared some information in a few reports. But I was trying to convince them that we could use the data and information they had and go even further. I was hoping to build out some predictive analysis and pattern recognition dashboards to take their current level of Business Intelligence from “dimwit” to “genius” level.

But the picture in the article that caught my attention was not going to convey anything to this group. Here’s my version of that picture:



This picture was theoretical concept only. I needed to tie it to some systems architecture. So I imposed some familiar terms and concepts to lock the idea down. I ended up with a flow that was familiar, yet was able to convey the need to continue along the spectrum and give me some talking points about my vision for this new BI system. Here is my new, improved picture.


(can't read the picture? click on it for full size.)

Well, it worked. I was able to discuss possibilities in both visionary and pragmatic terms, pointing to points of the picture and describing algorithms, graphics, alerts and all the other cool BI stuff. It was much better than trying to do so pointing to a box that said “wisdom”. So, thanks to the guys at Systems Thinking for get me thinking about the value chain of BI in something other than servers, clients, and code.

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.