Saturday 27 March 2010
Our highland friends
A recipient of the Five Pineapples award over at the Taproot burrow, emailed in this picture of our Scottish cousins. Nice picture but did you buy us any Johnnie Walker in duty free?
Wednesday 24 March 2010
Saturday 20 March 2010
Banned kulula.com advert
Need to run Sepp Blatter just called...
Friday 19 March 2010
Sunday 14 March 2010
Saturday 13 March 2010
Blogs and stuff that rock - Lifetime achievement award
Following the announcement of the retirement of well-known Cisco blogger Brad Reese from Network World, the meerkats had a meeting during Boeing drinks at 10:00am and decided to award him the Blogs and stuff that rock: Lifetime Achievement Award. The award was celebrated with an extra round of marula beer.Brad is the first recipient of The Lifetime Achievement Award also known as the Roadkill Rinkhals award. Roadkill Rinkhals refers to the favourite meerkat pass-time of taunting passing Rinkhals' to chase them across the nearest road, only to be flattened by a passing Toyota.
On another note the meerkats denied that Brad's new business venture is setting up an ISP for the burrow using second hand Cisco kit.
The "best practice" Myths
"In theory, there is no difference between theory and practice. But, in practice, there is." Jan LA van de Snepscheut.One of the purposes of problem management is to provide a set of best practices that span all IT disciplines. Best practice is based on the idea that the best way to learn is from the experiences of others. The goal is to establish the maturity of these IT disciplines within the enterprise, and acknowledge that different disciplines may be at different levels of maturity. The nature of problem management can be termed extreme in that all disciples are measured and evaluated. In many cases and studies, problem management is placed at the bottom of the service management pile. I have the alternative view that it should have its rightful place at the top of the heap.
Most executives in an enterprise consider IT spending to be wasteful and out of control. IT spending grew rapidly until the technology bust of 2001 and again repeated in 2008. The result of these busts was that in most enterprises, empowerment was given to the business unit to control spending, thereby disempowering IT.
The reality is that no modern enterprise can divorce itself from IT, and executives need to balance the reality of the cost of IT versus the automation benefits it provides.
The best way to reduce IT costing and contribute to higher service levels is to use best practices. These provide a high level of process discipline, simplification and standardization, and alignment with business goals. An enterprise will be successful if its processes are based on best practices and implemented with methods that are disciplined, repeatable and auditable.
The drivers for best practices are: globalization, technology, removal of boundaries, placing value on intellectual capital, and focusing on value as defined by the business unit user.
Goals
The goals of IT best practices are:
- Managing the demand for IT services
- Securing relationships with business units
- Analyzing where to invest IT funds
- Estimating the size of projects
- Managing project changes
- Rationalizing what services to offer to business units
- Deciding what information to put on a portfolio dashboard to measure performance
The benefits of IT best practices are: quality, consistency, efficiency and flexibility.
The characteristics of a best practice are:
- Proven coding practices (patterns), designs, reference architectures, or business methodologies
- Well documented practices that are widely used by peer groups
- Continually evolving practices
The promise and benefits of using best practices have led many enterprises to identify and establish them. In their haste to gain this advantage, some enterprises misuse the concept of best practice. Realizing the power of a “best practice” moniker, a bad practice is incorrectly promoted as a “best practice”. This is used to bludgeon team members into following or using it. Some common myths of best practices are:
- IWorkThereforeIAm: The most common myth around best practices is that if there is a solution to a problem (especially if the problem has been difficult to solve), then this solution should qualify automatically for a best practice. Since this is usually the first solution to the problem, it generates enough euphoria among the small community affected by the problem to declare it a best practice. This is incorrect, as a solution has to first mature into a practice, and then further into a best practice.
- GuiltybyAssociation: A practice that uses other best practices does not automatically become a best practice. This myth is most prevalent in development, where best practices are defined as patterns. However, simply using a best practice in creating a new practice does not automatically qualify the new practice as a best practice. It may increase its chances of maturing and succeeding as a best practice, but patterns should not be aggregated indiscriminately. Often they achieve flexibility and variability by introducing additional levels of indirection, and that can complicate a system at the cost of performance.
- OpenStandards: The complexity of current e-business applications and systems requires a set of standards, common templates, and open environments to facilitate interoperability and flexibility. However, the fact that a practice uses open standards does not automatically make it a best practice. Team members using standards can still produce poor results.
The IT Maturity Model
Best practices assist the enterprise in improving the maturity of their IT systems. The implication is that IT in an enterprise builds maturity in a staged manner and does not undergo a radical transformation. The road to transformation requires the following principles to be embraced:
Best practices assist the enterprise in improving the maturity of their IT systems. The implication is that IT in an enterprise builds maturity in a staged manner and does not undergo a radical transformation. The road to transformation requires the following principles to be embraced:
- The long-term success of IT and improved value for the enterprise lies, to a very great extent, in IT’s ability to develop and sustain genuine relationships with business unit users.
- A view of the business unit IT customer that asserts that he or she is a valuable asset to be managed.
- Deciding that you want lifetime clients.
Gartner proposes the following IT maturity model:
- Chaotic - Ad-hoc, Undocumented, Unpredictable, Multiple help desks, Minimal IT operations, Business unit IT customer call notification, Tool leverage, Operational process engineering.
- Reactive - Best effort, Fight fires, Inventory, Initiate problem management process, Alert and event management, Monitor availability, Service and account management.
- Proactive - Monitor performance, Analyze trends, Set thresholds, Predict problems, Automation, Mature problem-, issue- and change-management process, Service and delivery process.
- Service - Define services, classes and pricing, Understand costs, Set quality goals, Guarantee SLAs, Monitor and report on services, Capacity planning, Business management, Profit.
- Value - IT and business metric linkage, IT improves business process, Real-time infrastructure, Business planning.
Thursday 11 March 2010
No broken windows
The relevance of the broken windows theory, first coined by Kelling and Wilson, to determining the underlying, root causes for major incidents in Information Technology (IT) is important. The broken windows theory describes the purported phenomenon whereby an abandoned building with no broken windows is mostly left undisturbed, but as soon as one window is broken, it acts as an open invitation to passers-by that it's open-season for rock-throwing.I have previously written about the techie curse. The fundamental techie curse is the reluctance to create documentation. My corollary to the broken windows theory as applied to IT is that more major incidents will happen to infrastructure where the processes, resources (vendors and technicians), products and tools are not fully documented.
Infrastructure that is not fully documented leads to tardy habits, which become bad processes that ultimately results in an increased rate of major incidents.
One of the major benefits a Configuration Management Database (CMDB) provides is the ability to provide and act as a repository for documenting infrastructure. This basic feature is the most important and it is time that IT professionals stop taking short cuts and start documenting! NO BROKEN WINDOWS!
The need for end to end change management
In the mid nineties I lived in Pretoria, in Hill Street, close to Loftus. I worked for Madge Networks as a Technical Account Manager and was fighting a rearguard action with Token-ring against Ethernet.
The Madge offices in South Africa were located in Rivonia. My trip would start early mornings before 7 as with heavy traffic the journey might take up to an hour. (the situation is now worse with even longer travel times)
One morning I was driving in to work and was listening to a CD and switched to Radio 702 just before 7. The headline news was about major delays at Johannesburg International Airport (now called OR Tambo) that was caused by a computer problem. I had worked at the airport for SAA installing a large number of switches and CAUs and was very familiar with the environment. I was coming up to the Buccleuch interchange and decided to go left to the airport instead of right to the office. Maybe there was something I could do to help.
A few moments later my mobile rang. It was the SAA IT manager who had heard the same news broadcast and asked me to meet him at the airport. He was as much in the dark about the situation as what I was. The two of use arrived at much the same time at the departure hall. The crowd and queues were extremely long. We walked to the front counters to determine from the staff what was the issue. Many of the passengers threatened us as the assumed we were hopping the queue and told us to get back into the line. Having struggled our way to the front we duly learned from the controller that there was no connectivity to the mainframe. Since my companion has walked over from the headquarters building, he confirmed it was not a general mainframe outage as the systems were all accessible and working from that building.
I had my laptop with me. An IBM Butterfly (BTW: best laptop I have ever owned!) I attached my laptop using my Smart token-ring adapter to the network and loaded a good old DOS application called RingManager. I looked in dismay as RingManager proceeded to tell me that there were well over 500 nodes connected onto the single ring (maximum should not be more than 200) that I had attached to and the locked up solid and froze. Being a typical techie and not believing it the first time I proceeded to do it a second time with the same results. I conferred with the SAA guys and told them that it was my suspicion that someone had looped the rings at the airport together. There was only one location where this was possible and that was the main fibre patching room. We proceeded to the patch room and at first inspection all was in order. However, when we started checking the patches they were totally incorrect with the diagram pasted on the wall next to the cabinet.
The security guards confirmed that a cable installer had signed in and worked in the room at 1am in the morning connecting a new voice switch. We deduced that the patch cables were in his way, so he unpatched them all. Put in his new fibre cables and then randomly patched the cables back. We started patching the fibres back to their correct position using the diagram on the wall. The technician who pasted the diagram on the wall was a hero. Many times I have encountered no diagrams present in patch rooms. When it comes to resolving issues they are crucial.
The airport network slowly started coming online as we worked through the patches and the departures were able to move from manual boarding to full ticket check-in and boarding.
After the crisis was over we had some strong cups of coffee. I asked the SAA guys was there was no escalation as the operators had a network management alert console. No one had the answer, so we decided to go over to the operations area to work out the reason. The operator was sitting in his office blissfully unaware of the crisis. The network management console had a total of 11 million unacknowledged alerts. When questioned as to why there was no escalation the guy said that no-one had phoned him. He only does anything when someone phones him and since no-one phoned there wasn't an issue. I never knew what happened to the poor bloke but there were some pretty pissed off people ready to strangle him.
I have repeated seen change management done in isolation and not in an end to end fashion. In some companies each business unit does there own thing and does not consult with any other stakeholders. Change management will fail and cause outages unless there is a transparent end to end process where all stakeholders and their vendors within an organization have visibility to the activities.
To often the changes are done in a fashion of need to know. I need to know and will tell you about it if I think you need to know. Murphy usually conspires to bring two changes together at the most inappropriate moment to cause absolute havoc.
Whenever I sit delayed in some airport, I often have the urge to go and ask the airport personnel who messed up the change management process, because that is the most probable reason.
Saturday 06 March 2010
Subscribe to:
Posts (Atom)
