A RADical Departure from the V-Model

One of the hats I wear these days is that of AE Safety Report Designer / Developer. In this role, I take the user requirements for the reports, mock them up and code them in whichever reporting tool is appropriate. This is fairly standard stuff, but I’ve found that moving away from my beloved V-model methodology for small activities pays big rewards. I’m talking about an iterative design/prototype/build loop that much more closely resembles Rapid Application Development (RAD). Is this a deviation from my beloved “Flying V”? Not really. This is just a unique approach to gathering and locking down user requirements that happens to work very well in report design. I use the final prototype as part of the design documentation, and the whole process is wrapped in the overall traceability of the V Methodology.


We start the process off with a standardized request form that the users / requestors will fill out to capture the basic business functionality and data requirements. I take this form and create a SQL version of the report (using TOAD) and export the results into a pre-formatted Excel template. I’ll adjust the formatting of the spreadsheet to get a preliminary “look and feel”, and send it off the requestor for feedback. They are responsible for making sure that the prototype meets their expectations, that the data is as they expect it, and that the layout works for them. Their feedback is incorporated into a subsequent prototype. Sometimes, it makes sense to actually sit down side by side with the requestor in the beginning to understand what they need, especially if the report is not of the standard AE Listing or Summary Tabulation variety. The end result is a set of SQL code and a report mockup in a spreadsheet that can be used when developing the report in whichever robust reporting tool is used to deliver these standardized, user-driven reports, such as Cognos or Business Objects. If you are wondering about the waves in the middle of the graphic, those are harmonic waves, hopefully spreading their soothing harmony to all involved in the process.

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.

Data Warehousing Best Practices

Data warehousing is not a new technology by any means. But it is one of those more intimidating subjects to many folks that don't have the experience or exposure to them. I've spent the past several years working on various data warehouses and data marts in the Life Science's industry, and have a developed a few tips and techniques to avoid some of the most common problems. Lets face it, Data Warehouses have a higher than normal rate of cost overruns and even project failure rates than other systems. This is largely due to the fact that they are complicated projects with several focused and specialized teams that aren't always communicating well. So I've put together a list of these "best practices" and my company, Intrasphere, published them in a white paper. Which makes it a prime candidate for sharing here.

Now, if you are a data warehouse guru, and you are looking for bleeding edge approaches that will shake the earth as you read, don't bother. This white paper is written for project managers and IT managers that may not have tons of data warehousing experience, but are looking for some pragmatic and practical advice they can both understand and use.

Data Warehouse Best Practices

As always, I appreciate your feedback and comments.

Administrivia - About Phar-B-IT

Thanks for checking out my new blog. I wanted to take a moment to "set a few expectations." Basically, I want to let you know what to expect and to ask for your feedback.

I started this blog for two reasons. The first was because I've spent quite a lot of time in my job searching the internet for templates, utilities, and advice to help me do my job. Unfortunately, I wasn't always successfull. So, I figured I wasn't the only one frustrated by this, and decided to share what I can.

The other reason is to network a bit. I'm hoping that if you're reading this blog, you'll learn a little bit more about me. Which brings me to my other request, the one for feedback. I'd like to learn a little bit more about all the folks that represent the dots on the ClustrMap over there on the left. So, please leave comments. Let me know which dot you are (where are you?) and what interests you. Let me know if there is something that you want my opinion on, or if you even disagree with me (you won't be the first!)

Now, I'll try to post as often as I can, and I'll certainly check the comments out daily. My target right now is to post about 2 - 3 blogs a week. I'll try to include some helpful templates at least 2 - 3 times a month in order to build up a nice little online library. And lastly, I'll try to keep the puns and bad jokes to a minimum, although this is probably the first promise I'll break.

Validation with a Flying V

When I was young, I liked my music and my technology new and cutting edge. But, like all things, as I grew older, I watched what was cutting edge become contemporary, and then contemporary become classic. Take Jimi Hendrix, for example. Here’s a picture of him playing guitar. When he started out, he was breaking new ground with his music. Then, he became main stream, and everyone wanted to be like Jimi. Nowadays, he’s on the Classic Rock and Oldies stations. Like the guitar he’s playing here. The Flying V was leap away from the classic guitar design. It was cutting edge, then became the norm for bands that wanted to project a cutting edge image. Now, like Jimi, the Flying V is a classic oldie.

And it makes perfect sense to me that my favorite SDLC (software development life cycle) methodology follows the same pattern. The V-model started as an innovative approach, breaking away from the norm of the traditional waterfall model. And, of course, it didn’t hurt that is easily associated with the coolest looking guitar the rock world has ever known (with the exception of Gene Simmons’ Axe, that is.)

As for why I like it so much, well, it’s all about the validation. I feel the V-model is the best methodology to support the typical validation approach. QA groups around the industry understand it, and like it. So do system designers, analysts and developers. And anytime a project manager can get both of those groups to agree, they’d be unwise not go along for the ride.


The idea is quite simple, create a matrix based mapping for each requirement, and trace the requirements through design, build and test in your documentation. My flying V methodology here outlines the traceability. The Unit Test will ensure the coded modules work according to the specifications. The OQ should reference the designed features and functions being tested, and ensure the system works as it was designed. And the PQ will ensure that the business requirements are correct and that the users can actually meet those requirements using the system.

Anyway, this has been my favorite methodology approach to validated systems over the past 10 years. Which for some reason is making me feel a little old today.

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.