The technology is moving much, much faster than the knowledge base to make the best use of it, or have the best understanding of it.

... you may find that an equally large group of people are roaming the halls with torches and pitch forks trying to find the person responsible for another learning curve being thrown at them.

The systems contracting industry is in an interesting state. I only just noticed this a short time ago, typical of the view from the trenches, you only get a look at what's going on across the entire field of operations when you get handed the aerial photos. My aerial reconnaissance photo-op came from being involved in the NSCA teleconference discussion group on the changes in the National Fire Code, and the efforts to entrench a measurable intelligibility requirement in the voice evacuation system section of the Code. This was an interesting and productive fast-track process, headed by William Keezer of Bose Corp., to deliver a proposed Code change by the November 15 deadline, but the process and outcome will be a story for others to tell. What the process made me realize is that there is convergence and then there is convergence. The technology might be converging at a closing velocity approaching the speed of light, but the actual bulk of each of the industries are travelling at much lower velocities.

We are seeing the evolution of the systems contracting industry in which the technology convergence is producing market Darwinism, and is forcing manufacturers, contractors and consultants to either adapt or die. Everything is becoming some kind of a digital signal, and new hardware and software products appear like killer aliens in some Level 10 Nintendo® game. As an industry we are having to respond to these changes at an ever faster rate. And much like a video game, it is easier for a video game player's fingers to respond at the needed speed than it is for a tennis player who has to throw their whole body at shot fired behind them. It occurred to me that even though the technology is changing quickly, the balance of the bodies of the various systems contracting industries are not moving that fast.

Each of the typical markets in the systems contracting industry have a body of history behind them. The sound contracting business goes back to the cinema sound industry in the 30's, and the radio broadcast world before that (which grew out of the telephone world). The video industry has a history rooted in the world of television and broadcast, again into the mid 40's. The telephone industry is rooted in the telegraph industry, and goes waaaaay back. The world of data systems probably can be tied to the telegraph world of 0's and 1's but we'll say that it only became a contender in the last two decades. The alarm and security industry probably dates to the start of the Second World War, but I must admit to a lack of knowledge regarding those roots. Behind this high speed technology convergence is a substantial inertia of the body of each industry, and that body does not change direction as fast as the fingers of technology.

The example that brought this to light for me is the need for intelligibility in a voice evacuation system. From the sound system designer's point of view, there would be no value at all in designing a speech delivery system that could not deliver speech intelligibility (or you would call it something else). Yet in dealing with developing a code requirement that required a critical speech delivery system to have a minimum standard for intelligibility, the wording of the code had to be carefully considered so that this requirement would be accepted. This wasn't a technical issue as much as one of serving the tennis ball in such a way that an entire body of an industry was able to return the serve.

This is one example of the more substantial inertia that industry knowledge has in responding to convergence. As fast as the flying fingers of technology are in all these industries, the body of knowledge of an industry is much slower to respond to the convergence acceleration. And the regulatory level is only one aspect of that. I realized that it exists at most levels for the clients, equipment manufacturers, contractors and consultants. The technology is moving much, much faster than the knowledge base to make the best use of it, or have the best understanding of it.

From the owner or end user's point of view, all technology is moving at a hectic pace. Computer hardware and software are obsolete from the moment they are installed, and the learning curve for each new release, and each new feature set keeps people in a constant state of Beginner status. Network sys-admins are busy guys these days, just keeping up with the changes, and fixing computer problems created by perpetual neophyte users. This inertia manifests itself in the design process, where senior management people are usually the ones that are involved in defining the design requirements of new facilities. They may be the ones who are still using WordPerfect 5.1 for DOS because that was the last wordprocessor that they mastered the command set on, and they just don't want to be bothered to use a newer piece of software with all the extra bells and whistles on it. Alternately, they may be the ones who still use WP5.1 because it is adequately productive and does not have the extra features that bring productivity to halt.

The convergence of technology and the provision of vastly extended features and performance is both a curse and a blessing, depending upon the users. This applies to everything from a piece of software, a VCR, a boardroom presentation system or a building management system. In every situation we find that the client has both interest groups, and in designing a facility to suit the needs of the techno-literate, you may find that an equally large group of people are roaming the halls with torches and pitch forks trying to find the person responsible for another learning curve being thrown at them. The techno-literate design is likely the one that will see the long term use after people get over the learning curve anxiety (assuming it has not been made obsolete by some garage size software/hardware developer that has done the same thing in a cheap add-on for a desktop PC). Sometimes the users dig in their heels and just won't deal with the learning curve that their management has tossed their way, and it becomes a matter of principle, a software equivalent of the hammers of the Luddites.

The product and system manufacturer's are faced with a similar situation, although they may well be likened to the ones being responsible for pouring oil on the learning curve. New products and new software are available by the minute it seems, downloadable off the Web. New hardware products that use software are becoming increasingly common (ubiquitous computing - a way to maximize the negative impact of bad software design on everyone, everywhere). Inertia is apparent here in the lead time of documentation and testing of software. The developers are incorporating all sorts of features and ideas into products, some of which form a vital part of a design, and it can be very distressing to find that the one feature you need is not actually implemented in the current release of software, but will be soon, by version 2.053c for sure. Features that are there are often not documented, and documented features often have undocumented bugs that turn them into creature features. In a software driven system, it can often take months to find and squash the undocumented bugs. In control systems, there is always the risk of one manufacturer changing their software driver, and not informing others that may care, thus creating a new round of troubleshooting by the contractor, under the baleful eye of the consultant and the litigation-happy eye of the client. The last thing a contractor or consultant wants to hear when they talk to a manufacturer is "Gee, no one else has ever complained about that problem before." As cool as it is to be pushing the envelope, one always hopes that the envelope size and shape was documented before they pushed the boundary a bit further.

You could easily be out by a factor of four in programming time estimates with just a couple of sizable bugs.

A head-on collision on the learning curve S bends is never a pretty sight.

The rush to stay ahead in the product market almost always means that documentation and troubleshooting of "leading edge products" is something to be done just after the final, or next to final, version is released. This keeps the client, contractor and consultant out on the edge with the product developer, and the edge isn't all that big to start with, without the added challenge of having to share it with a large group of people.

From the contractor's point of view, the challenge is to try to make money while speeding through the learning curve "S bends." The convergence of technology means that new hardware (and often the software that goes with it) from other industries keeps showing up in system specifications. If you don't know what it is that you don't know, it can be very difficult to predict the amount of time it may take to get a system working once it is connected together. And the problem is that there is no one who can tell you what you don't know, because often the people you ask at a manufacturer will not know of the bug or glitch that will drag a project across the profit line into the red. Often that glitch will be a joint venture between two manufacturers, existing at the interface of two devices that should talk to each other, but for one reason or another, will not or cannot. The "Caplets" and the "Montaques" in Romeo and Juliet have nothing on systems integration for the magnitude of family feuds. The old joke about the contracting side of the industry was that a bid was a guess to two decimal places. Well not only is that still true, but the error bars are now much broader. You could easily be out by a factor of four in programming time estimates with just a couple of sizable bugs.

The knowledge needed to converge all this technology isn't growing at a steady state rate either, the acceleration into the learning curves is increasing. Every time a contractor masters some programming tool or device, there is a new improved version that may or may not be backwards compatible. If you can't import all of your previous knowledge base into the new system, that experience is lost, and is of minimal value (although it may give you valuable experience in selecting vendors). This is like starting over from a standing start for each run through the pylons of the learning curve. It is hard to get really practised at this run if someone changes the layout of the pylons for every run, and it is only through practice that enough experience puts you into the profitable picture. Training time is time that you can't be earning money, and with only one lifetime per installer/programmer it can be a challenge to keep them profitable and up-to-date at the same time.

From the consulting point of view, the challenge is to develop designs that are cost effective, functional and long lived. That's getting harder as the technology changes so fast that you may have to revise the design once or twice through the a one year design development process, and that may have implications for the other design disciplines. Design fees are tight for architects and the other consultants, so the last thing anyone wants to see is a significant change in hardware or approach just to save the client money, if it will cost the design team a stack of time to incorporate. Minor changes in technology, or basic advances in cost-effectiveness are welcome of course, that gives the client more bang for the buck. Often these advances have hidden traps that aren't apparent in the pre-production units, but become a huge problem in the production models. Then there are problems where early documentation is just simply wrong and does not reflect the reality of the unit. This can be something minor like a missing control feature, where there may be a work around elsewhere, or it can be something really important like the wrong lens information so a video projector is located in the wrong place at the design stage, and it isn't apparent till the box is opened on site. The recurring theme of danger is always related to the situations where marketing leads the engineering department in documentation. A head-on collision on the learning curve S bends is never a pretty sight.

As the consultant, we always try to look out for the client's best interest while covering our own backsides. You always hope that you can trust the information that you use to cover your rear flank, so it always comes as a bit of a disappointment when you're hit by friendly fire. Because products are being introduced so quickly, the documentation is often sketchy, especially at the early stage that a product might be selected for a project. A good design should be able to be fairly independent of a reliance on any particular product, but there are those times when a design does hinge on particular feature that is only available in one device, and when that is the case, the consultant needs some assurance that the information they are working with is accurate. That is increasingly difficult to get at an early enough stage to be helpful.

The other issues of concern for consultants are the situations that I described for manufacturers and contractors. How much of a project will be given over to the learning curve by both of them. We often find ourselves pushing the limits of the hardware, using equipment for new applications and asking questions of manufacturers that they have never had asked before. This often means that a substantial amount of design time can be consumed by trying things for the first time, because no one else has tried it and told anyone else about it. Where this time isn't recoverable on a single project, you hope to be able to make use of that information on subsequent projects, but often that information becomes obsolete before it can be used again. Experience quickly becomes the fossil record of money lost on projects through product or process development.

Convergence is bringing all of the branches of the systems contracting industry together at high speed into the learning curves of each other's industries. Don't expect to get through this without some damage to the bodywork.