In a discussion in the IIBA LinkedIn group, someone asked ‚Are any of you using UML, and how is working out for you?‘ The answer is like always: ‚it depends‘. It depends on the situation and what others expect.

I use diagrams depending on the complexity of the undertaking and the current unknowns. If all stakeholders (as defined by Alexander) agree that everything is clearly understood equally among stakeholders, then there would be no one needing my analysis and it would present no value for anyone. Whether I believe that there may be misunderstanding among the stakeholders doesn’t really matter – unless I am given the go-ahead to analyze the situation, anyway.

Why does an architect create a blue print for your house? It is not because the architect thinks it would be nice to have one. It is because the builder wants to know exactly what should be build. And the agreed method of communication is the blue print.

If the stakeholders agree that we currently disagree on what should be build, then the context diagram provides an early visualization of the scope of the undertaking, the actors, and the complexity of their interactions of the system under development (SUD). Next, use case diagrams and describe the needed functionality required from a black-box perspective. In parallel, I start the business object model using class diagrams to clarify terms and their relationships.

Even in situations in which an agile approach is preferred, these three types of diagrams should be a must.

We need to identify early, what needs to be modeled, why a model is helpful, and which parts of the model we want to use in a model-driven approach. Are the models throw-away? Will we maintain them and keep them current? On which level do we model? Many modelers cannot answer whether they are modeling on a conceptual, logical, or physical level and why they are doing it.

Whether more detail is helpful to anyone but the creator of the diagram depends on the situation.