The only problem with this though is that the expertise is really the other way around. The composer and the musicians are the people creating the music, thus I'd say that they are the business. IT provides certain facilities to them, e.g. makes the instruments and puts out the chairs.
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'd argue that most businesses seem to be pretty effective at understanding and explaining what they do, the problem is almost created by the IT organisations who want everything to be transfered into a binary form. To stretch this analogy to breaking point Maybe business is a jazz band and we are trying to document it within a single stave and then complaining when they improvise. My issue with arguments such as the one below is that they assume that the failure is in comprehension from the business. Given that they are the people who understand both what they want the processes they want to see delivered this is a brave statement, the reality of the failure is that IT wishes to complicate this communication with information that is just noise to the business people. Again to use the analogy, does a violinist need to know how to cut down a tree in order to play? Of course not, but in IT we will talk about "security" and "database access" to someone asking to put their sales information onto mobile phones. Steve On 17/01/07, Ashley at Metamaxim <[EMAIL PROTECTED]> wrote:
Dan, Steve, Hitoshi I think, perhaps, there is an analogy between modelling and music. A composer uses musical notation as the medium for composition and, through familiarity with the medium, can "hear the music" from the notes on the page. For a non-musician, however, the notes are a foreign language and need to be heard to be understood. Similarly, an experienced modeller uses graphical or other notations to define the behaviour of software. Through familiarity with the notations, the modeller can "envisage the behaviour" from the diagrams he or she draws. Both the musician and the modeller are performing an act of translation: from static representations on the page into (in the first case) sound and (in the second case) interactive dynamics. Arguably, both forms of translation require a skill that has to be learned and practised. In order to convey a piece of music to a non musician, the composer will play it on a piano thereby realising the translation. Similarly, to convey a behavioural model it may be necessary to render it into the behaviour it represents. This could be by execution (if the model is executable) or by some form of manual simulation. It may be that "standard modelling language for business people" is not possible, any more than a form of musical notation suitable for non musicians. Rgds Ashley
