Why Read This Book?

Systems Development Is a Team Sport

In today's business climate, systems development is a game that you can't afford to lose. Losing the game can literally cost you your entire business. Business analysis, software development, and database teams all need to work together to understand a business customer's problems and to solve them through the software systems they are assigned to create. We do not build systems just for the sake of keeping our jobs. There are valid business reasons for the systems. The typical overall goal is to make the business better (more efficient, more profitable, and so on). Sometimes the problem to solve lies not in the software but in the way a business process is performed. You may be improving infrastructure, customer experience, internal experience, or some type of business process, but it is not just for the sake of adding or changing the systems. There are critical requirements that need to be met, and it is the responsibility of all teams involved to create the best and most economical solution to fulfill the requirements levied upon them by the business.

In most organizations today, the analysis, development, and database teams work for different managers, business units, or other business organizations. Although these teams are separate, they are all working toward a common goal and need to work together. We have witnessed situations where members of the different teams had to be introduced to each other by name during a meeting although they had been working on the same project for years . This is not a good scenario. It causes the communication of requirements, and especially changes to those requirements, to be lost, misinterpreted, or resolved differently by different groups.

Generally you are not just changing one part of the system but also adding different pieces to a constantly changing system as new requirements are uncovered. In other words, software development is an iterative process. As the developers build the applications, they uncover new requirements just as the data base team uncovers new requirements when building the database. These all need to be communicated not only via documents but also visually through models. This enables these requirements to be traced to the different artifacts throughout the development cycle. However, in the past this could not be done easily since there was no common language for all the development teams to use.

The Unified Modeling Language

The Unified Modeling Language (UML) has quickly become the standard language used for modeling business and software application needs. Although it is the standard of the Object Modeling Group (OMG), the UML is not just for modeling object-oriented (OO) applications. A common misconception is that the UML is intended only for OO development and can't be used for other types. However, the UML was designed as a very flexible and customizable language. This allows for many different types of modeling, including models for understanding the business process, workflow of events, sequence of queries, applications, databases, architectures, and more.

Using the UML for database design allows the business and application teams who are already using the UML for their designs to share a common language and to communicate with the database team. A common problem is that business analysts and developers are building enterprise architectures without considering the data and how the data will be affected. Can the database capture the information that is being described? Are there existing systems that already address the business's needs but are unknown to other teams? Do items with the same names mean completely different things? All of these questions lead us to conclude that the database team should be involved at the beginning of the development process, taking part in the initial analysis and continuing all the way throughout the complete development life cycle. With the ability of the UML to design so many different visual models, you can encompass an en tire application and database design using a single language that everyone can share.

While reading this book, you will learn the different types of UML diagrams and how they apply to the database world. You will also understand how other teams may be using these diagrams and how all the teams can share their work rather than working in separate silos , not communicating until it is too late.