DBMS, September1996

Adopting New Technologies

I love hot new technology. It's the way I make my living. However, I think that IT management should begin to look at new technology innovation with a jaded eye. Too often in this industry, organizations are ready to move headlong into the newest technology offering without first weighing the risks. Does this mean that you should avoid new technology like the plague and return to the days of Cobol and mainframe operating systems?

No. In fact, it is more important than ever for organizations to watch the emerging technologies in areas such as object orientation and components, data warehousing, the Internet and Intranets, infrastructure, and the like. The difference lies in the way organizations apply these innovations to their businesses. The typical scenario is all too familiar. A hot new product is announced, with all of the attributes you were hoping for: It is object-oriented, it is Internet-based, and it lets you easily design complex code. It has hooks into all the latest de facto standards. It supports a language that is a definite resume-builder. Some organizations will move quickly to purchase the software and get started before anyone else. Is this the smartest idea? Maybe or maybe not. But how do you know the answer? The best way is to perform an internal risk assessment before making any purchasing decisions. Following is a list of questions to help you get started:

• Is this technology unique? If so, which attributes of the technology will be helpful to your business?
• Does your organization have the skills to leverage this technology? What are the hidden reasons for its current popularity? Is it related to some unique aspect of the design, or does it offer a resume-enhancing skill that will make the developer more marketable?
• What will happen to the development schedule if the technology is not designed well or still needs maturation? Is there an alternative that can be substituted? Will problems place a business project at risk?
• What is the time frame for delivery of the project? Is it a short window? Is it an experimental opportunity?
• Does the new technology add dependencies? For example, if this technology is used as part of a client/server infrastructure, will a lot of code be written on top that is dependent on the infrastructure?
• How mature is the product? Is it already in the hands of other organizations? Is it still in beta test or even alpha test?
• Has the vendor told you 10 times how much he or she likes to partner with customers? This usually means that the product needs a lot more funding before it will be ready for prime time.
• How much time and money can your organization afford to invest if a product needs more attention than you thought?
• Is the potential benefit of advanced development with the product worth the risk? There are times when a new technology will have such profound ramifications for an organization that it is worth the time and money. Match the benefits of the technology against your corporate financial and business goals before you go forward. If they are out of sync, think again.

Once you have answered these questions, there may be other factors to consider. For example, some technologies may be too risky to use to implement the company's most strategic project. However, there may be an excellent reason to purchase a small implementation of the technology in order to train developers to use it. Pick a small pilot project that can serve as a "proof of concept" for this technology. You will learn a lot without putting your organization at risk. If it turns out that the technology is strategic and well-designed, you can do one of two things: You can redevelop the strategic project with the technology as a second stage, or you can select the next big project and leverage the technology. On the other hand, the technology you selected may not live up to your expectations. It may be too early in its development or may be too complex for your developers to use. If it is immature, you must determine whether you want to work closely with the technology supplier to change the product to make it work for your organization. If you are working with a young, emerging company, its developers may be willing to add functionality to meet some of your very specific future requirements. Even if the technology is a complete failure, your organization will learn some good lessons that can be applied to the next evaluation of emerging technology.

This has happened many times in the past. For example, look at what happened to several Fortune 500 companies that were among the first to embrace OSF's DCE technology in the mid-1980s. Some of these companies began working with the components of DCE before the coding was complete. Recognizing the benefit of a cross-platform distributed computing infrastructure, the companies' technology teams committed huge corporate resources to implementing strategic projects with DCE services at the core. But after many years of working with this early technology, these projects languished. The developers involved in these efforts had learned important lessons about the complexities of working with 400 low-level APIs. But they were expensive lessons, especially because the corporations were relying on the completion of key projects. Other corporations that better understood the risks of early-stage technology brought DCE in-house as a pilot project, but they did not anticipate that the technology could be initially used for production systems. These companies learned the same lessons as those trying to use DCE to deliver production systems. The difference was the level of risk to the organization.

The downside of placing too strict a business focus on technology is that you risk being too conservative - waiting until everything is perfect before trying a technology. This will not work any better than leveraging too much unproven technology. I was asked if organizations should wait to implement Internet application development tools until a set of standards is imposed. I believe it is more important to gain experience, even in the absence of standards, than to wait. For example, companies that have been experimenting with object-oriented programming for the past 10 years have developed much better programming techniques and styles, even if they have not used these languages for their production systems. In contrast, companies that have put off experimentation are less prepared for technology transitions.

The key is to strike a comfortable balance. You must focus first on the business benefits and the strategic requirements of your organization. You do not want to implement new, unproven technology in a strategic project unless the risk is very low. When the risk is high, do your homework. Determine what dependencies will be created between the new technology and custom coding on top of this code. If there is considerable value to be derived from an unproven technology, you may put your company at substantial and unnecessary risk. On the other hand, if the product you are bringing in is isolated, the risk may be worthwhile.

The bottom line is that common sense should reign supreme when it comes to new technology adoption. Emerging software is not yet the perfect science that we hope it will become someday. The risks are real and can cause companies to make hard choices about how and when to deploy what may be groundbreaking technology. Too often corporations leap to what seems promising before they look. Look first at the corporate business objectives, then match these objectives to the functionality and benefit of the actual product today. Even the most exciting and popular technology might put you at risk. Is the company stable? Is the technology mature enough to bet the business on? What will happen if it fails? If you can answer these questions and feel comfortable taking responsibility, then the coast is clear. Otherwise, wait, test, watch, and be patient.