Still going strong after all of these years....

My mate Duncan emailed me this pic of a Madge CAU in a data centre in ZA. WOW!

Memories of a childhood - the vinyl of sixto rodriguez

Electronic tombstones

My wife used to say that often she would read about what I was thinking via a blog entry instead of a personal conversation. Some things are easier to write about than to speak about. Something else my wife used to say is that I never took enough pictures of her and the children.

I have neglected this spot (there are many broken links to fix) because I changed jobs and on 17th August 2011 my wife passed away. Her wish was to be scattered to the four corners of the earth. That is a difficult place to find on a map, so we selected three places in the Pilansberg and a koppie at the Norscot Manor reserve.

However, her facebook account remains as an electronic tombstone. I realized that when we go, all of that is going to remain is not our scattered ashes but our electronic presence. I started posting pictures of our sons and me on facebook on a regular basis. Somehow it makes me feel that she can see them and smile down at us. I hope there are enough pictures for her to see! The other day I had a burden. I had been letting go the emotional ashes that the presence of her worldly possessions had created. The last thing I let go were her shoes. I was present when she went and the shoes were on a chair in the room outside under my jacket. During the past year, no-one had asked me what happened in those moments and what were her last words. I logged onto facebook and posted it on her electronic tombstone, her facebook account. It was the same release as when the shoes left, a burden I did not have to carry myself. BTW: the words were: "I don't know."

PS: Babe, I hope you are still reading...

G.8032

Remembering...

Speaking at the Nil event in ZA

Seeking to eliminate the "techie curse"

I wrote about the "techie curse" some time ago. Techies don't create documentation and most environments are a SOP (Standard Operating Procedures) desert. In every job in which I have started, no-one has ever given me a SOP of the services being provided. I would have to "sink or swim." Most techie managers who were treated in this manner, reinforce the behaviour by treating their subordinates in a similar manner. In reality they even go further to ridicule those who create documentation as bureaucratic. By this they imply that it is a waste of time but often the underlying reason is to be able to be a hero, as when the sh1t hits the fan, they are the only ones able to resolve it, as all the knowledge is in their heads and not on paper for anyone else to attempt to resolve. I have even been told that it stops their ability to be "business flexible." What a load of codswallop! Imagine if a new hire was given a SOP of the service they are responsible for delivering on day one of their tenure. Alas, most techies spend the first three weeks of their job being unproductive.

I have been meaning to update the orginal SOP template ever since it became a reference in Wikipedia's entry for callcentres for a short time period. Here is the updated SOP template!

Documentation - the techie curse

Techies are cursed by the reluctance to create documentation. This is so bad when a member of the techie sect actually starts becoming diligent and creates some documentation he or she is ridiculed. My opinion is that technologists have evolved into a mindset where the expectation is to be spoon fed and mollycoddled. In the good old days, it was common practice to tell people to RTFM. This was the "old school" way I learnt Computer Science. Nowadays this is deemed rude. "RTFM or Google it are two inappropriate responses to a question. If you don't know the answer or don't wish to help, please say nothing instead of brushing off someones question. Politely showing someone how you searched or obtained the answer to a question is acceptable, even encouraged. If you wish to remind a user to use search tools or other resources when they have asked a question you feel is basic or common, please be very polite. Any replies for help that contain language disrespectful towards the user asking the question are unacceptable and will not be tolerated." (from the Forum Policies and Expectations - Ubuntu Forums). If these wimps are not expected to do some of their own reading and research there is no chance in hell that they will create any documentation. It is time to be a traffic cop.

Being involved in problem management I have gathered some stats about the major incidents that have crossed my desk. The service that causes the most major incidents is data networks. This is no surprise as in this neck of the Kalahari the former telecommunications monopoly that dominates the market is not renowned for service excellence. This is followed closely by messaging and then voice. Again no surprises as the email and voice systems are by far the most used IT systems.

The statistic that is of more interest in this blog is the second one. The cause of most major incidents is around mis-configurations. This is often because techies do not configure a system or solution correctly. Further analysis usually indicates that the techies never bothered to document it in the first place and the reason for the incorrect configuration was that they were flying blind. Next is component failure. Again this is traced back to not knowing what systems are where and what the warranty and maintenance schedules happened to be! Yes, you guessed right! Again insufficient documentation. The next category are the vendors (carriers and service providers). I will deal with vendor management in another blog post.

The documents that should exist and are never created are Standard Operating Procedures, also known as SOPs. The term is used to describe a best practice approach to executing tasks related to hardware and software maintenance, as well as incident and change management. SOPs are created to provide specific documentation for various processes, usually highly-technical processes. Businesses are finding that they lack this kind of documentation; either there has been inadequate process definitions altogether, or they have no documentation in place. When reviewing the existing documentation, it is important to know where a particular SOP may be needed, or that the SOP available is detailed enough or not current.

The reasons for a SOP are:

• To provide techies with all the environmental and operational information necessary to perform a job properly.
• To ensure that IT operations are performed consistently to maintain quality control of people, processes, partners and products.
• To ensure that processes continue uninterrupted and are completed on a prescribed schedule.
• To ensure that no failures occur in the live environment that could result in major incidents.
• To ensure that approved procedures are followed in compliance with corporate due diligence and compliance to regulations.
• To serve as a training document for teaching newbies about IT processes.
• To serve as a checklist for the techie's superior when job performance is being evaluated.
• To serve as a checklist for auditors and they become an important part of compliance due diligence.
• To serve as an historical record of the how, why and when of steps in an existing process so there is no hearsay when reviewing a process when a process has changed. As people move from job to job within and between companies, unwritten knowledge and skills disappear from the workplace. Properly maintained written SOPs can chronicle the best knowledge that can serve new workers when older ones move on.
• To serve as an explanation of steps in a process so they can be reviewed in major incident analysis.

The SOP should take the following format:

• Title and description (include reference numbers)
• Definitions
• Scope
• What Vital business functions are being serviced?
• Lessons learned
• Equipment, hardware and software lists
• Daily availability checklists
• Diagrams
• Full system configuration
• Testing plans
• Schedule of administrative and maintenance tasks
• Costs and charge back models
• Risk mitigation actions
• Continuity plans including disaster recovery and methods for restoring data
• Escalations

The following are guidelines that apply. Use pictures, diagrams, tables, and bulleted lists for quick reference. Often screen shots are great. Keep the steps involved to a maximum of ten. If the steps are more than this amount, break it up into logical sub procedures. Review the effectiveness of SOPs after a few weeks and make necessary changes if in-the-field practice suggests that descriptions should be improved. A SOP template is available here.

Some of the important Infrastructure SOPs required are:

• SOP for major incidents and problem management
• SOP for handling security incidents
• SOP for messaging
• SOP for directory services
• SOP for WAN quality of service
• SOP for video conferencing
• SOP for corporate voice, least cost routing and branch to branch links
• SOP for call centre
• SOP for voice recording
• SOP for SAN and storage
• SOP for backup and restore
• SOP for virtual servers
• SOP for patch management
• SOP for server images
• SOP for hosting
• SOP for access management
• SOP for hardware management
• SOP for anti-virus
• SOP for network management
• SOP for cabling
• SOP for licensing and asset management

and my final opinion on the subject is, "READ THE ~!@#$%^&*()_ SOP."

NB: The SOP template has been updated!!! Read about it here.

Radwin video

At least you guys could have cleaned up the cables at 0:57!

Love of my life

Africa's fibre routes

African Undersea Cables -- A History

View more presentations from Steve Song

The final landing...