So, you have built a gorgeous model of your software requirements or architecture? Now what to do with it? Many people look for benefits by automating certain aspects of modelling, like checking or transformation. Although this is an intriguing area with huge potential, IMHO the real killer application of modelling lies in a completely different aspect. From my own experience as a business analyst (BA) in quite a number of IT projects I would say: the killer application of a model in software development is talking about it.
Now, “talking about it” sounds simple at first. However, have you ever tried to discuss your ideas with somebody who has a completely different underlying model of how to think of the situation? Quite often it goes like this: I say “” and two hours later, after an exhausting debate, we find out that “” are actually the same, just seen from a different angle. Sounds familiar? And even if our opinions really are contradictory, we still need a common ground if we are to compare them and argue about them. This is what a common underlying model can provide.
Nowadays, software projects are quite heterogeneously staffed, since, for example, there may be a need to scale up the number of people within a short period, special skills may be temporarily required or the project may be affected by a general reorganization. Thus, professionals with different roles, experiences and schools (of thinking) must find a common ground from which to discuss issues such as the business domain, applications of the technology and how to collaborate. This common ground can range 
from attaching accepted and meaningful names to objects and relations in the business domain so that they can easily be referred to, through defining appropriate abstraction layers for discussing and deciding on technical architecture, to agreeing on basic notions, such as what is a requirement at all, where does the biz domain model end and the technical architecture start and what are the consequences for project roles and responsibilities. And it doesn’t matter what some book or standard says. In the end, the project itself should decide which concepts or approaches to adopt or to define.
Despite the fact that models of requirements, architectures or the software development process itself can be of great use, the way these models are actually used in software projects varies largely. It ranges from horror scenarios, like posterior documentation or ending up in some abandoned folder, to highly beneficial usages forming a basis for common understanding, debate and decisions, where people really “speak model”.
So, there’s a lot to find out, like:
1. One size doesn’t fit all: classifications of model users
2. Thinking about “talking about it”: classification of communication/ collaboration scenarios involving models
3. How can we tell good models from bad models (for communication purposes)?
4. How fit are current modelling languages for the above scenarios, and how could they be improved?
5. How can we make software development people really adopt a model-based collaboration?
So long,
|=
PS: More on practical software modelling:
modelpractice 
Pingback: Modelling the World … | modelpractice