Scaling Standards

What should you do about IT standards if you're a Fortune 500 company?

• How many distinct IT products does your enterprise own?
  
• How many different product categories do all those distinct products fit into?

One of the main reasons for setting up IT standards is to direct people so they will choose the right products within each of the various product categories.

Establishing IT standards would be almost trivial if there weren't too many product categories to standardize. Granted, decisions would still need to be made, tradeoffs evaluated, political considerations assessed, etc.  But, as the number of categories grow, scaling does become a major issue.

Sticking one's head in the sand like an ostrich is not a viable scalability solution although it's a strategy often adopted by default. Companies complain they haven't the resources to conduct technology audits to inventory what they own, let alone to methodically select, communicate, and enforce standards.

Typically, an overworked IT team tries to turn the whole standards problem into a technological issue. What's needed, they insist, is a crawler that can automatically go off and perform an exhaustive inventory search by scouring every hardware platform, software library, and executable image. The shear enormity of this task will generally get IT off the hook with the excuse that the job is too big and there aren't enough resources either in terms of money to buy the right tools or people to perform the necessary work.

Of course, ignoring the problem does not make the pain go away. It merely sweeps the issue under the rug. The reason why nobody is screaming loudly is because the vast majority of business managers are totally clueless when it comes to knowing even how to think about IT. I swear heads would roll if businesspeople ever grasped the true magnitude of waste directly attributable to underutilization and redundancy of IT products. Maybe that's why IT doesn't want to address this.

In a recent posting to the "'XML Developers List'" , Roger Costello of Mitre mused about scaling. Below is an edited excerpt from his thread entitled "Understanding Scaling -- Critical for a Net-Centric Vision".

A SCALABLE MOVIE REVIEW TECHNOLOGY
Roger Ebert is a professional movie critic. He reviews movies. But, over the years, the number of movies has multiplied (independent movies, blockbuster movies, etc). It is no longer possible for Ebert to review them all.

Having a single professional movie critic review movies doesn't scale. Even a group of professional movie critics would be soon overloaded.

As well as not scaling, there is a problem with "truth". A movie review represents someone's interpretation, not facts. Everyone has their own opinions about a movie. Ebert may love the movie, but the rest of the world may hate it.

An alternative to using a professional movie critic to review movies is to have each movie producer generate a movie review. This approach scales well -- there is one movie reviewer for each movie. Of course, the problem with this approach is that the movie review will be heavily biased.

A third alternative is to record the comments of the movie-goers. This approach is highly scalable -- there are many reviewers for each movie. Further, since there are many reviewers there is a diversity of opinions, which give a variety of perspective to someone who is trying to decide whether to view a movie.

Thus, a scalable movie review "technology" is one that can grow as the number of movies to be reviewed increases.

A SCALABLE BOOK REVIEW TECHNOLOGY
The New York Times has a small group of book reviewers. This group reviews books and then publishes their reviews.

Just as with the problem of reviewing movies, using professional reviewers does not scale. The New York Times group is unable to review the exponentially growing number of new and old books.

An alternative approach is for each book author to elicit a review from a fellow author. This scales well, but suffers from bias.

A third alternative is to let the users (the readers) provide a review of the books. This scales well and provides for a diversity of opinions.

A scalable book review "technology" is one that can grow as the number of books to be reviewed increases.

There are three approaches to solving the scalability problem:

1. The high priests approach: Solve the problem using a small, centralized set of skilled professionals (the professionals may be geographically separate but functionally they are centralized)


2. The authors approach: Solve a problem using the authors.


3. The users approach: Solve the problem using the large body of distributed users.

For IT standards, the high priests approach is the only way to go. That's not to say there isn't tremendous benefit in allowing the user community to share feedback with both the high priests (i.e., the folks responsible for selecting standards) as well as their fellow users. Bottom line, there's always value in being able to communicate pertinent and timely information about IT products and IT standards. The real issue here is that IT products, especially those selected to be standards, are not like movies or books. Usually people only see a movie or read a book once. Moreover, on those occasions where somebody views a movie multiple times or re-reads a book over and over again, nothing really changes outside of losing the drama by knowing the ending of the story ahead of time. Such is not the case with software.

A novice's experience when first using a software product bears little resemblance to what transpires during a working session in the hands of an experienced user. It's not the software tool that changes -- it's the user who changes. Software usage, unlike movie-going or book-reading, involves a (sometimes steep) learning curve. Additionally, much of that learning curve is highly product-specific. Another key consideration involves support. There are high investment costs associated with selecting a product as an internal standard. Enterprises are required to commit time and money to develop a corps of product experts to support other users.

There is an initimate relationship between scaling and standards. The larger the number of users for a product chosen to be a standard, the greater the opportunity for cost amortization. Leverage also improves one's ability to negotiate better terms and conditions with software vendors.

In my opinion, CIOs should have a fiduciary responsibility to implement an effective IT standards program. The decision of what tools to standardize should never be left up to which vendor has the best salesperson. That's just like reviews written by authors. Similarly, while it's essential to carefully listen to the diverse opinions of the user community, there are way too many other factors beyond simple acquisition costs that need to be weighed before choosing a standard. That's why high priests are needed.