General discussion

Locked

Blogging IT One Word at a Time

By Bill Elmore ·
Tags: Off Topic
blog root

This conversation is currently closed to new comments.

65 total posts (Page 5 of 7)   Prev   03 | 04 | 05 | 06 | 07   Next
Thread display: Collapse - | Expand +

All Comments

Collapse -

Death by printing and political maladies

by Bork Blatt In reply to Death by printing and pol ...

<p><strong>I say: "Make 'em walk!"</strong></p>
<p>If they can't justify a walk down the hall to fetch a document they just printed, then the printout can't have been that important, could it?</p>

Collapse -

Death by printing and political maladies

by br123456 In reply to Death by printing and pol ...

<p>I read an interesting article a few years back about how it came to be that the printing subsystem of Windows 95 (or maybe it was w9 was a massive overhaul of the previous version.  It took an opinionated Alex St. John, then an evangelist at Microsoft, to express that the current printing subsystem of the time was a mess.  He caught a lot of flack and ruffled the feathers of a lot of MS developers at the time, but it did get the attention of Bill Gates.  It was dedided that an overhaul project should proceed.  They did so and in the end, a major overhaul was completed and desktop printers flourished.  Since then, however, the architecture has not seemed to scale up and is viewed by many to be clunky and error prone as described.  Maybe it is time for MS to take a serious look at that architecture again.</p>

Collapse -

Death by printing and political maladies

by straightshooter In reply to Death by printing and pol ...

<p>I've joked about this issue frequently over the years and I believe I have designed the perfect solution. </p>
<p>Here it is: The output tray of every printer feeds directly into a paper shredder. This eliminates the loss of productivity caused by someone having to go get the document and then put it in the shredder. Maybe HP or one of the others will jump on this idea. Remember, you heard it here first!</p>

Collapse -

Death by printing and political maladies

by toilone25 In reply to Death by printing and pol ...

<p>The paper flood is caused in large part by IT's refusal to provide sufficient screen space to allow users to view 2 documents or applications at a time.</p>
<p>I have a 20" screen at home and I can put up 2 window side by side and get real work done on a computer that is not even connected to a printer.  The miniscule screen I have a work requires terrible gyrations or I print out one output to reference while I work on another.</p>
<p>That used to be excusable because scress space was expensive.  Not anymore.  Admit it you IT types all want systems so secure that all of those pesky users are locked out entirely.  "Send them back to a pencil and a Big Chief Tablet."  That's your motto.</p>

Collapse -

Sticking to your standards in the face of pushy vendors

by Bill Elmore In reply to Blogging IT One Word at a ...

<p class="MsoNormal">I assume it?s the same situation everywhere, but more and
more vendors seem to play by their own set of rules rather than the
customer?s.  They attempt to anyway.  It?s not enough to review basic system
requirements posted on a web site.  You
have to really ferret out the details of what installing the vendor?s system
means.  Almost like a reporter
researching a good story, you need to know what questions to ask and who to
ask.  You need to analyze the data and
piece together the puzzle.  They may not
always be forthcoming with the information, especially if they think it could
be a deal breaker.</p>

<p class="MsoNormal"></p>

<p class="MsoNormal">Will users need to be local administrators to run the
client?  Will the application need its
own VLAN or completely isolated network? 
Are there conflicts with their requirements versus your Group Policy
settings for items such as password length or other security settings?  Are there special requirements for running
antivirus or backup software?  Are
certain components still using 16-bit code or defunct unsupported third party
plug-ins?  Does the vendor insist that
their server not be a member server of the company domain?</p>

<p class="MsoNormal"></p>

<p class="MsoNormal">The list of questions can go on nearly forever, but it?s
important to expose the facts prior to signing a contract or giving your stamp
of approval for all things technical. 
The trend I see occurring is vendors wishing to isolate their application
as much as possible from a customer?s environment; attempting to protect
themselves from support calls and blame due to a change or outage on the customer?s
side.  This is somewhat understandable
given the growing complexity of IT infrastructures and the support nightmares
which can arise.  Finger pointing often
ensues.  But isolating every installed
system just is not feasible or practical. 
</p>

<p class="MsoNormal"></p>

<p class="MsoNormal">As an example, a vendor I am currently working with is
requiring that their servers be in a separate domain and a two-way trust
relationship established with our domain. 
If we wish to instead make them member servers as is our policy, then
they require that we sign a waiver release form to absolve them of
responsibility should a change to our environment cause a system outage.  This all seems ridiculous to me, but the
company reports that ?95%? of their clients go along with the separate domain
scenario.  I have a difficult time
believing that figure unless most other customers are relatively small and have
unstructured IT departments.  In this
case, the vendor is attempting to impose their will on the customer, and
effectively disregard a company?s established IT implementation best practice.  This would set a dangerous precedent if allowed,
and make us susceptible to numerous security threats, not to mention, we would
lose our ability to manage devices on our network.</p>

<p class="MsoNormal"></p>

<p class="MsoNormal">While segregating systems in an effort to improve network
performance and stability are nothing new, making customers sign responsibility
waiver forms is, at least to me.  Obviously
there are a couple points of contention here. 
The trend toward application isolation wouldn?t be as prevalent if
software makers wrote more sound software that adhered to generally accepted
coding standards, and companies always followed best practices and were
proactive in maintaining their IT infrastructure.  In lieu of a perfect world though, vendors
and their customers should jointly research the environment and software prior
to beginning implementation.  This could
serve to determine potential pitfalls and also develop action plans that are
agreeable to both parties.</p>

<p class="MsoNormal"></p>

<p class="MsoNormal">Allowing each vendor that walks through your door to set the
rules of engagement will never work in the long run.  Each environment is different than the next,
and each company must create reliable IT policies that protect the stability of
<b>all</b> their supported systems
collectively, not just one going in today. </p>

Collapse -

Sticking to your standards in the face of pushy vendors

by Michael@FriarTuck In reply to Sticking to your standard ...

The author seemed to put the blame on software development. "..if
software makers wrote more sound software that adhered to generally accepted
coding standards..." failed to acknowledge the fact that most software projects failed not due to a lack of following coding standards.<br /><br />One of the top reasons for failure of software development project is that users can't make up their mind of what they want and yet want the project to complete in a timeline that would seemed unreasonable to most software developers.<br /><br />A tight deadline with alot of changes over and over again is definitely going to result in failed software projects.<br /><br />Michael, CITPM, PMP<br /><br /><br />

Collapse -

Sticking to your standards in the face of pushy vendors

by david In reply to Sticking to your standard ...

<p class="MsoNormal"><font face="Times new roman" size="3">After many years of implementing core business and ERP applications I can say without hesitation that the biggest reason for problems at implementation or post implementation are the customer required customizations.<span>  </span>While there are some differences from one business to the next most applications are flexible to allow for most of these differences. <span> </span>If you are installing a best of breed application and you have done your research you should not need customizations. <span> </span>If you do then you may want to review your business practices to see if they are inline with the industry standards.</font></p>
<p class="MsoNormal"><?xml:namespace prefix =" o" ns =" "urn:schemas-microsoft-com:office:office"" /><o><font face="Times new roman" size="3"> </font></o></p>
<p class="MsoNormal"><font face="Times new roman" size="3">The short of it is if you require the vendor to customize the application for your install then it will not be as sound as the base application.<span>  </span>Your vendor is the expert on their application.<span>  </span>If you trust them you should follow their recommendations (not blindly). <span> </span>If you don?t trust them then suggest to the powers that be that you not do business with them.</font></p>

Collapse -

Sticking to your standards in the face of pushy vendors

by sr10 In reply to Sticking to your standard ...

OK, maybe 95% of the people who actually bought the product signed the waiver. What percentage of the people the vendor called on actually bought? What percentage of the people they called on laughed them out of the building when they mentioned their waiver?

Collapse -

Sticking to your standards in the face of pushy vendors

by kovachevg In reply to Sticking to your standard ...

<p>From a technical stand point, it makes a lot of sense to isolate an application server in a separate domain. That actually helps the customer by protecting him from the complexities of securing an exposed system.</p>
<p>The difficulty in this case springs from the fact that the customer needs to have the expertise to manage this new scenario - now the customer needs to dedicate a skilled system administrator who is proficient in subnetting and network routing and to purchase a reliable VPN solution.</p>
<p>If the vendors were smart enough, they would package their application with the VPN solution that would transparently deliver the services to the customer's netowork. Pitching security and reliablility to complete this sale is paramount.</p>
<p>Vendors and customers alike tend to play the BLAME GAME. It's kind of easier this way, instead of paying a bit more to have a reliable solution. But hey, that's why there is such a thing called oraganizational maturity. Some cusomers and vendors get it, some don't.</p>

Collapse -

Sticking to your standards in the face of pushy vendors

by IdRatherBdiving In reply to Sticking to your standard ...

<p>We have many vendors that also require such ridiculous things as this.  One of the best is not wanting any virus protection on the machines becasue it may interfere with the vendors poorly written application, but they want you to put it on you network and guarantee it remain virus free.</p>

Back to After Hours Forum
65 total posts (Page 5 of 7)   Prev   03 | 04 | 05 | 06 | 07   Next

Related Discussions

Related Forums