IT Applications of Sun Tzu’s Art of War: Laying Plans

Sun Tzu wrote:

26. Now the general who wins a battle makes many
calculations in his temple ere the battle is fought.
The general who loses a battle makes but few
calculations beforehand. Thus do many calculations
lead to victory, and few calculations to defeat:
how much more no calculation at all! It is by attention
to this point that I can foresee who is likely to win or lose.

Whether performing a routine upgrade or making a massive infrastructure change, if you haven’t performed the appropriate amount of planning you will most likely fail. The more planning you perform the more likely you are to succeed, and the more likely you will be prepared for any problems you encounter.

When you make plans your imagination must be fully engaged. Visualize the tasks ahead of you, re-arranging them in time and space, step forward and backward through the process. In this way, you will recognize potential pitfalls and devise methods to avoid or mitigate against them.

As the plans solidify in your mind, document them in written form (Wiki, text document, paper, anything). Use this document to engage the opinions and imaginations of people you trust. Their experience and alternate view of the situation will help bring to light anything you may have missed. Use this information to refine your plans, incorporating their advice.

For small projects, a miniature version of the above process will suffice. You may not even need to write anything down for a small enough project, but don’t neglect planning. When scaling up for larger projects, make sure to build in some checkpoints for re-assessing your plans and dealing with anything which may have cropped up. As projects grow in complexity it becomes more import to build in extra flexibility.

No matter what the time frame, make sure to take time for planning. You will not regret it.

IT Applications of Sun Tzu’s Art of War: Intro

Sun Tzu’s The Art of War is considered essential reading in many disciplines, but is not typically a requirement for students of Information Technology. I posit, however, that Sun Tzu’s teachings can be applied across many disciplines (I’ll even go as far as to claim any discipline), including IT.

With this series of posts, I intend to pull out key phrases from The Art of War and show how their principles can be applied within various IT disciplines. Not all of Sun Tzu’s wisdom can be directly applied, so I will not be performing a verse-by-verse analysis. There are, however, some sections or verses which should lend themselves to certain IT situations such as building and maintaining infrastructure, security strategies (lots there) and disaster recovery tactics. Here I intend to share with you my IT-focused ideas, as inspired by Sun Tzu.

For this series, I will read through this translation available from Project Gutenberg. All of my section/verse references will refer to that translation. Note that the translator’s notes are included in this version.

As an aside, I highly encourage everyone to explore Project Gutenburg’s catalog of works, as it is the largest repository of public domain e-texts that I know of, and has many classics available to download for free.

Next time: The core of Laying Plans.

The Wiki Way: Final Thoughts

Nothing I’ve presented in this series has been particularly earth-shattering. Wikis are just another Web-based tool out there for collecting and presenting information. Wikis are well-suited for some types of data, ill-suited for others, and there is a huge gray space in between.

Some examples of well-suited purposes are:

  • Encyclopedias.
  • Reference manuals.
  • Infrastructure guides or references.
  • Collaborative writing or other creative projects.

Some examples of ill-suited purposes are:

  • Large databases with somewhat static or homogeneous formatted data.
  • Content Management System (though it could work, just not ideal).
  • Web log or blog.

With proper research and some time taken to think about your community and purpose, you may find that a Wiki fits the bill. Just keep in mind that it will become an on-going project requiring a fair amount of care, feeding and community cultivation. Be ready to dedicate the necessary time to get it off the ground.

The Wiki Way: The double edges of the Wiki blade.

The main advantage of a Wiki is that it is a free-form database.

The main disadvantage of a Wiki is that it is a free-form database.

Being a free-form database, a Wiki allows contributors to format their pages and create their content almost without limit to form. This is both a good thing and a bad thing at the same time.

Without the constraints of a traditional forms-based database, contributors can build pages which better suit the data which they are trying to present — especially if that data differs slightly from the “standard” presentation. For example, in a structured database that catalogs computing devices in an environment you may have it set up to catalog various types of devices such as printers, workstations and laptops. What happens, however, when you get an influx of new devices which don’t fall under those categories or have additional properties which cannot be captured under one of the existing categories (let’s say, a bunch of new iPhones)? Well, you need to spend some development time to create a brand new form for the new devices which accounts for their special attributes (like an extra field for the iPhone’s GSM SIM card number). In a Wiki, there is no development effort required. Because the Wiki is not constrained with forms and fields, the person entering the data can simply note the relevant attributes directly and immediately.

On the flip side, though, you do need to enforce some semblance of structure or else it will eventually become impossible to locate any data at all — even with a good search function. Extending the example above, consider ten different contributors documenting new devices. If each one places their notes in a different section in the Wiki there will be ten different places to check if you want information on the various devices. Even a good search engine will lead users astray if the information is scattered across the Wiki like this.

The solution is to enforce firm, but flexible style guides for organizing information. The style guides should only go as far as to tell where various types of information should be located within the Wiki and what information should be captured, but they should not dictate exactly how it is presented (unless the volume of information requires it). Templates for new pages can assist with ensuring the rough “outline” of the Wiki stays consistent, but still allow individual contributors to be flexible with how they present data.

Community enforcement of the style guides becomes important, too. You should encourage contributors to edit each others’ work when they notice that something isn’t in quite the right place. If there are any disagreements on where something should be placed, be sure to resolve those as a community so you can all agree to a standard.

Think of the Wiki as a very large reference manual with many writers contributing (because it is, really). When writing papers for college, you typically had to conform to a style guide such as the AP Stylebook or one of the MLA Handbooks. Similarly, professional writers are often issued a style manual particular to the publications or projects to which they will be contributing. Your Wiki style guide does not need to be as formal as those, but it does need to exist in some form or another to prevent (or at least minimize) total chaos.

Next time: Final Thoughts.

The Wiki Way: Building your Wiki community.

So, you’ve picked out a Wiki platrform, successfully beta-tested it with a small group of users and have rolled out your final production version. Unless you are an exceptional individual possessing an encyclopedic volume of knowledge which you can dump into the Wiki, you will need other people to help you.

Building that community, however, could prove to be the most difficult task. In a business environment, it is important to get management to buy in to the idea of building the Wiki, but it is most important to build a base of content contributors. Without that content, the Wiki will have no value at all.

In my experience, I found that the “old guard” was a very large obstacle to implementing a Wiki as a documentation system. Most people, by nature, are averse to change. Change requires them to learn a new way of doing what they already know how to do the old way. At first, they won’t be proficient at the new way so they will be strongly tempted to revert back to the old way. And they did. For quite some time, I felt I was the sole contributor to our Wiki.

It took an influx of new employees before the Wiki really came into its own at our company. These new employees were able to see both the old ways and the Wiki way in action. From that experience they were able to experience the virtues of recording and sharing information through the Wiki. Most of them enthusiastically adopted the Wiki as their preferred method for documenting their activities.

Did that leave the “old guard” behind? Yes, it did. That is a challenge we need to deal with going forward. Hopefully, building a critical mass of usable documentation within the Wiki itself will eventually bring them around. Eventually, they will have little choice left as the old methods become impossible to maintain and others start asking, “Why isn’t this information in the Wiki?”

Next time: The double edges of the Wiki blade.

The Wiki Way: Which Wiki Works for You? lists nine Open Source Wiki implementations. Three of them are based on ASP and six on PHP. That is by no means a comprehensive list, but OpenSourceCMS hosts live, working demos of each Wiki listed. A more comprehensive list (but without the live demos) is available from Wikipedia (which runs on MediaWiki).

Another technique for identifying which Wiki is best for you, is to think about the goal of your Wiki and look for existing Wikis which have a similar goal. A good way to find existing Wikis is to perform a Google search with the term wiki.

Between the two techniques listed above, you should now have a very short list of candidates. Now is the time to download and install a beta test of each one on your own server. Load it up with data similar to what you that which you will put in your production Wiki. If you can, get some actual users to help with this process and get their input on which Wiki they like best.

After all that, you should have it narrowed down enough to pick your final candidate for a production Wiki. Get it installed and running on your production server, then work on getting that Critical Mass needed to make it a success.

Next time: Building your Wiki community.

The Wiki Way: The Wiki is here to stay!

There are many well-known examples of Wikis in action. There is, therefore, little argument against Wikis presenting a viable, living document to any size community.

A quick Google search with the simple query wiki returns over 400 Million results as of this writing. Many of the results on the first few pages are long-standing Wiki-based sites.

From gigantic Wikis such as WikiPedia to small personal Wikis, this technology has been adopted and adapted by a wide variety of users. Because most Wikis are (and are built on top of) Free, Open Source Software technologies, they are not going to fade away any time soon.

Next Post: Which Wiki Works for You?

The Wiki Way: Intro

Why use a Wiki to document your IT infrastructure (or your clients’)? What are some of the Good Things about using a Wiki, and how can you amplify them to your advantage? What are some of the Bad Things inherent to using a Wiki and how can you tame or control them?

With this series of posts, I hope to help answer a few of the above questions, perhaps bring up (and answer) a few more questions, and recount my personal experiences using a Wiki to document IT infrastructure for my employers and clients over the past five or so years.

Keeping with my site’s informal theme, I’m not going to draw up an outline or try to structure this. Instead, I intend to think about these questions and tie them to some personal experience which illustrates them.

While my personal experience lies in documenting IT infrastructure, I hope the ideas I present here are general enough that you can apply them to your own experience.

Next post: The Wiki is here to stay!

RANT: Pick Up Your Dog Poop, Please!

While working from home the other day, I observed from my office window a gentleman walking his small dog on the bicycle trail which runs behind our house. First, they walked by in one direction, then a few minutes later they came back through, obviously heading home.

The dog was at the end of one of those retractable leads and the lead was reeled all the way out, allowing the dog to go far off of the trail. Our yard is fenced, so the dog was in the middle of our neighbor’s yard, which has only an “invisible fence” for their own dog. Being a dog, it naturally determined that the middle of our neighbor’s yard was a good place to poop, and so he did. No big deal.

The gentleman waking the dog, however, did not have with him any means for picking up after his dog. So he left the poop in the middle of our neighbor’s back yard. What a jerk.

Many ideas ran through my head. I could have run out with my own scooper, picked up the poo myself and disposed of it. Or, I could have scooped it up, followed the rude man home and depsoted the poo on his yard. Maybe I should have opened my wiindow up and yelled at the man, “Hey! Pick up after your dog!” Perhaps I should have called the police. It is, after all, against the law in most cities (including ours) to not pick up after your dog — a law that is very difficult to enforce.

Instead, I let it slide and went about my business. Still (as evidenced by this post), it bothers me that some people with dogs just don’t get it. Owning and caring for an animal is a big responsibility. Being a good dog owner reqires picking up after it. At the very least, you should carry a plastic bag with you while you walk your dog. If you don’t like the idea of getting that close to your dog’s mess, pick up a proper scooping device to carry with you.

Your neighbors will thank you, I will thank you and you’ll feel good knowing you aren’t a total idiot and complete jerk.

Deja Vu?

OK, I’m at a restaurant, writing other posts for this blog. The table next to me when I sat down consisted of a family of 5, including Grandpa, Grandma, Mom, Dad and child.

I was at my table for awhile. That family finished their meal and left. Who was the next party to be sat at that very same table? A family of 5 including Grandpa, Grandma, Mom, Dad and child. Weird.

Here are the differences I observed between the two parties. The Grandpa and Grandma appeared to be older in the second party. The child sat between the parents in the first party, but in the second party, the child sat next to the wall. The child in the first party was male; in the second party the child was female.

Here are the similarities I observed between the two parties. The parents and children in each group were approximately the same ages. The entire party sat on the same sides of the table — the grandparents together on the far side (relative to my position) and the family of three on the closer side. The men sat on the outside part of the booth and the women on the side closest to the wall.

Chaos is strange.