The Rational Unified Process (RUP),
Process (AUP), and the Enterprise Unified Process
(EUP), are instantiations of the Unified Process (UP). A fairly
common question that many organizations face is "how do data professionals fit
into a RUP project?" Very well, actually, when the data professionals
choose to modify their approach to meet the realities of the RUP. The RUP takes an evolutionary (iterative
and incremental) approach to development. Unfortunately many data
professionals prefer a more traditional, serial approach to development where
comprehensive data models are typically developed very early in a project,
reviewed and accepted, and then baselines and put under change control.
Although this is very convenient for the data professionals it puts projects at
risk because it hampers their ability to react to change. Luckily, as
this site amply shows, data professionals
can in fact work in an evolutionary manner if they choose to do so.
To understand why there is an issue, you need to understand the way that the
RUP works. The RUP lifecycle is based on four consecutive
phases (the EUP
adds two more so as to cover the entire system lifecycle, not just development).
The fact that there are four serial phases can often motivate traditional
developers to believe that the
is similar to the serial processes that they are familiar to. This
isn't the case. Instead, I like to say that the RUP is iterative in the
small, serial in the large, delivering incremental releases over time.
Let's look at each phase in order, discussing the potential role for data
- During the Inception
phase the goal is to identify
high-level requirements for the system so
that the scope may be identified and project funding obtained. Little,
if any, data
modeling is performed at this point although some conceptual modeling may
occur. Detailed data models are clearly not needed at this point, nor
should you be sidelined by some needless quest to ascertain the "one
- During the
Elaboration phase the goals are to flesh out the requirements to the 80%
envision an architecture for the system, and to prove that the
architecture works via an end-to-end technical prototype. Enterprise
architects may be involved with this effort, and one of several issues that
they are likely to address is data architecture. See
Enterprise Architecture for some thoughts on how architects can work in an
agile manner. Once again, detailed data models are not needed at this
- During the
Construction phase the goal is to build a working system that is ready to
be put into production. It is at this point that data professionals are
likely to be needed. In the RUP development proceeds in iterations,
typically several weeks in length, during which a subset of the requirements
are implemented. For example a 6 month construction phase might be
organized into 6 iterations of four weeks each, or even 12 iterations of two
weeks each. During each iteration your analysis models, design models,
source code, and test suite are fleshed out to implement that iteration's
requirements. In other words your development artifacts, including your
data-oriented artifacts, evolve over time. The implication is that data
professionals need to be prepared to grow their models, including their
database schema over time. Furthermore they may discover that they may need to
refactor their schema to reflect the needs of new requirements. If your
system needs to interface with existing legacy systems, and it often does,
data professionals will likely be needed to be involved with legacy
integration efforts. Data models are very likely needed, but they're not
needed up front.
- During the
phase the goal is to system and user test the system to ensure that it is
ready to be deployed into production, to make needed corrections, and to
actually deploy the system. The need for data professionals decreases
during this phase.
So how can data professionals involved with their their first RUP project
learn to work in an evolutionary manner via the philosophies and agile database
techniques of the Agile Data method? My advice is to do the following:
Note that there is an assumption in the writings at this
site that project teams are taking an agile approach to software development.
This may not be completely true of a RUP project team, although hopefully should
be, but what is true is that the team will be taking at
least an evolutionary approach. Therefore the techniques described at this
site are still applicable although may be a little harder to accomplish in
environments where the RUP has been instantiated in a non-agile manner.
- Read The
Agile Data Method to learn the philosophical underpinnings
of the evolutionary database techniques.
- Read The
roles on Agile Data Projects to learn about the two roles that they are
likely to fall into, Agile DBA or Enterprise Administrator, and how they can
effectively interact with evolutionary teams.
- Read Evolutionary
Development to gain an overview of basic development techniques for
evolutionary database development. Repeat after me: comprehensive data models
are not required up front, comprehensive data models are not required up
front, comprehensive data models are not required up front, ...
- Read Agile Model
Driven Development (AMDD), posted at
www.agilemodeling.com, to learn
about how it is in fact possible to model in an evolutionary and
documentation-light manner, instead of the traditional serial and
documentation heavy one that many data professionals are accustomed to.
- Read The
Process of Database
Refactoring to learn how to evolve a database schema after the fact.
It is a myth that you must have the database schema in place, or at least
mostly in place, before coding begins.
- Read Why
Data Models Don't Drive Object Models (And Vice Versa), The Object-Relational Impedance Mismatch,
and Mapping 101
to overcome any misconceptions about how to effectively use object and
relational technologies together.
- Read the rest of the articles at this