Fixing my fence, the ITIL way

I just finished ITIL Foundations training, and wanted to detail how I fixed a fence problem this morning in ITIL Terms:

1. Event--> Dogs barking outside.
2. Alert --> Dogs shouldn't be barking this early .
3. Incident Created with service desk --> Dogs shouldn't be barking this early.
4. Incident Troubleshooting Dog is outside the fence, Fence SLA violated ('5 Nines' Dog Containment)
5. Incident Priority Critical.
6. Transferred to Problem Management.
7. Problem Management identifies a work around --> Put the the dog in the house.
8. Problem Management communicate the work around to service desk to communicate to customer.
9. Dog is put in the house.
10. Since the Fence is a VBF and the SLA is being violated Problem Management convenes the ECAB
11. Problem Management identifies the problem and suggests a solution  --> Fix the section of the fence that dog breached.
12. The ECAB Approves the change and transfers it the Technical Operations.
13. Technical Operations fixes the problem.
14. The Change is noted in the CMDB (My Wife).
15. The Service Desk is notified, they notify the customer.
16. The dog is let back out.
17. During Post incident review by CSI, it's noted that fence inspection should happen more often.

XML, Just Say No.

I don't like XML.  While its goal was to be be both machine readable and human readable, it does a poor job at both.  Its way to verbose. There are better alternatives like JSON  or just plain old text.

Professional Development

I've been working in IT for more than 20 Years. I never intended to do the job I do. I graduated College in 1989 with Business Degree, with every intent of going into some type of sales, then business management. In fact, at that time there were very few degrees in IT outside of engineering. There were  fledgling MIS (Management Information Systems) programs, but what they were teaching never appealed to me.  I ended up in IT because of circumstances outside my control  and a knack for being able to figure out computers and programs.

But one thing that is obviously missing is formal education. For a long time, I figured that formal knowledge really wasn't that important ,as long as I could do my job. Recently, I've concluded that my knowledge is more spotty then I had imagined, And I have begun to to try to fill in the blanks. To be able to talk with my peers, I need not only to know how to do the job, but also the terminology.  Frequently, I have discovered, there are tools and methods that I wasn't aware of, that could have helped along the way, had I actually gone to a class on the subject sooner. I've worked hard recently on professional development,  because I need to fill in the holes.

Don't skimp on professional development, especially if you are a product of early days of IT. You may have a lot of experience, but there are most certainly holes in your knowledge.

The end of paper as we know it.

Back in the '90's there was lots of talk about "going paperless", a utopian vision of a world where we no longer used paper, notepads were passe, and file cabinets were for suckas. That never happened. We still have notepads, laser printers, and lots of file cabinets. But the role of paper has changed since the digital age came upon us.

Since the 13th century paper as been used for record keeping and communication.  Paper has some very unique properties  made it successful for 700 years. It's light, cheap, easy to add data to (writing), data can be retrieved easily by anyone without special equipment (reading), and its durable. These properties made it the go-to method  for record keeping and communication. Its biggest disadvantage was that if you want to see the data, you have to go to it or have it brought to you.  Reports were written on paper, if you needed to collect metrics, someone reviewed the paper, made calculations and wrote it on a new piece of paper. Paper was so important to the successful operation of society, that the governments created agencies to transport paper under protection of the law (postal service), and other laws to protect content (copyrights).

Enter the late 20th and Early 21st century. The ability of computers to process and disseminate information have relegated data that used to be stored on paper to databases and file systems. Information  that used to be disseminated on paper is now transmitted digitally. 50 years ago business records like invoices and customers data were stored in file cabinets, now they are stored in databases. Paper is not just another method to display content.

While this revolution has allowed us to make great advances in almost every field of human endeavor, it has also led to new challenges. Age old institutions are searching for relevance (the postal service); hundreds of years of legal precedents no longer are relevant (copyright). Most importantly, since access to data is governed by technology, as that technology progresses we run the risk of loosing information forever.

We are moving into a new age, we need to start thinking about how we will manage data for ourselves and future generations.

It's The Data, Stupid

I saw a tweet a while back that went something like "I can't believe people still use data-centric design".  It's been festering in my brain and has inspired this mini-rant:

I'd like to remind everyone, that the reason we write, software,  mobile apps, and even have the Internet is so we can provide information (useful data) to users. Social media isn't about the interface its about the data, the interface just improves access. E-commerce is about moving item data to the customer, and order data to the vendor. This blog is about  the information I provide, not the layout.  If we loose site of the data, all we end up with is eye candy. 

Modes of Thinking

Linear Thinkers. Use if A then B logic.  They handle structured and known problems quickly an well. 

Spacial Thinkers. Look at the entire issue, analyze causes and options, to come up with the 'best' solution. They solve structured problems a bit slower, but can solve complex problems quicker than others. 

Chaotic Thinkers. Get distracted by some element of the issue and solve a different problem.  They are able to solve problems that have not been defined yet. 

Examples

A linear thinker walks into a dark room and flips on the light switch. 

A spacial thinker walks into a dark room and observes that it's dark, this may mean that the ligh bulb blew out, the power is out, or the light switch is off.   She takes a metal inventory of light bulbs and flashlights.  Then she flips on the light switch. 

A chaotic thinker walks into a dark room , it  reminds  him of his youth when he used to develop photographs ( old school) in a darkroom. He turns around gets his camera and takes some photos of local landscapes.    He later hangs the photos on a blank wall in the currently dark room. 

What kind of thinker are you?  

6 Reasons to use a SQL Database

There is a lot of hype about NoSQL databases. These databases provide solutions to problems that traditional SQL RDBMS's can't, and they are 'new and shiny'. While these new tools are drawing a lot of attention, I'd like to review the case for the traditional SQL RDBMS.

1. They abstract data the way that we would store them without  a database. A ledger is like a table, an invoice is  a one-to-many relationship. They are easy to understand and apply to real life situations.
   
2. They are structured. Since each row in a table has the same structure, you only have to write one 'piece' of code to deal with it. Less code means faster development times, and less bugs.
   
3. Static Data Types. Each column has a static data type (Or should anyway) so programs don't have to worry about data validation when retrieving data. This means less code too.
   
4. SQL. They all run a dialect of SQL which cuts down on the programming learning curve.
   
5. They are reliable. ACID transaction handling means that there is less chance of data corruption. And we all know corruption is bad.
   
6. They are mature. Oracle and DB2 have been around for over 30 years, SQL Server for more than 20, PosgressSQL more than 15. Most of the bugs are out of the system, and there is a lot of documentation available. 

Don't jump into the NoSQL pool, unless you need too. SQL RDBMS's still provide the an excellent solution to most data storage and retrieval issues.