Last post Dec 03, 2005 02:40 AM by slope
Dec 02, 2005 02:16 AM|djbaldwin|LINK
Real World DotNetNuke – Part II
“But we have always done it that way.”
Yesterday has gone.
Today we have all sorts of ways to accomplish what we need. There are many stories about how things have always worked, but here are my two favorites from the U.S. Army.
The first involves a brand new warship with a fancy gunning system that could target anything in real time. The problem was that the fire button wouldn’t work for 15 seconds.
It turned out that this long practiced rule of thumb was implemented during the days of the horse and canon. The operator was supposed to wait 15 seconds after aiming the canon in order to let the horse settle down and not jerk the canon.
So they have this multi-million dollar, top of the line, technically superior gun that has a 15 second lockout feature because that was the way it had been done for nearly a hundred years!
The second story involves the Army procurement process. They needed a dependable supply of llama dung, as required by the specifications for treating leather used in airplane seats and jackets.
Due to unreliable shipping methods at the time, the Army attempted to establish a herd a llamas in New Jersey. No one suspected anything until someone had trouble filling the request.
It turned out that the US Army had copied the specifications from the British Army, dating back to Great Britain’s era of colonial expansion. New leather on saddles made the horses skittish
and unmanageable. Treating the leather with llama dung created a different odor that calmed the horses. The treatment became part of the leather’s specification, which remained unchanged for a century.
I’m sure you can look around your organization and find similar stories. Many people do not like change, and use the best excuses to keep things as they are. Because it has always been done
that way does not mean that it cannot be done in a different way. The trick here is to look for rote procedures and discover ways to improve the process.
In order to use the right tool for the job, sometimes you have to understand the job itself. Is this mass importing of data something that needs to be done at the end of the month? Why do we
have an end of day process? Why does this batch process have to run at night? Should the console to operate these jobs be on a web server?
I prefer to know about the exceptions rather then the things that work. I do not want to be notified of every order processed today; I am only interested in the totals and the ones that experienced
problems. Of course I can look up an audit trail to see what occurred, but I rarely need to watch successful processes.
Should I develop some fancy progress bar that displays naked women (or men) on my browser while I wait for a job to run? I have to ask – why do I have to login and click on something to launch
this job from a web browser in the first place?
That is an example of the wrong tool for the job.
Another system I developed uses SQL Reporting Services to display an invoice on the screen. That got me thinking… how am I going to display this invoice in a DotNetNuke HTML module?
The right tool is Reporting Services.
So I wrote a module to render the invoice using Reporting Services and display it within the DotNetNuke application. I can choose to render a Windows metafile, a PDF or an Excel spreadsheet, simply by changing a single parameter in the call to Reporting
Services. The payoff is that now a customer can login to the company portal, and view their invoice online. What they see in their browser is *exactly* what was printed on the invoice.
Now I ask, is there any reason to print the invoice in the first place?
Why not email the invoice as a file directly to the customer? Or email a link directly to the invoice and they can use the print module contents built into DotNetNuke. The customer can ultimately decide whether or not to print the invoice. Best idea
yet? Allow the customer to edit their online profile, and they can choose how they want to handle the process!
In any business process there are steps from start to finish. The best designed systems allow you to hook any process (i.e: pre-render, page_load, shipping, invoicing,) to add functionality.
For example, if an application allowed you to add a call to your .net code after printing an invoice, you could call a web service to update a dissimilar system anywhere in the world.
I love the commercial where they guy pays for his coffee with his bank card and waits for the debit to appear on his PDA. That is the way people want to work - in real-time. Jobs should not
be batched because that’s the way it has always been done.
Customer statements are another example of a wasteful process.
Not only is your organization wasting money printing and mailing the statements, they are always inaccurate and out of date by the time they are received. Put customer statements on line, and allow the customer to view it at any time.
Depending on your company, if you had a customer on watch, you can be notified that they just looked at their statement. So why not phone them while your statement is on their screen. (Slightly
nasty, but very effective.)
Look around your organization to see how you can make more things happen in real time.
Continued in Part III…
Dec 02, 2005 03:33 AM|IndianGuru|LINK
Hi, Great [:)]
By the way, where is "Real World DotNetNuke - Part I" ?
Dec 02, 2005 04:12 AM|DocHoliday|LINK
Dec 02, 2005 05:26 AM|Vodzurk|LINK
Hey, why doesn't somebody make a site just containing articles such as this one, with links to this board for discussions?
If only there were a portal system that allowed for quick setup on such things. *sigh* ;).
Dec 02, 2005 08:05 AM|dnncreative|LINK
Dec 02, 2005 08:15 AM|lomaxx|LINK
Dec 02, 2005 09:02 AM|IndianGuru|LINK
"Man, by nature, is resistant to change [:(]"
Dec 03, 2005 02:40 AM|slope|LINK
For those of you who have not read the Real world dnn part I.It's here.
Once again djbaldwin, you are "on the money". Well written. Looks forward to part III.
-Enjoy your weekend folks.