Application DB Lifecycle

The application database process and its associated lifecycle have been around for 50 years and is a subset of the larger systems development and enterprise development lifecycles and methodologies.

Some organizations will execute the lifecycle one phase at a time, completing each phase before beginning the next -- the "waterfall" lifecycle. Other organizations will employ an iterative and incremental process where more than one iteration of the development cycle may be in progress at the same time. This approach may be described as "evolutionary acquisition."

The approach suggested in this site depends on an iterative and incremental process to integrate the business's smokestack systems into a true enterprise-wide information resouce.


Business executives, managers and staff interact with the data architect/analyst to identify and describe the business environment, business relationships and business objects. This phase is a big "data collection" job. The analyst/architect does not address business processes. The business systems analyst is doing that.


The analyst/architect provides the database administrator (DBA) with the models and associated entities, attributes and identifiers that are discovered during the Requirements phase. These are the input to the DBA's design phase.

The Requirements and Design phases are iterative and the architect/analyst and DBA are friendly opponents that engage in a constant peer review. The architect/analyst represents the business unit and the DBA represents the corporate information facility. They are not each others enemy. When that happens, everybody loses.


This is the phase where the DBA does his/her thing and a good DBA is worth their weight in platinum.


Populating and validating the database should begin as early as possible. There is a ton of work involved in moving data around, creating data sets, scrubbing data, validating data, reparing data . . . it never stops . . . ever!


In the past, each of the above lifecycle phases would be completed before beginning the subsequent phase. Some of us, the ones that recognize that "you're never done," have experienced the price paid for this "waterfall lifecycle."

The key to your success is iteration. You don't have to "get it right." You only need to get one. Then you iteratively make it better. Once the Requirements/design team have a first cut database, they encourage the application developers to begin hitting against the database. Learn where the problems are early.

The key to your success is iteration (besides, it's never "done").