Data has been an important aspect of every business application development project Ive ever been involved with. Yet data issues are given short shrift in modern software development methods, particularly those geared toward object technology. The Rational Unified Process (RUP), the industrys leading prescriptive methodology, is clearly no exception: Although it briefly overviews data modeling, RUP provides little guidance in addressing the complexities of data issues on RUP projects. Its time to rectify this deficiency.
Data professionals offer many of the valuable skills software development teams requireskills that arent well addressed in RUP. First and foremost, data professionals understand the enterprises need for consistent and accurate information shared across applicationsa need that developers often dont appreciate. Second, they understand and can help project teams access legacy data sources, which can be extremely challenging due to quality, design and architecture problems. Third, data professionals can provide project teams with data modeling and ideally with object and relational mapping. All of these tasks are important and often difficultits unfortunate that RUP understates the complexity of data-oriented activities.
RUP Isnt Traditional
Despite the positives, many data professionals also bring inappropriate philosophies
to software development teams. They often prefer serial development approaches
in which comprehensive data models are developed early in a project, then are
reviewed and accepted, baselined, and put under change control. Although this
process is convenient for data professionals, it puts projects at risk because
it hampers the ability to react to change. Like it or not, our stakeholders
change their minds about the priority, meaning and relevance of requirements
throughout a project. If our requirements evolve over time, so must our designs;
we must be flexible to be effective, which means that a serial approach to data
modeling wont work.
RUP acknowledges that requirements evolve over time and therefore takes an evolutionary (iterative and incremental) approach to developmentits iterative in the small, serial in the large, delivering incremental releases over time. To fit into a RUP project, data professionals must adopt modern, evolutionary approaches to data-oriented development (see Join the Evolution). Other IT professionals have adopted evolutionary techniques and have improved the quality of their workdata professionals must now do the same.
RUP 411
At some point, an organization adopting RUP asks itself, How do data professionals
fit into a RUP project team? The answer? They fit in very well, thank
youwhen they work in an evolutionary manner. Therein lies the rub: RUP
doesnt provide much advice on the subject, and data professionals frequently
prefer to follow traditional, and often ineffective, procedures.
To understand why this is an issue, you need to know the way that RUP works. The RUP lifecycle is based on four consecutive phases, a format that can often make traditional developers mistakenly believe that RUP is similar to the serial processes theyre familiar with. Instead, data-oriented artifacts, such as conceptual models and physical data models, evolve as a project progresses through the four phases. Lets examine each phase in order, discussing the data professionals potential role.
In the Inception phase, your goal is to identify your systems high-level requirements to determine its scope, achieve stakeholder concurrence as to the scope, and obtain project funding. Part of your initial modeling efforts should include high-level, conceptual domain modeling, which identifies the major business entities and the relationships among them. Detailed data models arent yet needed, as you want to model just enough to understand the domainany greater effort could be a waste of time because once you better understand the requirements, you may discover that the project doesnt make much sense and should be canceled.
During the Elaboration phase, your primary goal is to identify a system architecture and prove that it works via an end-to-end technical prototype. Data architecture issues, including online transaction processing (OLTP) databases, data marts, data warehouses and legacy data sources, should all be considered in this phase.
In the Elaboration phase, youll also flesh out approximately 80 percent of the requirements and do some initial analysis and design. Because RUP is object oriented, any detailed analysis-level modeling would probably be done using an analysis class model as opposed to a logical data model (LDM). Detailed physical data modeling typically isnt yet required because your implementation efforts focus on developing a technical prototype. However, you may need to do some physical data modeling for the subset of the database schema required for any sort of stress testing of the technical prototype. For example, if your system must process 1,000 business transactions per second, youd want to do enough work to show that your overall architecture, including your databases, can handle it.
During the Construction phase, your goal is to build a working system thats ready to be put into production. On RUP projects, the construction effort proceeds in iterations, typically several weeks in length, during which a subset of the requirements is implemented. A six-month construction phase might be organized into six iterations of four weeks each, or even 12 iterations of two weeks each. By taking an evolutionary approach, youre able to provide your stakeholders with regular and concrete feedback in the form of working software. This not only shows them that youre proceeding successfully, but also provides opportunities for them to rethink and then evolve their requirements as the project progresses, ensuring that you build a system that meets their true needs.
Data professionals must evolve their models, including their database schema, throughout a project. Not only should data professionals take an evolutionary approach to data modeling, they should also refactor their database schema (www.databaserefactoring.com) just as object developers refactor their object schemas (www.refactoring.com). If your system needs to interface with existing legacy systemsand it often doesdata professionals are probably necessary for legacy integration efforts.
During the Transition phase, you perform system and user testing to make needed corrections, and to ensure that the system is ready to be deployed into production. Then, you actually deploy the system. The need for data professionals, and for programmers, clearly decreases during this phase.
[click for larger image] The Enterprise Unified Process Lifecycle This lifecycle as an extension to the enhanced RUP lifecycle I originally proposed in Enhancing the Unified Process (Oct. 1999); Data concerns, such as enterprise data modeling and data administration, are naturally an important aspect of these extensions. |
Beyond RUP
One strength of data professionals is their understanding and appreciation of
enterprise issues, at least when it comes to data. RUPs focus on software
development is deficient when it comes to enterprise concerns such as enterprise
architecture, reuse and enterprise data administration. The minimal information
about database development, and the lack of enterprise focus, are the primary
reasons why data professionals are less than enthusiastic about RUP, and rightfully
so. Luckily, in The Enterprise Unified Process: Extending the Rational Unified
Process (Prentice Hall, 2005), John Nalbone, Mike Vizdos and I describe
how to extend RUP to address enterprise concerns. Data concerns, such as enterprise
data modeling and data administration, are naturally an important aspect of
these extensions. The Enterprise Unified Process Lifecycle is depicted
here. Weve suggested seven new enterprise
disciplines, and see this lifecycle as an extension to the enhanced RUP lifecycle
I originally proposed in Enhancing
the Unified Process (Oct. 1999).
Enterprise domain modeling, in which you create a high-level slim domain model identifying your organizations main business entity and the relationships among them, is a vital part of the Enterprise Business Modeling discipline. Project teams can use this model during the Inception phase, promoting consistency among applications. Its typically fleshed out into a detailed enterprise data model as part of the Enterprise Administration discipline, and can be used by your operational data administrators, as well as by project teams, in the Construction phase, to ensure consistency in their detailed data models.
Enterprise data architecture issues, such as what data sources exist and what middleware should be used to access them, are a concern of RUPs Enterprise Architecture discipline. The Operations and Support discipline offers activities for the operation of your databasesincluding monitoring, backup and restorationonce theyre in production.
Data is clearly an important aspect of any RUP project, and RUP must evolve to reflect the data-oriented issues faced by most organizations. This evolution entails a sharper focus on development-oriented data activities, as well as extending RUP to address data activities that occur at the enterprise level. At the same time, data professionals must evolve their approaches to reflect modern software development methodologies. Unifying your data and development practices is possibleit just takes an open mind and a bit of hard work.
Senior Contributing Editor Scott W. Ambler is author of the Productivity Award-winning Agile Database Techniques (Wiley, 2003).