A Brief History of Modern RDBMS Technology & Information Technology Management Practice

A Brief History of Modern RDBMS Technology
& Information Technology Management Practice

PRF Brown
Winluck Pty Ltd.
IT Managers & Engineers
Falls Creek, NSW, Australia
http://www.mountainman.com.au/software/Winluck




Welcome.

In the following series of articles a specific environment in the many and varied realms of Information Technology environments will be explored in a little detail. This is the domain of the RDBMS, or Relational Database Management System. Such systems have evolved, in the course of time, due to the demand for the services that these systems provide.

Also considered in these articles is the parallel requirements of IT Management practices as the decades brought one wave of technological change after another. When the first cars appeared, they were often accompanied by a stand-by mechanic with a toolbox in hand riding on the running boards and ready for any roadside repairs.

IT Management started as a similar form of occupation, but in this instance the machines were data processing engines, and their purpose was not to traverse the earth, but to traverse the diurnal organizational cycle of capitalising on the electronic record keeping arrangments.

Organisational investment in these machines became more focussed. Scientific, administrative and business organisations strove to idealise the paperless office. Up-time and reliablity were gradually pegged back and harnessed through plain old research and development, until the data processing engines could be relied upon to function day in and day out.

What was it like a decade back to manage an IT environment, and what is the nature of the occupation today? These questions and others are explored and the answers provided are from experience on the production floor.

The articles are below indexed:

• Article 1: In the beginning was the Code.
  This article examines the origins of IT's holy grail, a shoebox full of punch cards, and a box of valves conspire to work together and perform a task of computation. Enter loadable programmatic coded instructions. Enter a host of hardware platforms. The code went rampant. Organizational intelligence was redefined many times over each second as the code went through its executions.
• Article 2: Emergence of the Database Management System (DBMS)
  This section deals with the crystalisation of applications that were characterised by their ability to manage data structures earlier specified by the application code. But problems soon appeared in the primitive data structures when load was applied, either through increased transaction throughput, or in increased record lengths of the constituent database structures. Concurrency problems, multi- user access problems, ever-increasing structural sizes. These and other challenges were met on the ground of theory, as well as on the production floor of live systems.
• Article 3: Emergence of the Relational Database Management System (RDBMS)
  This section diverges into the theory of the Relational Database model as first espoused by Codd, Date, and others. It examines history not according to the RDBMS vendors secure pathway of benefits that has advanced over time. It is certainly acknowledged that the rigorous and academic, shall we say "quality assurance by peer review process" of all RDBMS products is necessary for the long-term evolution of such systems. However my perspective is different again simply due to my experience in the field of IT Management at organisations which had to come up with the workable solution by dawn and the opening of business. We look at data integrity issues, their consequences and their work-arounds when the underlying DBMS (or is it RDBMS?) fails to provide a consistent integrity constraint mechanism.
• Article 4: Under the hood of the Modern RDBMS
  When the bonnet is lifted on a modern RDBMS it is beginning to look like there has been alot of work going on behind the scenes. These Database Management Systems have a range of attendant suites of tools and utilities which are all geared towards automation. Import and export, inter-database object transfers, scripting, indexation management, database backups and restorations, user and security administration, transaction logging, rollback and recovery, replication mechanisms, and at the backbone of the organisation, a mechanism to schedule all such tasks.
• Article 5: Change Management and Systems Environments
  Long serving IT professionals can probably recall at least one major overhaul of their database systems environment every decade. But often that is because their memory is failing, and the days of mainframe, or midrange computer operating system software (and DBMS) upgrades are remote in time. Somehow things have gotten more complex.

  Change Management is probably the largest single task (if indeed it could ever be called single) performed by an IT Manager and support staff at any organisation. It is simply the management of change, but it is rarely a simple task due to the complexity of the environment.

  
  

• Article 6: The Generic Change Management Flowchart
  This article examines the 11 steps of the change management cycle from a global perspective, and then scrutinises in succession each of these steps, to determine what is the essence of step. This is an exhausting but worthwhile process, for it quantifies a number of variables in change management, including the turnaround time, (and this from multiple perspectives), the number of coordinating parties at any given time, the exact number of critical points where all the involved people may consult in realtime. Also, it provides a mechanism to derive approximations of the costs of change management, by identifying its workflow patterns.
• Article 7: Future change management
  Large scientific, administrative and business organisations all share a common focus in the RDBMS. Today they also share a task in the management and change management of their preferred database application software product or products, running on their preferred RDBMS solution. Costs of such environments are not decreasing, and this concerns executive. Complexity of solutions is not decreasing, and this concerns the IT Manager. Where is change leading information technology?

  1) Answer: Not known
  2) ETA: Not known (See 1)
  3) COST: Not cheap.(See 2)

  The problem appears to me clearly to reside in the manner by which change in the RDBMS client environment is inordinately dominating attention. By this I mean continuous change of the database application software product code, either in the text of the code, or in its form, in its version or patch or new release, or in any other form whatsoever that "the code" might be conceived.

• Article 8: The Future Technology of the RDBMS Environment ...
  The above picture appears reasonably non-eventful in terms of new horizons. Nothing much has changed in the underlying management and administration problems associated with large scale database application software required as the user-interface to the RDBMS. It will take a new approach to this long-term problem in order to solve it.

  This final article in the series examines such a newly appeared alternative to the deployment and development of organisational intelligence, whether it be scientific, administrative or business in nature.

  In this article we use our experience as IT Managers of yesteryear to specify and reverse engineer one mode of dealing with all such identified problems. The method utilised is unique, universal and rich in benefits, not the least of which being the empowerment of those people with initimate knowledge of the RDBMS native utilities and their functionality.

  In this final article we examine what will more than likely become a new technology.