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.

The Right Tool

I've been working as a systems integration and technology consultant for 15 years now. Prior to that, I worked in the construction industry for 10 years. Surprisingly, I think there are many skills and approaches to problem solving that my previous vocation has given me that are very effective in my current occupation.

One thing I learned early on was the value of having the right tool for the job at hand. If you have ever tried to use a hammer on a screw you know what I mean. Of course, another thing I learned was how to make do with the tools you have at hand, even if it’s not the perfect tool for the job. In a perfect world, every time I needed a new tool, I’d just buy it. But that wasn’t practical back then, and it isn't now either. The real world dictates that I buy the tools I use the most, and make do with the ones I have for the odd jobs that require rare or expensive tools.

How does this translate to my current job? I’m currently working on a Drug Safety Reporting system, designing standardized and validated reports that the users will run on demand. We’re using the right tools (Cognos/Oracle in this case), gathering requirements, designing the look and feel, engaging the users and business experts to make sure we get the reports right. We’re also engaging the QA and validation teams to make sure our approach to design, development and testing is blessed by them. We’re slowly but surely getting the reports into the hands of the users that need them. This process is the right approach for the reports that will be used by groups of users time and time again. Monthly listings and summaries, annual and semi annual regulatory reports, and operational metric reports all fit into this category.

But what about the one offs? The reports that need run once? Sure, we can try to cover some of these with careful design of some broad requirements and push these through the process, but it still doesn’t fit 100% of the business needs. Nor does it make practical sense to dedicate the cost of the resources required to answer a simple question that a user may have about the data.

We could go out and implement a validated, fully-powered, 20 horsepower Ad Hoc query tool for a significant chunk of $$ (like Cognos!) Cognos would perfectly fit the requirement, but the cost of the effort of configuring the software, training users in using the Ad Hoc functionality, as well as the risk of them from shooting themselves in the foot due to lack of expertise in the data model is enough for my client to nix this. Hey! Wait! Didn't you just read above that we are already using Cognos? Yes, but we are using a "COTS" prepackaged set of frameworks and packages, something we can't change (invalidates the COTS support contract) and that has been deemed too "complicated and dangerous" for the average users. It's fine for the report developers (who are experts in this COTS), but not for the everyday user.

Instead, we could look into our toolbox and figure out how to use what we already have.
Like TOAD. We are already meeting these requests by having a small, core group of database experts write SQL in TOAD and export the data into either a spreadsheet or PDF. The challenge is to figure out how to use this tool in a way that can be validated and deliver quality reports, while keeping down the costs. Not impossible, and the validation effort is actually similar to implementing a new, off the shelf tool, but at much lower costs.

The key is to come up with an approach to developing the SQL, running and testing it, and delivering it to the users in a way that is approved by the QA group. The plan is to fully document all the fields commonly used, the tables and joins between the tables, and any special filters or business rules (such as determining relatedness via causality.) Basically, it's a documented brain dump of the aforementioned data experts. Then the approach is to take this coding standard and data dictionary and implement it with processes for requesting and delivering the reports, as well as templates that document requirements, SQL queries, and results for transparency. The result is that reports are delivered in hours rather than weeks it would take to code a standard report. And if any of these ad hoc reports is required on a recurring basis, the requirements are already fully documented and easily passed along to the standard report development team.

The bottom line is this: It's important to use the right tool for the job, but it's not always practical. As a consultant, I've learned to balance quality with pragmatism.