A Library for IT Folks

ITIL is the Information Technology Infrastructure Library, a collection of documents describing IT best practices. ITIL was first developed in the late 1980s by the UK's Central Computer and Telecommunications Agency The ITIL philosophy is centered around a Service Strategy, which supports the areas of Service Design, Service Transition, and Service Operation; these processes are continually being improved (image from SUBnet.192):

ITIL has had 3 versions: v1, encompassing 30 books on various aspects of the IT process; v2, with 8 books; and v3, simplified to 5 books. ITIL is in the process of transitioning from version 2 to version 3, though both versions are still widely used by IT companies.

One of the aspects included in v2 -- specifically, the Service Support category of v2 -- is the Service Desk. It is pretty much what it sounds like: the company's tech support function. There are three descriptors for a Service Desk, each with differing levels of actual tech support provided.

• A Call Center is essentially a relay station for taking customer problems and forwarding them to the appropriate support department. While Call Center employees can solve some basic problems, most of the time they just get information and forward customers to another department that is better equipped to solve their problem.
• A Help Desk solves problems as quickly as possible. They provide support, but don't handle maintenance-type activities.
• A Service Desk handles tech support, maintenance, change requests, etc. Pretty much, if it has to do with their system, they handle it.

The Service Desk activity is categorized under the Service Operation banner in ITIL v3.

There are many software solutions for ITIL, spanning programs that cover the entire breadth of ITIL activities and programs that focus on one aspect of it. One more focused product is ServiceDesk Plus, "a web-based help desk software that...[manages] all your communications from a single point". It takes requests via different methods (phone, email, etc.), applies the necessary rules and/or conditions, and routes them to a technician for fulfillment. (Workflow image from ManageEngine.)

There are also several companies that provide ITIL consulting services. One such company is Enterprise Consulting Services, "a boutique consulting firm specializing in IT Service Management consulting, implementation and outsourcing, using the ITIL framework". ECS focuses on translating ITIL best practices into concrete implementations based on a company's needs.

One such client with whom they have worked is Iberdrola USA (formerly Energy East), a multi-state energy corporation. ECS provided training for employees, allowing them to become certified in ITIL. They also redesigned the support and security systems and upgraded their computers (Windows XP, Office 2003, and McAfee security -- in related news, Iberdrola probably just had svchost.exe disappear for a while). These moves resulted in annual savings for Iberdrola of about $1.4 million. That's what applying optimized practices will do for a company.

Quote of the Day:
The Tech Support Glossary:
ID-Ten-T error: the user has just done something inane, like use their DVD drive tray as a cupholder. (Also known as ID10T.)

PEBKAC error: there is nothing wrong with the computer; the problem exists between keyboard and chair.

Layer 8: in the OSI Model, the user layer above the application. (See also ID-Ten-T.)

(from Wikipedia)

Buildings, Triangles, and Big Balls of Mud

Christopher Alexander had a problem. Actually, all architects had a problem. There they were, being hired to design buildings, and their clients understood the buildings more than they did. The problem, essentially, was translation. How could an architect take what the client described and turn it into what the client wanted?

Simple, Alexander said. Clients want basic variations of a set of buildings. We need a language that describes basic stuff (that's a technical term) in our problem domain, building buildings, that is simple enough to be understood and used by our clients: a pattern language. "The elements of this language are entities called [design] patterns. Each pattern describes a problem that occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice."

Design patterns are not one-size-fits-all, cookie-cutter solutions. Instead, they are skeletons, templates, general descriptions of how one might solve a type of problem. For example, it has been determined that people like rooms where natural light comes in from two directions. That's a design pattern. Notice that the pattern does not say, "Put one 16"x30" window on the north wall, and one 24"x30" window on the west wall." It says, "The optimal room has natural light coming in from two directions."

Alexander came up with this concept in 1977. To this day, it has had a mixed reception in architecture. In 1987, however, Kent Beck and Ward Cunningham got the idea of applying the principles of design patterns to software. The "Gang of Four" (Gamma, Helm, Johnson, and Vlissides) popularized that usage in their 1994 book, Design Patterns: Elements of Reusable Object-Oriented Software (Wikipedia).

Good design patterns, in computer science, are classified in four categories: creational patterns, structural patterns, behavioral patterns, and concurrency patterns. Creational patterns define how an object is created. Structural patterns define relationships between entities. Behavioral patterns define methods and patterns of communication between entities. Concurrency patterns define how to deal with multiple threads in a program. Wikipedia has some good descriptions of software patterns.

An example of a good design pattern is the creational pattern abstract factory. An example of an abstract pattern is the AbstractCollection class in Java. This class provides the basic skeleton required to create a collection of objects. It has methods to add items to the collection, remove items from the collection, get the size of the collection, etc. Individual methods in the class can be overridden in subclasses to provide functionality specific to that implementation. Several classes implement AbstractCollection in a more specific way. ArrayList, by way of AbstractList, implements the methods so that they work with a resizable, sortable list of objects of a specified type. List implements them to work with a list of specifiable, but fixed, size.

To put it in simpler terms, an abstract factory pattern is like the definition of a triangle. The abstract definition of a triangle is that it is a shape with three sides. The abstract methods would be implemented in the classes RightTriangle, ObtuseTriangle, and AcuteTriangle, which would place restrictions on the angles of the triangle, as shown below (Wikipedia).


Bad design patterns are called antipatterns. While good patterns have dry names like "abstract factory", "composite", and "chain of responsibility", antipatterns have been given such monikers as "spaghetti code", "God class", and (my favorite) "big ball of mud". The big ball of mud starts out as a relatively simple piece of software, then through the addition of bits of throwaway code, quick fixes, and piecemeal growth, becomes an unwieldy, mutant program that would take a good deal more time and money to fix than it would have taken to properly maintain it in the first place. By leveraging all of my considerable artistic talent, I leave you with this insightful look into big balls of mud: