© 2003 International Business Machines Corporation. All rights reserved.
DB2DD: Thank you very much for talking with us. You've been with DB2 and data management longer than perhaps anyone else I know. But I've never heard how you ended up at IBM. Can you give us a little history of how that happened?
Don: In 1967 I graduated from UC Berkeley and took a job with the Port of New York Authority in New York City as an application programmer to work on a wide variety of applications including general ledger, real times systems for maintaining traffic movement in the tunnels and bridges, and analysis of elevator traffic, motion sickness related to building sway, and other studies for the World Trade Center.
They had just installed an IBM System/360TM when I arrived and discovered that they needed someone called a "system programmer". The prior generation hardware had I/O drivers which programmers loaded, but no operating system per se - no multiprogramming - you ran one application at a time. With the introduction of MFT on S/360 suddenly you could run multiple applications at the same time, which made it difficult for the application programmer to do problem determination and other tasks. IBM sent 4 large boxes of manuals and because I was the new kid, they turned around and said "Here, kid. Read these and tell us what we need to do." I read them all in a couple of weeks understanding about 20%. I went to IBM classes at night and figured out what was needed. This turned me onto operating systems.
My wife and I were born and raised in San Francisco. All of our family was in the Bay Area. The pay in New York was barely subsistence level. We decided to head back to the west coast after a year in New York, even if we had to mooch off the family. My brother, Jack, was a programmer on the west coast and told me that they were paying close to twice what I was getting paid in New York. I sent my resume off to IBM and a couple of other companies in the Bay Area. IBM had interesting work and they met my request for an outrageous salary of $10,500. So I joined them in 1968. We lived high on the hog for the next year.
DB2DD: So you were here on the West Coast long before DB2 got started.
Don: I worked on several projects before ending up in what became DB2. I worked on a real time operating system called MPX for the IBM 1800 which was used in manufacturing and process control. That was followed with a project for automating supermarkets, which was commercialized with IBM Point of Sales offerings. Both of these projects shifted to other locations because IBM San Jose was bursting at the seams with work.
In 1970 MVS was under development for IBM S/370TM and I was asked to lead technical development for data management services. This was followed by a series of projects on S/370 including definition of the security system, RACF®, with respect to data management
I joined the database project (known as EAGLE) in 1978. Bob Jackson led systems services and I led database services. EAGLE evolved into DB2, shipping to beta customers in 1983. It consumed twice the processor as hierarchical database systems to perform the same work. But you could develop and deploy an application 3-5 times faster. To broaden the market appeal we had to get the hardware costs down. By 1989 (DB2 V2.1) we had processor costs within 15% of hierarchical database systems, the capabilities for robust transaction processing, and highly competitive analytical and query capability, coupled with the advantages in application development and deployment. Sales of DB2 took off.
DB2DD: You are heavily involved with research. How did that start?
Don: DB2 originates from the IBM Research prototype, System/R. Development and research collaborated to create the DB2 product. After launching DB2 we were faced with many very tough technology problems that needed deep thinking with enduring solutions. The researchers were working on next generation technology. But if we didn't solve the current generation problems, there wouldn't be a next generation. Irv Traiger who was managing the computer science department in San Jose Research and was one of our collaborators on DB2, together with Pat Selinger and I conceived the DataBase Technology Institute (DBTI), which joins research and development to work on advanced technolgy for the current generation. Pat formed and managed the group
Research has deep subject matter experts. Wedding them with expert software engineering from development produces a superior product for the market. And you get headlights into the future.
DB2DD: And has the DBTI concept been successful?
Don: It had tremendous impact. Mohan joined, and the first project was row level locking. The impact of that work (ARIES) is used by every database player in the market place. It achieved the effect we wanted - technology that would last for 20 years. It's been out 18 years so far. Not bad.
The second major project was the evolving Parallel Sysplex® on 390 - CMOS technology was less expensive than bipolar. We needed to cluster smaller units which led to sysplex clustering technology. We needed coherency and concurrency algorithms in a shared environment to make it scale. That project was in full swing by 1991.
And DBTI is still going strong. Right now there are a lot of projects involving XML, information integration, query processing, autonomics, business process integration, and more.
DB2DD: You were made IBM Fellow in 1989 and you're also CTO of the organization. How did that role evolve for you?
Don: In 1992 Steve Mills asked me to become a director, to move from the pure technical to the technical executive management side. Quite frankly, I didn't even know what that meant. At that time there wasn't a strong technology view inside the executive team. I was supposed to bring that perspective - I was supposed to link the technology to the customer business problem. Which really defines the office of CTO. It was new thinking for me.
IBM was just forming a software business. Up to this point software was developed to support the hardware - no other reason. Steve was developing IBM's software business. Janet Perna convinced the business that database management was fundamental to our success and, as such, we needed to expand beyond mainframe to open systems. I collaborated with Janet and others on defining DB2 UDB from a technology viewpoint; that is, what capabilities we needed to succeed in the market.
As CTO, I launched a number of projects: spatial DB2, DataJoiner® (federation), data warehousing, internet database access, object relational, stored procedure development, pervasive/embeddable database, and others which became products
DB2DD: And what has been the most successful of those projects?
Don: I think that in the long term, the most successful will be federated technology.
DB2DD: You have contact with many of our customers and partners in your job. How does what you hear from them influence what direction we take in Data Management and in software in general?
Don: It's a chicken and egg problem. On the development side, when we create a product, we understand the technology and we need to ground it with customers. From 1985 to the present, I've logged 300-400 thousand miles a year. I would see a customer a week on their home turf. I needed to understand executive business goals and the problems that the engineering teams and line of businesses had in satisfying those goals. The impediments may be organizational, technical, social, skills, or other perspectives. Technology solutions may reshape organizations or be constrained by skills. We need to understand what is preventing DBAs, etc, from extending their systems into new business initiatives
So, my day job was spending time with customers. My night job was understanding the technology and figuring out how to link the technology with the business problem.
DB2DD: Do you have any examples?
Don: OK, let's look at the Garlic project as an example. The Garlic research project dealt with the issue of integrating information from various data sources. To the consumer it offered a virtual database, providing the illusion that all of the data was stored in a single database. In reality the virtual database layer would federate a set of databases or files to form the image of a single integrated store. Prior to this the only topology to solve the problem was a data warehousing topology which extracted the data from multiple sources, transformed and copied it into a single database.
The federated topology is appealing. Today enterprises have an incredible number of data sources and application systems, which they need to aggregate and integrate to form a unified information view; e.g., a holistic view of their customer, of their suppliers, of their inventories, etc.They want the information near real time. Federation at its heart acknowledges that information is heterogeneous and deals with the metadata data, access, and currency issues for infromation.
Caching is a must to make such a topology perform and workable. Concurrent with Garlic research was research on smart caches, including materialized views or automatic summary tables and better understanding of business data coherency.
In the mid 1990s we produced DB2 DataJoiner, the first heterogeneous federated SQL database. It largely dealt with structured information that mapped well into the relational model; namely, databases and record oriented files. John Deere helped us understand how this technology would solve information integration and simple data access problems for them. We focused on customer usage and value.
The Garlic research expanded the information types that we could deal with and provided a better way for information developers to describe their information and capabilities to the virtual database via wrappers. This advance leads us to today where we can deal with a wide variety of information types - records, X-rays, spreadsheets, etc. - integrated into a single information model. We partnered with pharmaceutical companies to integrate myriad diverse information sources to form a unified view of experiments and allowed information to be shared across science disciplines. Once again, customer business problems drove the development of the technology.
Today integration is a fiat for businesses and this technology is core to solving those problems.
DB2DD: You are involved in the workgroups that are designing and delivering the IBM e-business on demand strategy. How has that strategy changed the priorities you've set for development in the information management portfolio of products?
Don: It has brought focus. The on demand part is "how do I make information and processes available on demand, real time, superfast?" Someone wants to order perhaps a hosted service or an in-house hosted service, or in house computational power. How can we speed up the link between the customer's initiative and ability to deploy?
The customer may not precisely know what the take up is going to be, how many transactions they expect, etc. They don't even know for sure if 100 people or a million are going to knock on the door on the first day. The on demand part of it is getting the technology to be more responsive and getting the business cycle to be more responsive. On demand brought focus on the time aspect from end to end, meaning the full business cycle from customer view from seen need to having deployment in their shop.
DB2DD: Wait a second. Does this mean that IBM itself is becoming an on demand business?
Don: Certainly! We are looking at how to get the IBM business cycle to be more response to customers.
This urgency for on demand reaches through every facet of IBM's business, not just the technology side. It filters into the way we do business, draw up contracts, deliver processing power. It filters into the way we assemble and test elements for configurations that will be used as utilities rather than making customers assemble bits and pieces of a solution from different products.
DB2DD: And on the technology side?
Don: On the technology side, on demand puts focus on us from an integration view. For example, we have programming models. What are the set of models by which we will solve a class of customer problems? There could be a thousand models. We need to decide on a model or set of models so that our technology will be honed for a set of assembly processes. We need to use those models to help us bring focus to everything from application design and development tools to the data store to manageability.
DB2DD: What are the inhibitors for becoming an on demand business, at least from a technology side?
Don: Complexity is a major inhibitor. There is complexity in data design and complexity cost in managing for availability, recovery, and for performance management and monitoring. Capacity planning is another huge issue. You design a physical database against a particular topology - then you need to redesign it because an application grows and changes.
The inhibitors are what drives our research and development efforts. That led us to the SMART [self-managing and resource tuning] initiative, which is now part of IBM's autonomic computing strategy. We are looking at how to make the DBMS smarter and self-tuning because if you look at the pressure points of time to market, it's the availability of the skills to do designs and redesigns and the cost of those skills were major inhibitors in creating a business solution.
DB2DD: Thanks very much for your time, Don, and I'm looking forward to hearing your Webcast on May 7, 2003.
Don: You're welcome. I hope people come with lots of questions!
All statements regarding IBM's future direction or intent are subject to change without notice, and represent goals and objectives only.

Don Haderle is the Vice President and Chief Technology Officer of Data Management and is a member of the IBM Academy. Don was one of the founding architects of DB2®, now known as DB2 Universal DatabaseTM. Today, Don drives development of XML, JavaTM, EJBs, and many other initiatives, including personalization and security to enable e-commerce and pervasive computing.
Comments (Undergoing maintenance)





