Scott,
Enterprise with no legacy, no precedent, straight business modeling in UML may be most helpful. But for an existing enterprise, I have following explanation. Existing complex enterprise comprises of both manual and automated components. Manual components employ physical structural elements to aid in the events/processes flow. Physical structure requires physical modeling while the automated component requires modeling of the 'abstracted' parts requiring digitization. One of the challenge for an existing enterprise especially for the service sector heavily dependent on the manual processes and undergoing automation is how to discover opportunities for processes automation and then to model them, develop them and finally plug them into the enterprise ensuring that no newer functional discontinuities are introduced. For situation like these Zachman's framework is most useful, to understand which of the existing matrix set of the physical structural elements are retained, which goes away and what comes into their place, while ensuring that there are no severe bottlenecks introduced b/n the physical and the automated processes. One more interesting observation is that while the physical structure are always in existence either aiding processes or not, software structural elements (elements of .mdl) comes into being only when the codes are executed. Consolidation of the contrasting nature of the architectural elements is of high interest for companies with complex set of manual and automated processes. When fool proof in theory then it is certain to work in practice. In product design world, electronics, semiconductor, mechanical, electrical etc, it is very important to get the theory correct through elaborate analysis and design before any physical prototype attempts are made. Especially in VLSI design, each chip costs a fortune to be prototyped. Hence software simulation or theory is vital. Software engineering has for long misconstrued engineering to be itself design. This has what added to the big percentage of the software project failures. regards srinidhi --- "Scott W. Ambler" <[EMAIL PROTECTED]> wrote: > You realize of course that Zachman's theories, note > the use of the term > theories, are based outside of the software > development world. I'm not sure > that there are any documented success stories using > his framework. I could > be wrong about that, but I doubt it. > > - Scott > ----- Original Message ----- > From: "Srinidhi Boray" <[EMAIL PROTECTED]> > To: "Baynes, Steve" <[EMAIL PROTECTED]>; > "Lyalin, David S." > <[EMAIL PROTECTED]>; "'[EMAIL PROTECTED]'" > <[EMAIL PROTECTED]> > Cc: "Brian McCarthy" <[EMAIL PROTECTED]>; > "'Richard A. Menard'" > <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Sent: Thursday, September 19, 2002 11:40 AM > Subject: (RUP) RE: (ROSE) Process Modelling? > > > > Hi, > > > > Sorry if I did come across bit rudely. Anyway, > heat is > > what that helps evolution. > > > > Find attached article from Zachman on enterprise > > architecture/modeling. I guess It should be very > > interesting area for all business modelers. > > > > rgds > > srinidhi > > > > > > --- "Baynes, Steve" <[EMAIL PROTECTED]> > wrote: > > > Hi all, I can see this thread becoming very > > > interesting and, possibly, quite > > > heated (heated occurs as I write)! So before > that > > > happens here is my view > > > point... > > > > > > Process Modelling - what are we trying to > achieve. > > > > > > The aim of modelling is quite simple (in my > opinion) > > > - it allows us to > > > "share complex information". How many > architects > > > selling a building idea do > > > not provide a mock-up model (none, I would > suggest > > > because the mock-up model > > > is a very effective method of conveying complex > > > information (i.e. the > > > architectural diagrams, another form of model). > If > > > the model can be > > > interactive so much the better but its value is > > > allowing us to share the > > > complex information (having spent many an hour > > > completing the information > > > necessary to generate interactive Casewise > models I > > > can assure everyone > > > interactively modelling the simple is not worth > the > > > effort). > > > > > > So the aim of a model is to share complex > > > information. This means diagrams > > > are a very good modelling tool (they are just > not > > > interactive). UML is a > > > very good modelling language as everyone > > > "understands" what it means. > > > > > > One other thought - the model must be targeted > at > > > the audience. Presenting > > > the UML model to the executive board is a very > good > > > way to get fired. > > > > > > I hope this does not add to much fat to the fire > > > > > > Regards > > > Stephen Baynes > > > > > > -----Original Message----- > > > From: Srinidhi Boray [mailto:[EMAIL PROTECTED]] > > > Sent: 19 September 2002 15:13 > > > To: Lyalin, David S.; '[EMAIL PROTECTED]' > > > Cc: 'Srinidhi Boray'; Brian McCarthy; 'Richard > A. > > > Menard'; > > > [EMAIL PROTECTED]; Lyalin, David S. > > > Subject: RE: (ROSE) Process Modeling? > > > > > > > > > > > > Hello David, > > > > > > Sorry, I have to deny you to employ into > > > professional > > > practice the common sense (wrt 'modeling') that > you > > > intend to think that it is. Instead, I prefer to > > > offer > > > you following observation which may help you to > > > discern better the concepts of modeling. > > > > > > 1. Diagram is not a model. A model is a model is > a > > > model. Diagram is a mere depiction of one > instance > > > or > > > one perspective of a model. Several diagrams > > > combined > > > together attempts to capture the whole truth of > a > > > model. Yet it fails. > > > > > > 2. Strong notations are required to be followed > > > while > > > modeling, to maintain and retain the model > > > integrity. > > > Else spurious elements creep in during modeling > and > > > become demonic during the implementation stage. > Slay > > > the demon when it is young. Any vanity provides > room > > > for the demon to creep in. A good modeler in a > > > disciplined way keeps out all cosmetic attempts. > > > > > > 3. Model is not to appease client. Model is to > > > assist > > > as a cohesive thinking artifact based on which > > > productive collaborative actions can be planned. > So, > > > models must be objective and clear in nature. > > > Beauticians to be kept out. > > > > > > 4. Last but not the least Happiness is not in > > > avoiding > > > problem or in sublimating (with fancy notations > :)) > > > )them. It is in solving them. Bottom line > ...client > > > wants solution and not fancy diagrams to hang on > > > their > > > walls.. > > > > > > cheers > > > srinidhi > > > > > > > > > > > > > > > > Good morning, > > > > > > > > I'd like to put these "process modeling" > things in > > > a > > > > "common sense" > > > > perspective. > > > > Let me start from the quote: > > > > "Any diagram is intimidating to the > uninitiated, > > > so > > > > it is extremely > > > > important that the diagram is as attractive as > > > > possible and that it conveys > > > > the sense of what is to be communicated. Of > > > course, > > > > this (primarily) > > > > requires skill on the part of the diagrammer." > > > > http://www.BRCommunity.com/a2002/b117.html (It > is > > > > interesting, that the > > > > author of this quotation is strongly against > UML). > > > > Common sense should prevail. Show to me any > model > > > of > > > > the business process, > > > > and I will show to you how to built it with > UML > > > > instruments (diagrams and > > > > use cases). Rose and ReqPro quite sufficient > for > > > > business process modeling. > > > > The only thing they would not do for you is a > > > > process simulation (if you > > > > ever need it). The rest is just usual > > > > groups-interest-serving dogs struggle > === message truncated === __________________________________________________ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com ************************************************************************ * Rose Forum is a public venue for ideas and discussions. * For technical support, visit http://www.rational.com/support * * Post or Reply to: [EMAIL PROTECTED] * Subscription Requests: [EMAIL PROTECTED] * Archive of messages: * http://www.rational.com/support/usergroups/rose/rose_forum.jsp * Other Requests: [EMAIL PROTECTED] * * To unsubscribe from the list, please send email * To: [EMAIL PROTECTED] * Subject: <BLANK> * Body: unsubscribe rose_forum *************************************************************************
