You probably vaguely remember the study on the effect of lighting on productivity at a Western Electric plant in Hawthorne, Illinois (1924, Elton Mayo). Productivity went up for the group where illumination was increased. Interestingly, productivity also went up in the control group where the lighting was left as is.
Mayo concluded that productivity simply increased because attention to the workers increased. Illumination was not a factor.
Now, over 80 years later, isn’t it simply amazing to learn how stunning productivity gains can now be attributed to implementing the right technology? Is it possible that information technology has negated the Hawthorne Effect?
Perhaps.
Others suggest that the hyperbole surrounding most information technology projects is best understood in the context of the law of self-interest.
Perhaps they’re right, also.
Ivan Hoffman argues we’ve been conditioned to believe that acting in our own self-interest is bad. However, claiming outrageous productivity gains only serves to damage the credibility of those involved. Unfortunately, this practice is rampant in trade press articles hyping technology.
If even a small fraction of the hype can be believed, it does make you wonder if the Hawthorne Effect still exists.
General, Lessons Learned
Microsoft made changes to its browser to avoid infringing on Eolas patent, essentially forcing users to click to use ActiveX controls. Maybe you noticed something different with the 11 April Microsoft updates applied to your computer?Â
Microsoft argued (and lost) that Eola’s patent actually should not have been awarded since examples exist that pre-date their claims. All of this seems to support Brad Feld’s arguments to abolish software patents.
Real reform seems unlikely. Microsoft has to pay $521 million and change their browser. Their lesson learned is likely the notion that they need more software patents in their portfolio to be able to invalidate others claims.
General, Lessons Learned
One of Dave Taylor’s best posts on business blogging can’t be found on his main blog. Explode your Business via Blogging, describing a teleseminar he is offering, contains some real nuggets including:
- Why conventional wisdom (i.e. more traffic = sales) is wrong
- Why you should think in terms of findability
- Why content matters more than parlour tricks
Businesses are already spending a significant amount of time and effort to improve their online positions. However, most are flying blind and have no idea how their online activities affect their offline results. Too much is written about secrets to drive traffic and not enough about visitor conversion.
Are you flying blind? Do you know which analytics matter? Do you have a strategy to convert visitors into customers?
I’m looking forward to Dave’s insight on some of these topics.
Assessments, General, Lessons Learned
After participating in a business continuity session around the pandemic flu scenario (a la Avian Flu), it became clear that many organizations will be left wondering what happened to their careful planning.
At the root of most failed plans are the wrong assumptions that were never challenged. Let’s explore one of those elements.
Most companies will conclude that one way to address a flu pandemic is to deploy their workforce at home. This means they’ll have VPN (virtual private network) access. What are the wrong assumptions here?
- Assuming the Internet won’t fail in some way. After all, the Internet is made up of circuits and switches and routers maintained by people. If the pandemic sidelines large portions of workforce around the world, there will be failures at various points leading to congestion. There could even be localized outages if the pandemic affects your area more heavily than another area.
- Assuming that your VPN solution will work unattended. This is pretty common. Most people assume something is simple, but it turns out quite complicated. Who will fix your VPN in your moment of crisis if your own technical staff has been adversely affected?
- Assuming someone else is responsible. Whose job is it to test the VPN? Did your IT staff assume the employee tested it? Did the employee assume it would work? Did management assume that everything that needs to be done can be done over VPN?
Those are just a few examples. What are the lessons learned?
- Have someone external to your company review your business continuity plan
- Test your plan
- Document the responsibilities
- Have a playbook that outlines your response
General, Lessons Learned
In my Illusions of Information Security white paper, I make the point that if you wanted to protect something really important (like your data), you’d want the perimeter fence (the firewall) AND the alarm system (the Intrusion Detection System). You’ve run out of excuses for failing to act.
StillSecure announced a freeware IDS. We’ll be tossing it in our test lab to determine the suitability for our customers.
The move by StillSecure should serve to increase the visibility of this Colorado-based company while raising the awareness of the importance of information security.
It’s an uphill battle. I still believe the adage that most organizations spend more on their coffee service than their information security. Does that sound like your company?
If you don’t even have a firewall, don’t let that stop you from dowloading their IDS. Wake up and smell the intrusions.
Anti-Threat, Assessments, Lessons Learned, Networks
There’s a useful methodology called root cause analysis (or shoot the innocents from the perspective of most IT staffs) that is supposed to determine three things regarding an event of interest (typically an outage):
1. What actually happened?
2. How did it happen?
3. Why did it happen?
Lots of things get in the way of root cause analysis including a lack of full disclosure by the IT staff involved in the event and failures by executive management to demand excellence from their IT Management and staff including consequences for what I term “self-inflicted gunshot wounds”.
The truly tragic outcome is that even after the “Lessons Learned” documents and e-mails are generated, they rarely result in “Lessons Remembered”.
I was reminded of this after participating in a Root Cause Analysis of a major systems failure for a customer several months ago that took days to bring back online. You would think this would leave an indelible mark or perhaps even an ugly scar as a reminder in the organization? (Hint: You’d be wrong.)
Fixing it the second time took only a few minutes. However, it was still a preventable outage that will happen again because organizations lack the management discipline to convert a lesson learned into a lesson remembered.
Assessments, General, Lessons Learned
Since my post on Downtime Unaccepted, several of you have e-mailed me with your “funny” (or painfull) stories on your own self-inflicted downtime blunders.
Let’s tackle some low hanging fruit first. Subsequent posts will address increasingly complex issues.
Here are some simple things you can do to save some future embarrassment:
- Replace those “inexpensive” ethernet switches (they’re already costing you money)
Reason? Those $79 switches you bought don’t have enough backplane capacity and are often oversubscribed (meaning dropped packets under load) when your servers need to do sustained data transfers.
- Stop making your own ethernet cables
These cables have a higher failure rate and will produce troubling intermittent symptoms that you’re likely blaming on something else. Everyone assumes their cables are good (bad assumption).
- Distribute your DNS (Domain Name Service)
Simply make sure that DNS queries for your domain can be answered from more than one machine and along more than one path. If you host your own DNS, make sure you have a secondary DNS server that does not depend on your primary Internet connection.
- Understand and use RAID (redundant array of independent disks) technology
If you’re an executive and you’ve lost data…chances are that your IT staff either isn’t using RAID or hasn’t deployed it properly. No excuses anymore for losing data. If this keeps happening, audit your IT practices.
- Why isn’t your e-mail system either distributed or clustered or both?
E-mail is a critical service for most organizations. Make sure your system doesn’t have a single point of failure.
- Why haven’t you tested restoring from your backups? (You are backing up your data, right?)
A rhetorical question, but don’t assume restore tests are being done. Backup is one of those custodial tasks that most IT staff detest. Make sure your organization has regularly scheduled restore tests.
Tags: downtime redundancy
Assessments, DataCenters, General, Lessons Learned, Networks
