This chapter is from the book
This chapter is from the book
This chapter is from the book
1.2 Evolutionary Data Modeling
Regardless of what you may have heard, evolutionary and agile techniques are not simply "code and fix" with a new name. You still need to explore requirements and to think through your architecture and design before you build it, and one good way of doing so is to model before you code. Figure 1.1 reviews the life cycle for Agile Mobile Driven Development (AMDD) (Ambler 2004; Ambler 2002). With AMDD, you create initial, high-level models at the beginning of a project, models that overview the scope of the problem domain that you are addressing as well as a potential architecture to build to. One of the models that you typically create is a "slim" conceptual/domain model that depicts the main business entities and the relationships between them (Fowler and Sadalage 2003). Figure 1.2 depicts an example for a simple financial institution. The amount of detail shown in this example is all that you need at the beginning of a project; your goal is to think through major issues early in your project without investing in needless details right away—you can work through the details later on a just-in-time (JIT) basis.
)
Figure 1.1 The Agile Model-Driven Development (AMDD) life cycle.
)
Figure 1.2 Conceptual/domain model for a fictional financial institution using UML.
Your conceptual model will naturally evolve as your understanding of the domain grows, but the level of detail will remain the same. Details are captured within your object model (which could be your source code) and your physical data model. These models are guided by your conceptual domain model and are developed in parallel along with other artifacts to ensure consistency. Figure 1.3 depicts a detailed physical data model (PDM) that represents the extent of the model at the end of the third development cycle. If "cycle 0" was one week in length, a period of time typical for projects of less than one year, and development cycles are two weeks in length, this is the PDM that exists at the end of the seventh week on the project. The PDM reflects the data requirements, and any legacy constraints, of the project up until this point. The data requirements for future development cycles are modeled during those cycles on a JIT basis.
)
Figure 1.3 Detailed physical data model (PDM) using UML.
Evolutionary data modeling is not easy. You need to take legacy data constraints into account, and as we all know, legacy data sources are often nasty beasts that will maim an unwary software development project. Luckily, good data professionals understand the nuances of their organization’s data sources, and this expertise can be applied on a JIT basis as easily as it could on a serial basis. You still need to apply intelligent data modeling conventions, just as Agile Modeling’s Apply Modeling Standards practice suggests. A detailed example of evolutionary/agile data modeling is posted at http://www.agiledata.org/essays/agileDataModeling.html.