Data Architects and UML - Talk at EDW 2011
This week I am speaking at the Enterprise Data World conference in Chicago. The topic of my talk addresses an issue that is often wrought with pain and loaded with emotion: data architects and UML. Today, data architects are exposed to UML from a variety of sources as they are consuming models that act as starting point for data models. These inputs appear as domain type models, models of messages in SOA, models of information that are part of analysis models of software and more. Sometimes, in agile projects there is even an expectation that the data models will be created in UML, as UML is used by the rest of the development team and the models evolve over time.
Some years ago a common attitude of data architects towards UML would be to just ignore it in the hope that it would just go away. But today data architects would do better if they learn enough of UML to be able to better participate and communicate with other stakeholders in the software development process.
Here is the good news: it takes only a tiny fragment of UML for one to become productive in using UML for data modeling. It is a separate issue that a typical UML training dumps on unsuspecting students a smorgasbord of UML features following the reference documentation, many of features foreign to the tasks of participants. No wonder that UML is often perceived as a heavy and complex. In my work as an educator, I believe that the training must be adjusted to the audience and that it is important to start with a subset of the language that would make the participants immediately productive.
This is the background of the talk. In the talk we introduce the most essential concepts and discuss the mapping to typical concepts found in data modeling notations. The talk is designed to give data architects a good start and encourage them to look into UML. It is supposed to be painless. In a real training session or in a workshop with a client, we would immediately start applying UML through a set of exercises, starting small and then developing more complex examples. Such a session would often start on a whiteboard and later we may switch to a real modeling tool.