Making Informed Technological Decisions

 
In my early system engineering years with IBM, my primary account was a large insurance company in central Wisconsin that was a leading-edge user of CICS [1] and one of the higher volume online systems in the world. Their advanced, heavily-used, real-time and transaction-based business applications stressed IBM’s largest S/370 processors to their limits. Transaction growth was robust, making the achievement of acceptable performance a moving target, which was addressed by regular upgrades to the fastest machines IBM was regularly enhancing.
 
Online systems offered massive opportunities in productivity, customer service and the bottom line to businesses like my client, but they were an emerging technology very early in the growth cycle. They contained shortcomings in performance, usability, code quality and functionality, and while the product development lab produced new releases that addressed all of these issues on an ongoing basis, this in turn created its own problems. Upgrading CICS was problematic; due to development and consequent testing deficiencies, an upgrade could induce code defects that led to malfunctions or outages.
 
So my client was faced with an intimidating conundrum: The existing CICS release was relatively stable, but a new, total product rewrite contained desperately-needed function and significant performance improvements. Granted, the product had been re-architected with extensive change, new function, new installation techniques and more, which meant uncertain quality. It was a seemingly unresolvable tradeoff. Still, this client was a leading CICS pioneer, an ideal testbed that would stretch the new CICS to its limits, so IBM Hursley suggested a solution that benefited both parties.
 

A Strong Support System

 
IBM had begun offering product introduction programs like First Customer Ship (FCP) and Early Support Program (ESP) on a semi-formal basis. These programs established a close working relationship between the customer, the IBM Support Center (who were specialists at dealing with code or other product defects), the IBM CICS Development Lab in Hursley, England and the local IBM team (mostly me). IBM provided enhanced support for problem resolution, product enhancements, prioritized service, onsite education and various other enhanced support.
 
My client was delighted and went through an extensive vetting process with management. With my help, the company put together a cost/benefit analysis along with other analyses and approval processes. I was the go-between on all aspects of the project, and it was one of the most powerful learning and management experiences of my life. We encountered some problems during installation, but the impact was greatly minimized from what it could have been. It was the first product installation program this insurer and I participated in, and the benefits more than paid for the cost of extra staff members, travel and product resolution effort.
 
The decision to participate in an ESP wasn’t a one-time thing—it was a decision to be a leading-edge, technology-stretching consumer of CICS on an ongoing basis, and a decision that would affect the organization for years to come. It was a long-term decision this client knew came with a cost, but it impacted the entire company much more than a handful of day-to-day technical decisions. The entire management team believed the advantages outweighed the costs, and that proved to be the case.
 

Defining Technical and Technological Decisions

 
I believe there are two significant types of technology-related decision making:
 

1. Technical decisions. Technical decisions are tactical, and require extensive knowledge of IT hardware, software, networks, operations, procedures, applications, and more. To make technical decisions, a manager needs a limited working knowledge of problem resolution, performance management, project planning, system character, backup/recovery, component interrelationships and interaction, priority of business processes, and other unique organizational characteristics. Lower management positions usually make most technical decisions.

2. Technological decisions. Technological decisions are strategic, and require an in-depth knowledge of company charter, business processes, strategic objectives, financial structure and working business plans. IT facets include thorough knowledge of IT operations, industry trends and projections, IT budget, capacity planning, cost/benefit analysis, product introduction programs, the IT strategic plan and contracts, user agreements, the UI, and especially leadership. Upper-level management makes most technological decisions.

 

Identifying Alternatives 

 
When making a technological decision, it’s important to identify all alternatives. For example, my client had several other options, including:
 

• Upgrading hardware for faster processors
• Increasing and training staff to more effectively tune systems, identify performance bottlenecks, and create solutions to improve throughput
• Rewriting programs—especially heavily-used ones—to perform more efficiently
• Eliminating some functions, perform utilities less frequently and take other steps to reduce workload

 
However, none of these options were palatable to the customer. Each one was too costly or had unacceptable consequences. After exploring these alternatives, my client was able to opt for an ESP as its best technological decision.
 

Technological Decisions Vary in Content and Nature 

 
My client’s decision was a manageability-driven technological decision involving how an IT operation upgrades software, but the reasoning behind technological decisions can vary greatly. Here are some examples:
 

• Providing financial viability. Price and performance, total and incremental cost, and amount and speed of payback are all universal components of any technological decision.
• Differentiating technologies that provide a similar function. Perhaps the greatest example of this is both the divergence of hardware and convergence of software that characterizes personal computers and cell phones. Both platforms provide several common functions, but each has certain strengths over the other.
• Examining how security techniques, architecture and administration influence technologies. This is a ubiquitous element of technological decisions.
• Analyzing how technologies interact with and influence each other. This can result in almost endless variations and implementations of manipulating or controlling said technologies. Artificial intelligence (AI) is an example of this.
• Maximizing manageability of technology. This is a key variable in almost any technological decision, and is often the determining factor.

 
These are just a few examples, but the list goes on, as other factors are prolific and vary with technology, usage, objectives, and more.
 

Criteria for Making Technological Decisions

 
While criteria for making technological decisions can vary greatly, there are some common standards and principles that need to be analyzed:
 

• Identify how business characteristics and processes can accommodate the technology
• Determine audience/customer set
• Determine which requirements and technology needs to adhere to
• Conduct thorough research of the technology’s scientific underpinnings and related considerations
• Analyze the success or failure probability. What are the chances of success, and what is the likely payback?
• Ask if the technological opportunity is consistent with both the IT and corporate strategic plans
• Calculate the ROI
• Estimate the difficulty of implementing the technology and integrating it with existing IT and business systems

 

Money Matters

 
Ultimately, finances are the final determining factor. Will moving to a different technology or making fundamental changes to a current technology strategy improve the organization’s financial position? Will the technology cut costs or increase revenues? Regardless of how appealing a technology is, how many advantages a new technology promises and how much potential a given technology appears to offer, the bottom line is the bottom line. Even if a technology saves lives, it can’t be viable if it drives an enterprise into bankruptcy. Running an organization and producing products or services costs money, and money needs to be earned for organizations to survive, so profit is a necessary component for growth.
 

A Win-win Situation

 
Both my client and IBM benefited greatly from ESPs; my client had IBM development’s ear far beyond most customers with elevated product installation and problem resolution support. IBM development gained great insight into customer requirements and experience, allowing it to produce a superior product that still dominates the market. Customer installations everywhere benefited from less disruption and online systems as CICS became more productive, usable and available. And as for me? It opened the door to authoring the original CICS Performance Bulletin that led to my becoming a founding author of the CICS Performance Guide that’s still a vital part of the CICS library.
 

---