Modern Network Architecture


March 31, 2013  6:39 PM

Building a Business relationship in the US

James Murray James Murray Profile: James Murray

I’m writing because I keep getting so much gmail spam from India.  I think that the Teams in India are looking up Seattle IT Consulting and sending spam email to my account, hoping that I’ll respond.  I’m happy to work with any company from anywhere in the world, but I’m not interested Continued »

March 31, 2013  6:35 PM

Gmail Spam from India

James Murray James Murray Profile: James Murray

First let me say I like working with Indians.  I’ve worked for 21 years as a Seattle IT Consultant working with teams all over the world.  Thinking about it, I’ve worked 95% of my time in the Seattle/Bellevue area yet I’ve worked with teams from Russia, The Philippines, Malaysia, China and multiple project teams from all over India.  Continued »


March 24, 2013  8:43 PM

Mapping a drive to a SharePoint 365 site

James Murray James Murray Profile: James Murray

SharePoint is not always the most intuitive system.  I setup my Seattle IT consulting clients with 365 SharePoint to replace file servers for small businesses.  The problem is that SharePoint is just really awkward.  What my client really wanted to do was see the SharePoint site like a drive letter on the network and interact with the drive like they would as if SharePoint was truly on the Continued »


March 24, 2013  2:39 PM

Multi-media a history and a Prediction

James Murray James Murray Profile: James Murray

Did your parents tell you not to get into art?  There’s no money in it?  Your family will starve?  That’s the way my parents thought.  I was discouraged from getting into art.  I think though that a lot of things have changed in the last 30 years.  As a Seattle IT Consultant I see art everywhere in our entertainment, the Continued »


March 17, 2013  1:30 PM

Simple Layout for a basic Config Document

James Murray James Murray Profile: James Murray

I began writing about why a configuration or settings document is important for network troubleshooting.  In this article, I’d like to try share a basic layout I use.  As I’m working with my Seattle IT Consulting clients, I am teaching them how to build this type of documentation.  This is just meant to be a base to get you started.  Continued »


March 17, 2013  1:02 PM

Writing a Settings or Configuration document…

James Murray James Murray Profile: James Murray

In other articles I’ve talked about how IT Experts can leap frog their careers by being able to document.  As a Seattle IT consultant, I find that the stereotype is true.  IT Experts don’t document.  They are under a great deal of stress to move Continued »


March 16, 2013  8:39 PM

How to write a topology Document

James Murray James Murray Profile: James Murray

When IT experts do write documentation, it’s usually a “How To…” document.  As a Seattle IT Consulting firm I need my experts to be able to troubleshoot the entire system, not install the system.  Topology documents describe the network in a Continued »


March 16, 2013  8:18 PM

How to write a Knowledge Base (KB) “How to…” Document

James Murray James Murray Profile: James Murray

As a Seattle IT Consultant, I review a lot of documentation.  Not because the clients I work with have documentation, but because I am training technicians to write their own documentation for the first time.  Documentation is one of my favorite subjects.  I think that a technician can increase their income faster because they are willing to do what most IT experts seem Continued »


March 16, 2013  7:57 PM

Documentation for IT Expert

James Murray James Murray Profile: James Murray

As a Seattle IT Consultant, I meet with IT departments on a regular basis.  When I ask, 95% of the time there is no documentation on the network.  I know I talk about this regularly but I’m working with fortune 500 client who is struggling with this very problem.  So I thought I’d talk about this subject again.  Recently, for example, Continued »


February 11, 2013  1:08 AM

Getting IT to document… The Knowledge Base

James Murray James Murray Profile: James Murray

Long before I became a Seattle IT Consultant, I started at the bottom.  About 21 years ago my mentor said to me,

IT guys never document.  If you want to leap frog ahead, practice documenting

I’ve worked on literally hundreds of networks.  Finding a network with strong documentation of their systems is like finding a needle in a haystack.  Even when you find someone who has “documented” their network, nobody trained them.  So the documentation is often outdated, poorly written and can’t be understood.  I’m writing this article to again sing the praises of documentation.  The right documentation with improve troubleshooting times, increase the productivity of the technology team and my biggest reason will get you on projects you couldn’t otherwise get on.

So documentation is such a misnomer.  When I come onto a sight with problems, the first thing I ask is,

Do you have documentation?”

Of course the answer is usually no… Even if the answer were yes, a better question to ask is probably, let me see your knowledge base.  We really can’t easily define the term documentation; it could anything from emails to topology maps.  A knowledge base is specifically designed to organize and manage documentation in a way that supports the IT vision.

Definition: A knowledge base is a special kind of database for knowledge management.  The knowledge base is an information repository that provides a means for information to be collected, organized, shared, searched and utilized. It can be either machine-readable or intended for human use. (See Wikipedia for more information.)

A knowledge base may be made up of the same articles written for multiple audiences.  A user “How To” document written for a user would be different than and install document written for the technician.   A KB articles documenting the troubleshooting process for known issues, is different than the documentation for root cause analysis of unknown issues.

Irrevo,  a local Seattle Knowledge Base expert I work with describe several areas most IT companies forget in their knowledge base design.

Quality Assurance – Many IT departments don’t take the time to write a standard.  When I first started my IT consulting career, I had a database to clean up.  When counting 1;s and 0’s little things like writing Suite, STE., # or whatever the writer felt like, was a serious issue.  When trying to filter account information based on something simple like Suite, the report was never accurate.  Creating and enforcing naming conventions for templates, checklist and even fields is a small part of the quality assurance process that pays long term dividends as the company grows and the potential for incidents increase.

Analytics – Creating the document is a good first step but many writers lose a good opportunity because they don’t understand how the document will be used.  For example:  Many ticketing databases leave the symptoms in the text fields of the tickets.  The problem with leaving symptoms in a text file is losing the ability to filter tickets for symptoms.  Creating a knowledge base means writing documentation systems that can be compared, measured and analyzed to measure trends and enhance management’s ability to make decisions.  With the symptom in the text file, the quality of the data depends on the technician’s writing skills and consistency in maintaining standard naming conventions.  Without this consistency, management can’t determine accurately, how often a specific symptom re-occurs.  Creating a drop down field with pre-determined symptoms for known issues changes the game completely for the analyst.

By learning about the components of a knowledge base a technician can jump start a waning career or leap frog ahead of other technicians that usually get the more interesting projects and opportunities.  Being the one person on the team that can created all the documents required means that every project manager will want that person on their team as well.  That’s how it started out for me.  When I became the manager, I needed technical writers.  I also needed my new technicians to quickly understand the network.  What better ways than having the new technician learn?  These new technicians became responsible for the network knowledge base.  They were able to quickly learn the knowledge base templates required to plan, management and measure network service.  In the process the technician also developed their own knowledge base , technical writing skills and quickly came up to speed sometimes jumping ahead of the more experienced technicians.


Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to: