Robert Pearson's reply to the Storage SIG questions

Q: Should the Storage SIG have a Storage Roadmap?

A: Definitely. Without a roadmap it is difficult to get where you think you want to go and to tell where you have been.

I have used, and recommend highly, the Flashmap Systems IT Roadmap as a "go by". Jeff Tash first delivered the IT Roadmap, now known as the FlashAtlas, publicly in the 1990's. I first saw it in Computerworld in 1993. I had been struggling to come up with something similar. The IT Roadmap was better than anything I could ever do so I adopted it as my IT standard. It is even better now that Jeff has incorporated some of the ideas I have been working on. Great Minds?

Q: What should be in the Storage Roadmap?

A: The Flashmap Systems IT Roadmap as a guide and then:

• Individual IT shop tweaks
  • Some of my personal favorite IT tweaks are:
    • Information on Demand (IoD)
    • End-to-End Information on Demand (E2EIoD)
    • Information Lifecycle Management (ILM) and its five phases of:
      1. Assess
      2. Strategy
      3. Design
      4. Implement
      5. Manage

I'm particularly fond of Manageware, which falls in the ILM Manage phase. ILM is a defined set of processes and tools to keep the Information "heartbeat" strong and the "finger on the pulse" accurate. Manageware monitors the "heartbeat" and keeps a "finger on the pulse" of the Information under Management. Manageware will give you the information needed to make good ILM decisions. Manageware needs to be 80%, or more, COTS (Commercial Off The Shelf) products. I always wanted to be like the Maytag repairman. I believe there are many more "value-add", and certainly more interesting, things to do in an IT shop than put out endless brush fires. I don't see any "fun" in always being behind the eight ball, stuck in the trenches, dealing with never-ending "no-win" pressure, and in a constant fight for sanity and survival in the fast lane. These brush fires add no value to the quality of life in the long run. This stress does build a funny kind of confidence that you "may be" bullet-proff and invisible except at raise and reward time. Brush fire panics are all short run solutions and are part of the job. The good part of the job is minimizing them. This lets you spend more time on the important stuff, the "fun" stuff.

Manageware is way behind the Technology. I am a big fan of Information Architecture (IA) and in particular Visual Information Architecture (VIA). My ideal of the perfect Manageware is something like Dennis Chao's "Doom as a tool for system administration". Later efforts, Doom: The Aftermath and the near Production versions Doom SysAdmin Tool and psDoom (together at the bottom of the page) never caught on and took off because the "dot com" Boom! Bomb! Bust!, as we all know.

Now the most exciting thing is Java P2P. Here is a write-up from the JavaMUG homepage. Peer-to-peer (P2P) is not obvious for most things other than file sharing. In this tutorial, you will first be introduced to a few JXTA (pronounced jux-ta) concepts, and shown simple but powerful examples of how to use the Java JXTA API. Next, you will learn how to write applications with newly invented software patterns for P2P. These patterns (Well–Known ID, One–to–One, aka Chat, Many–to–Many, aka Chat Room, Monitor, Software Update, File Chunking, Confirming Identity, Peer Presence, aka who's online, Socket Addressing, RMI over JXTA, and P2P HTTP) will help traditional client–server developers add very powerful P2P features to their software.

We did P2P for some of the Java patterns at NASA, and Amoco, using RPC calls. The NASA code was developed on personal time as a "learning" exercise using Borland Turbo C. It compiled great on all the *nix NASA platforms with minor modifications, which says a lot for Borland products. We had a peer-to-peer (P2P) network of 55+ DEC Ultrix 3100 and 5100, Masscomp, SGI (IRIX), and Sun (SunOS, early Solaris) workstations. Amoco was all Sun and SGI client-server but we used the same "C" code approach to gather information for the Electronic Inventory.

The "sleepy, or quiet, lagoon" days of Client/Server are gone for most IT people. Even in the SOHO and SMB. For sure in the Enterprise shops. The order of the day is 24x7xforever,forever,forever! We could once size our daily incremental backups as 20-30% of total Storage. This made it easy to set the time needed for the backup window. Not any more! Web sites are incredible in their Storage activity! 80-100% of Storage is active every day. This means "Full" backups every day. Unheard of!

Cell phone companies are more demanding in a different way. If a cell phone can't connect there is an immediate, noticeable loss of revenue. This is more of a server problem than Storage. Storage has to be available to capture the connection and transaction Information after the connection is made. The most important Storage use comes with running the billing program against the "stored" minutes Content. Wait until they get the Content profiled and in the database. You will then see some fancy rate setting based on "value" determined from your profile.