Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Channels ▼
RSS

Rationally Unified Data


Rationally Unified Data

Data has been an important aspect of every business application development project I’ve 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 industry’s 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. It’s time to rectify this deficiency.

Data professionals offer many of the valuable skills software development teams require—skills that aren’t well addressed in RUP. First and foremost, data professionals understand the enterprise’s need for consistent and accurate information shared across applications—a need that developers often don’t 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 difficult—it’s unfortunate that RUP understates the complexity of data-oriented activities.

RUP Isn’t 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 won’t work.

RUP acknowledges that requirements evolve over time and therefore takes an evolutionary (iterative and incremental) approach to development—it’s 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 work—data 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 you—when they work in an evolutionary manner. Therein lies the rub: RUP doesn’t 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 they’re familiar with. Instead, data-oriented artifacts, such as conceptual models and physical data models, evolve as a project progresses through the four phases. Let’s examine each phase in order, discussing the data professional’s potential role.

In the Inception phase, your goal is to identify your system’s 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 aren’t yet needed, as you want to model just enough to understand the domain—any greater effort could be a waste of time because once you better understand the requirements, you may discover that the project doesn’t 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, you’ll 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 isn’t 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, you’d 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 that’s 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, you’re able to provide your stakeholders with regular and concrete feedback in the form of working software. This not only shows them that you’re 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 systems—and it often does—data 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. RUP’s 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. We’ve 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 organization’s 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. It’s 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 RUP’s Enterprise Architecture discipline. The Operations and Support discipline offers activities for the operation of your databases—including monitoring, backup and restoration—once they’re 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 possible—it 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).


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.