| By Joe Winchester | Article Rating: |
|
| February 9, 2006 09:00 AM EST | Reads: |
16,898 |
One way in which technology is adopted is when an existing process is automated and made more efficient, cheaper, or reliable. Another is when a technique or innovation is applied to an existing process to drastically alter the way it occurs. The disadvantage of the latter is that it requires the idea being sold to someone who has to change to adopt it, and thereby carries a risk of failure. Applying a technology to merely streamline an existing process is a simpler to adopt as the implementation merely involves oiling an existing solution.
Given the keystone that communication occupies in our lives, you would think that it would be an exemplary case of technology implementation. Ironically though this isn't what has occurred; instead it is one of the most recalcitrant disciplines.
An example is the telephone. When it was first rolled out, it was used by secretaries to read memos sent by company executives. The secretaries would write down the message and read it to the recipient's secretary who'd deliver and collect a reply before phoning it back. It was a streamlining of the previous process, which had involved the message being carried to a telegraph agent who would encode it in Morse and send it as a telegram. We take it for granted now that a phone message is a way of conducting a two-way conversation, but for the first telephones it took a long while before the message's author and recipient would talk to each other directly and cut out the additional latency and inefficiency introduced by having couriers in-between.
While with smug hindsight we can mock the early adoption of the telephone, I fear that generations to come will do likewise with our current usage of e-mail. It originates from a scenario where mail would be used to send memos within and letters between organizations. Once computers were added to the equation, instead of hand writing memos and letters, people were using word processors and sending printed output. With networking, the obvious implementation was to shortcut the process and simply send the mail electronically to the recipient. What has occurred though is a world where e-mail has almost become the means and the end itself. A colleague came by my desk a few days ago to ask if I had received the e-mail he had sent me, and then went back to his cubicle to await my reply. Our corporate phone system e-mails you when someone leaves a phone message. In some situations I have received e-mails from people asking for a convenient time to telephone. Leaving aside the politics, flame, and other idiosyncrasies that come to the fore with e-mail, it is surely a poor implementation of technology as a means to solving the general problem of increasing communication effectiveness.
There are other examples of where the path of least resistance has been used, when a technology rollout has been influenced heavily by the legacy it replaces, rather than the promise it offers. Numeric keypads are a case in point, where telephones lay out 123 on the top row, and computers 123 on the bottom. The computer arrangement descends from calculators and adding machines, so why is the telephone different? It stems from an evolution that began with rotary phones with dials. The dial is turned clockwise to a fixed position and released, clicking on its return to generate pulses for each number; one for a 1, nine for a 9 and ten for a zero. The arrangement of the number was such that one was at the top, nine toward the bottom, and counter-clockwise next to it the zero. Nine and zero were infrequently used in phone numbers so they were the least easy to dial. When a numeric keypad for a phone was required, the engineers felt that, instead of just adopting the calculator key layout, keeping 1 at the top and 9 adjacent to 0 was easier for current phone dial users to migrate to. It was a decision based on following the path of least resistance to the adoption of technology, yet it has now created paradoxes such as the layout of soft keys on a telephony application being different from the physical layout of the keys on the computer's numeric keypad or the layout on a calculator application. It is a bizarre and seemingly insoluble legacy that stems from the initial solution being too closely aligned with the existing implementation rather than the new technology.
Apart from being interesting, these anecdotes provide lessons of failure where the common thread is that a technology is applied to an existing solution, rather than to the existing problem. When IT was first launched on corporations, buzzwords such as "business process re-engineering" were thrown about as jargon to embody the fact that computers would change the way the company worked, as well as merely improve its existing transactions. Instead, however, IT is now viewed as a cost center that has to purchase copies of operating systems and office applications, using whatever change remains to play with business innovation. It's akin to asking the sales department to pay a company's electric bills and catering costs before trying to generate new accounts, yet it passes off every day in boardrooms where IT managers have to fight daily for every dollar of their budget.
Whatever the future holds for IT, it has to come by looking at an existing scenario, and not merely attempting to tackle the old solution with a newer and faster technology, but peeling back the layers and working out what the original root problem was of the solution that's currently in place. The Internet has launched huge corporations that adopted technology as their means of doing point business rather than a bolt on, and the future is boundless as new problems are tackled with increasing bandwidth, mobility, and content type. I just hope that for each solution we aren't stuck with upside-down keyboards and implementations that hinder rather than aid communication, and that we all remember that the best solutions come from analyzing problems, not patching existing solutions.
Published February 9, 2006 Reads 16,898
Copyright © 2006 SYS-CON Media, Inc. — All Rights Reserved.
Syndicated stories and blog feeds, all rights reserved by the author.
More Stories By Joe Winchester
Joe Winchester, Editor-in-Chief of Java Developer's Journal, was formerly JDJ's longtime Desktop Technologies Editor and is a software developer working on development tools for IBM in Hursley, UK.
![]() |
SYS-CON Belgium News Desk 02/09/06 09:50:13 AM EST | |||
One way in which technology is adopted is when an existing process is automated and made more efficient, cheaper, or reliable. Another is when a technique or innovation is applied to an existing process to drastically alter the way it occurs. The disadvantage of the latter is that it requires the idea being sold to someone who has to change to adopt it, and thereby carries a risk of failure. Applying a technology to merely streamline an existing process is a simpler to adopt as the implementation merely involves oiling an existing solution. |
||||
- Kindle 2 vs Nook
- Why IBM’s Server Chief Got Busted
- Is Cloud Computing Like Teenage Sex?
- Industry Experts Discuss the State of Cloud Computing
- Performance Tuning Essentials for Java
- Confessions of a Ulitzer Addict
- Tactical Cloud Computing Panel at 1st Annual GovIT Expo
- It's the Java vs. C++ Shootout Revisited!
- Cloud Computing Can Revitalize Your Career as Software Developer
- IBM Could "Reinvent" Java: Mills
- Oracle & Cloud Computing: Exclusive Q&A with SVP Richard Sarwal
- A Brief History of Cloud Computing
- Kindle 2 vs Nook
- Cloud CEOs, CTOs & SVPs to Speak at 4th International Cloud Computing Expo
- Why IBM’s Server Chief Got Busted
- Is Cloud Computing Like Teenage Sex?
- Industry Experts Discuss the State of Cloud Computing
- Performance Tuning Essentials for Java
- The Difference Between Web Hosting and Cloud Computing
- Cloud Computing Expo: Exclusive Q&A with Yahoo! SVP Cloud Computing
- Ajax in RichFaces 3.3, JSF 2 and RichFaces 4
- Confessions of a Ulitzer Addict
- My Thoughts on Ulitzer
- Tactical Cloud Computing Panel at 1st Annual GovIT Expo
- A Cup of AJAX? Nay, Just Regular Java Please
- Java Developer's Journal Exclusive: 2006 "JDJ Editors' Choice" Awards
- The i-Technology Right Stuff
- JavaServer Faces (JSF) vs Struts
- Rich Internet Applications with Adobe Flex 2 and Java
- Java vs C++ "Shootout" Revisited
- Bean-Managed Persistence Using a Proxy List
- Reporting Made Easy with JasperReports and Hibernate
- Creating a Pet Store Application with JavaServer Faces, Spring, and Hibernate
- What's New in Eclipse?
- Why Do 'Cool Kids' Choose Ruby or PHP to Build Websites Instead of Java?
- i-Technology Predictions for 2007: Where's It All Headed?










































