In the second of two articles, the authors describe how to develop business patterns based on business functions, data, and business components, and show how these can be used to engineer software systems.
Data models and data profiling are complementary techniques. Although data models do not tell us the whole truth, profiling the database does not provide the whole truth either. In fact, both may be misleading. However, used together, they can provide better insight into the data.
XML is a perfectly good vehicle for describing data to be transmitted from one place to another. It is not so good for describing the semantics – the nature of – the underlying data. It cannot replace data modeling and sound database design. XML, data modeling, and database design are all ways to structure data. Each has its place. Unfortunately, our industry is somewhat confused as to what those places are. This article attempts to sort that out.
There has been much discussion about “atomic” data, but what about “molecular” data? This concept encompasses not only more concrete data specifications, but also more abstract function specifications, than conventional application development techniques.