Discussion on:

Specific solutions for the IT department

Scott, thanks for the links. If there are SA's like me out there theoretical doesn't help much when your too busy to spend hours researching, give me links to point me in a direction.

I have to say when I read the first article I said "this guy is crazy I can create patch cables quickly in my sleep". I decided, though, to run the numbers especially since STL is so close and if ShowMeCables quality vs price is that good I would have to consider them. Even at my best, due to my payscale, is would cost me nearly 4.50 to make a 10ft patch cable, much higher than I can purchase them for.

Opportunity costs - I hate making cables, but I can make a single one faster than I can fill out the paperwork to order it, and a lot faster than it takes to get it delivered. Obviously, the advantage goes toward purchasing when I buy them in larger quantities; the paperwork takes just as long whether I order a quantity of one or a quantity of 25, and the delivery doesn't matter when I order a variety of lengths to keep as inventory items.

Manually installing software - again, it's a question of volume. I have a handful of programs I install maybe every other month or less. It's not worth building an SCCM package, troubleshooting it, creating an advertisement, etc, for an app I install that infrequently.

Cheaper is not always better. And diminishing your job / role to nothing so you have more time to work on your resume doesn't make sense to me.

Being a Reporting Application Developer /. Data Analyst for over 20 years, I only sort of agree. Organization should "proceed with caution" when trying this. Yes, the end-product reports can totally be generated by a well-versed Business User...BUT...the organization MUST have checks, balances, and an IT support staff put in place in case something goes awry, To name a few: all their data organized in such a fashion that #1: it is accurately placed on non-critical-to-operations table specifically for end-user usage or they will bring down the servers due to a bad query seeing that it is quite hard for those business users to distinguish an AND from an OR (requesting data for City=Chicago OR State=Illinois can really make a system DBA quite angry); #2: joining the data to many sources by end-users is restricted or they will send the query language's hardware into doom by running full-table scans to hell and back; #3: the organization has a Subject Matter Reporting Application developer(s) AND QA staff who knows that data inside and out to double-check numbers BEFORE they are released for public knowledge. While the theory sounds simple, TOO many items must be put into place BEFORE attempting this feat or then you will have reports that make the Enron fiasco look like fun at Disney World. Do you really want an organization where everyone has their own version of the proverbial "truth"? Then who will it get dumped back to when it falls apart because they won't know how they tweaked their numbers? IT? QA? Trust me. one of the many situations that stands out the most for me was where an end-user created his own reports only to find out that it was my job to band-aid his error when he did not do his due diligence and research his numbers before posting them to the executives. He actually called me from the meeting on speaker with lots of executives in the room, accusing that MY numbers in the tables were bad because the executives were questioning them. When I asked what he was referring to, I had the knowledge that he did not to state that that different departments define net sales a bit differently so I pushed back to him on which version was he trying to display? Needless to say, he wasn't with the company much longer than that and it unfortunately left a bad taste in the executives' mouths so they decided against this sort of flexibility and it once again fell back on an under-staffed IT to pick up the pieces.

I worked for a manufacturing company where IT collected data across the factory, but we allowed engineers to play with the data using (if I remember correctly) SQL Query Builder. They were playing with copies or views of the data so performance issues they created would only exist in their world. I never heard of instances where the engineers tried to blame IT, but maybe this was because they had enough math skills and smarts to understand their results and enough integrity not to place blame wrongly. I agree that vetting data that will be published publicly is important and would be an important function for IT either in the report development process or as QA before being published.

Somebody needs to check the logic used in the query. Otherwise you may get one of those reports that compares ice cream consumption with drownings and concludes there's a cause and effect relationship.