Hi,
As I read http://www.intelligententerprise.com/010416/metaprise1_1.shtml, I can see that the author is mapping Zachman FW to UML as opposed to RUP. Cheers -- Pan-Wei Ng -----Original Message----- From: Courtney, Sam [mailto:[EMAIL PROTECTED]] Sent: 21 September 2002 05:36 To: Burk, Susan; 'Scott W. Ambler'; Srinidhi Boray; Baynes, Steve; Lyalin, David S.; '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]' Cc: Brian McCarthy; 'Richard A. Menard'; [EMAIL PROTECTED] Subject: RE: Zachman was Re: (RUP) RE: (ROSE) Process Modeling? There was a very good webinar yesterday on Enterprise Architectures, and it had a slide on mapping RUP artifacts to the Zachman FW. It is not in the archives yet but I'm sure it will be next week sometime. It is worth a quick peruse if you did not see it yesterday. In addition, see this link for article from 4/2001 on the RUP and the Zachman FW: http://www.intelligententerprise.com/010416/metaprise1_1.shtml Sam Sam Courtney Rational Software Software Engineering Specialist Dallas, TX Office: 972-492-5753 Tech Support: 1-800-433-5444 [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> Upcoming Webinars: http://www.rational.com/events/webinars/search.jsp -----Original Message----- From: Burk, Susan [mailto:[EMAIL PROTECTED]] Sent: Friday, September 20, 2002 2:11 PM To: 'Scott W. Ambler'; Srinidhi Boray; Baynes, Steve; Lyalin, David S.; '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]' Cc: Brian McCarthy; 'Richard A. Menard'; [EMAIL PROTECTED] Subject: RE: Zachman was Re: (RUP) RE: (ROSE) Process Modeling? Another thought: I think there is another way to view Zachman's accomplishment: What the Zachman framework provides is a way to present - on one page! - a best practices approach for the kinds of artifacts to use for communication during software development. Additionally, the Zachman Framework addresses the level of thinking that is needed at different points in a software development lifecycle; some projects may not need documents for all 36 cells, but most projects will need to think through all 36. It recognizes that different artifacts and thought-processes appeal to different audiences and cover different aspects of understanding the software problem and solution space. I - and many others - have improved communication between parties just by being able to point to two cells in the framework, in a non-threatening way ::~) - "you think you are talking this cell, but you are actually talking about this other cell." I've also found I have been able to continue to successfully communicate with it as I have moved from data-centered techniques to OO techniques and component-based techniques. With one notable exception, the implementation-independent aspects of the first two rows of the framework have not changed as I moved to OO and components, even though I use different artifacts for them, and sometimes think through an aspect without any formal documentation. I think that the notion of considering data and process as separate aspects (columns) is a big risk in the OO and component arenas, at least until design time, when a relational database may be used to persist the "types" or classes. So, I've adopted an idea first presented by Dan Tasker (which I believe Dan no longer uses): the columns of the framework should be Objects (data+process), Events, Participants, Locations, and Rules. I have had a lot of success with those columns on OO and component-based projects, and with the notion that there are confirmation techniques which may span columns. Although I have not had the time to do it, I believe that Scott's excellent list of artifacts which he has on his website could be compartmentalized within the Zachman framework. BellSouth and Tom Vayda once created a 15 column matrix for OO and component development - some of the additional columns which they added looked a lot like the bottom rows of RUP (Project Management, Change Management, and others). There have been several attempts to lay UML workproducts - and even RUP - against the Zachman framework. Some of these are available in the Rational Edge or in the whitepapers; others have been presented at data-centered professional conferences. I've never been totally satisfied with what I have seen out of those efforts, but I do think that the concept of a one-page view of what it takes to develop software is a powerful one. Sue Burk -----Original Message----- From: Scott W. Ambler [mailto:[EMAIL PROTECTED]] Sent: Friday, September 20, 2002 1:57 PM To: Srinidhi Boray; Baynes, Steve; Lyalin, David S.; '[EMAIL PROTECTED]' Cc: Brian McCarthy; 'Richard A. Menard'; [EMAIL PROTECTED] Subject: Zachman was Re: (RUP) RE: (ROSE) Process Modelling? 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 > > > under the rug. And if you would like your business > > > clients to like your > > > diagrams - develop your diagramming skills and > > build > > > a good ones (see > > > quotation above). Otherwise, no tool and no > > notation > > > will ever help ... > > > > > > Happy modeling. > > > > > > David Lyalin > > > > > > > > > -----Original Message----- > > > From: Srinidhi Boray [mailto:[EMAIL PROTECTED]] > > > Sent: Wednesday, September 18, 2002 5:22 PM > > > To: Brian McCarthy; 'Richard A. Menard' > > > Cc: '[EMAIL PROTECTED]' > > > Subject: RE: (ROSE) Process Modeling? > > > > > > > > > > > > Hi, > > > > > > To add to the muddle!!! Every time I hear process analysis, > > > process modeling etc and anything > > related > > > to > > > processes, I realize that what one is really > > talking > > > about is 'one instance' of the processes. If one > > > intends to model one instance of a process then > > one > > > may choose whatever on earth to depict pictorially > > > that instance. Process modeling is lot more than > > > mere > > > representation as a 2d diagram. Process model is > > > manifold more than just a mere event flow diagram. Process model > > > is a depiction of the dynamic functioning of an enterprise as a > > > cumulation of several processes utilizing numerous resources and > > > horizontally streaking through organized set of > > > functional units and each achieving a specific set > > > of > > > business objective and adding up to fulfill the > > > bigger > > > business goal. By employing the resources various > > > constraints are overcome. Business goals are > > always > > > accompanied by problems/constraints. The process > > > model > > > depicting the whole truth of an enterprise results > > > into a matrix set of resources and each uniquely > > > aiding in the efficient flow of the events (or > > > threads > > > of processes), overcoming problems as much as > > > possible. To model such a process flow more > > holistic > > > tools such as those based on Enterprise > > Architecture > > > framework such as Zachman is required. Rose at the > > > moment does not offer such a facility and it is > > > severely lacking in capacity to capture the > > > enterprise > > > architecture as a holistic relational model. > > > > > > === message truncated === > > > > __________________________________________________ > Do you Yahoo!? > New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com > > **************************************************************************** ***** * RUP Forum is a public venue for discussions about the * Rational Unified Process (RUP). * * For RUP support materials, process Plug-Ins, tutorials, whitepapers, * a biweekly column, Rational University training courses, and more, * please visit the Rational Developer Network (available to Rational * customers) at: http://www.rational.net. * * For technical support of RUP, RPW, Rose or any other Rational * product, please visit: http://www.rational.com/support * * For other discussion groups, such as Rose and UML, please * sign up at: http://www.rational.com/support/usergroups/index.jsp * * To reply to a posting, please "Reply to all" or send * To: [EMAIL PROTECTED] * * Admin.Subscription Requests: [EMAIL PROTECTED] * * Other Requests: [EMAIL PROTECTED] * * To unsubscribe from the list, please send an email: * * To: [EMAIL PROTECTED] * Subject:<BLANK> * Body: unsubscribe rup_forum * **************************************************************************** ---------------------------------------------------------------------------- -- This e-mail transmission may contain information that is proprietary, privileged and/or confidential and is intended exclusively for the person(s) to whom it is addressed. Any use, copying, retention or disclosure by any person other than the intended recipient or the intended recipient's designees is strictly prohibited. If you have received this message in error, please notify the sender immediately by return e-mail and delete all copies. ============================================================================ == **************************************************************************** ***** * RUP Forum is a public venue for discussions about the * Rational Unified Process (RUP). * * For RUP support materials, process Plug-Ins, tutorials, whitepapers, * a biweekly column, Rational University training courses, and more, * please visit the Rational Developer Network (available to Rational * customers) at: http://www.rational.net. * * For technical support of RUP, RPW, Rose or any other Rational * product, please visit: http://www.rational.com/support * * For other discussion groups, such as Rose and UML, please * sign up at: http://www.rational.com/support/usergroups/index.jsp * * To reply to a posting, please "Reply to all" or send * To: [EMAIL PROTECTED] * * Admin.Subscription Requests: [EMAIL PROTECTED] * * Other Requests: [EMAIL PROTECTED] * * To unsubscribe from the list, please send an email: * * To: [EMAIL PROTECTED] * Subject:<BLANK> * Body: unsubscribe rup_forum * **************************************************************************** ************************************************************************ * 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 ************************************************************************* ************************************************************************ * 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 *************************************************************************
