Steve The point of this analogy is really that interpretation of a model that involves translation, for instance from a static medium into dynamics (or sound), is a skill that has to be acquired through training and/or practice.
This can be constrasted with, say, an architectural model of a building. Here the only difference is scale and the model is thus easy to interpret for the layman. > So there might not be a standard way for IT to communicate how it understands > the business > but we need to be clear that this is a failure of IT's ability to communicate > rather than the > businesses ability to understand what it does. I agree. > My issue with arguments such as the one below is that they assume that the > failure is in > comprehension from the business. I don't think the argument below makes any such assumption. My point was that, if IT people want to convey their models to business people (who, in general, are not experts at interpreting models), the IT people must render their models into an understandable form. If IT people fail to do this, and therefore fail to communicate effectively, it is their fault. The (oft cited) problem with traditional (waterfall) development is that the first time business people see models so rendered is when the software is available for test, by which time it is normally too late or difficult to change it. Rgds Ashley
