[3B2-9] man2013020067.

3d 14/6/013 23:16 Page 67

Product Managing DB2’s Early

Development
Marilyn Bohl

In late 1979, IBM senior management charged its Santa Teresa Lab
with the task of building a new relational database management
system for its principal operating system, MVS. Marilyn Bohl, DB2’s
version 1 product manager, describes DB2’s early development
organization and product review as well as how it fit in IBM’s other
divisions and product releases.

Somebody said that it couldn’t be done,
But he with a chuckle replied
That ‘‘maybe it couldn’t,’’ but he would be one
Who wouldn’t say so till he’d tried . . .
—Edgar Guest
In late 1979, IBM senior management
charged IBM’s Santa Teresa Lab with the
task of building a new relational database
management system for its principal operat-
ing system, MVS. What a challenge! What
an opportunity! The good news was that we
benefitted from all the work that had been
done over the previous seven years in devel-
oping SQL and System R at the IBM San Jose
Research Laboratory.
I was assigned the responsibility of build-
ing a product development organization.
During the early development, a leadership
core of six managers and two senior techni-
cal leads reported directly to me. Reporting
to them were about 50 gifted, experienced,
dedicated professionals—some from the re-
lated relational database research projects,
some with IMS or CICS development ex-
perience, some with systems knowledge—
organized into functional teams. The num-
ber of people working in the DB2 group
continued to expand rapidly, when and as
appropriate, and I then became the DB2
product manager.
IMS had been shipped with source code
that many users modified heavily to fix
problems and add functions. This IBM prac-
tice for its applications and database and
communications software was popular with
its larger customers because it gave them
flexibility to customize the standard prod-
ucts. However, this made it difficult for
IBM to enhance and service these products,
and it slowed users from upgrading to new
releases. So, early on, we decided to change
the pattern and not to ship source code
with DB2. This was going to be a big cultural
shift for customers and would force them to
depend much more on IBM’s software sup-
port infrastructure.
Because it would now be even more im-
portant than before to ensure product qual-
ity, we adopted an even more rigorous
development process. We wrote detailed
product specifications, conducted formal
code reviews, and tested the software exten-
sively. We tracked problems through every
development phase and reviewed bug re-
ports daily. Bugs found later by customers
were going to be far more costly to fix
than bugs found during development. And
our extra efforts paid off; executives never
perceived that DB2 was ‘‘in trouble,’’ so
our development team enjoyed considerable
operational freedom. At one point, some se-
nior managers suggested moving the DB2
development organization to Tucson, Ari-
zona, to alleviate overcrowding in the San
Jose area. But because of our previous suc-
cess and continuing strong progress, we
were able to ignore this request and remain
at the Santa Teresa Lab.
IBM’s Field Engineering Division serviced
software as well as hardware products. Be-
cause we weren’t going to ship source code,
the Field Engineering personnel would need
in-depth knowledge of DB2 at general avail-
ability. Thus, we had to convince the divi-
sion’s management to assign people early to
DB2 even though they would see no signifi-
cant revenue from the product for several
years.

IEEE Annals of the History of Computing Published by the IEEE Computer Society 1058-6180/13/$31.00  2013 IEEE
c 67
 [3B2-9] man2013020067.3d 14/6/013 23:16 Page 68
Product Managing DB2’s Early Development
In late 1982, four customer field test sites
installed DB2 and provided us with invalu-
able feedback. Shortly thereafter, we began
‘‘selling’’ DB2 to the IBM sales force. Some
sales personnel with major IMS accounts
felt threatened by DB2, as did some IMS
developers in the lab. We were able to stress
that DB2 would complement IMS, however,
and presented case studies detailing users’
mainframe upgrades and additional disk
drive purchases. This quelled much of the in-
ternal concerns.
Still, the impact on IMS continued to be
an executive management issue, and it
delayed DB2’s general release. In late 1984
and early 1985, Norris van den Berg and
I met with IBM General Products Division
President J.E. Bertram monthly to review
DB2 progress. By this time, we had more
than 20 user sites worldwide that were gain-
ing experience with DB2. Nevertheless,
Bertram was keenly aware of IMS’s forth-
coming release 1.3, and because of his con-
cern that field personnel would be needed
to help users upgrade, he didn’t want DB2’s
68 IEEE Annals of the History of Computing
general release to complicate matters. How-
ever, in a memo to IBM President J.D. Kueh-
ler dated 28 March 1985, Bertram finally
certified DB2 for general availability. Such
was the beginning . . .
Marilyn Bohl was the prod-
uct manager for IBM’s DB2
version 1, agreeing to build
IBM’s relational database
product development team in
1979. After eight years and
an ever-expanding role with
DB2 and IBM’s relational data-
base strategy, she left IBM to participate in the
emerging PC industry. Later, she again managed
relational database technology as a senior vice pres-
ident with Ingres. She is currently enjoying life
in Southern California. Contact her at bohl22@
msn.com.