As to usage of the Zachman Framework, I understand that at least two major computer services companies use variants of the Zachman Framework when developing proposals for outsource contracts. That's how I came across the technique. I imagine that it is used in a very lightweight manner in this context.
I've not seen much on its usage documented in the (academic) literature. There is Melissa Cook's book, (Cook 1996), but this does not provide Case Studies or examples. On the other hand, some authors have suggested that difficulties in implementing Enterprise Integration Architectures may have led to the interest in ERP systems (Kumar and Hillegersberg 2000). Would this suggest, based on very scanty evidence admittedly, that it is the scale of the problem of integrating some Enterprise Architectures that implies large amounts of modelling (and the problems that would bring in its wake) and ZF is merely reflecting this 'need'? Paul Cook, M. A. (1996). Building Enterprise Information Architectures. Upper Saddle River, NJ, Prentice-Hall. Kumar, K. and J. V. Hillegersberg (2000). "ERP, Experiences and evolution." Communications of the ACM 42(4): 23-26. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Scott W. Ambler Sent: 23 September 2002 11:55 To: Srinidhi Boray; '[EMAIL PROTECTED]'; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Zachman was Re: (RUP) RE: (ROSE) Process Modelling? Answering several messages at once.... ----- Original Message ----- From: "Srinidhi Boray" <[EMAIL PROTECTED]> <snip> > > 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. Modeling can definitely help, it is one way to think something through before you build it, but excessive modeling is a hindrance. The Zachman Framework (ZF) motivates excessive modeling, IMHO. > > 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. These are good things to do, but the ZF is very likely overkill for 95% (or more) of all situations. > > 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. Yes, your systems should reflect the business processes that they are supposed to support. > > When fool proof in theory then it is certain to work > in practice. Absolutely not. Have you actually implemented the ZF in the real world? I bet not. I highly suspect that you're pontificating about something you haven't even tried. This is spectacularly dangerous -- everything works on a presentation slide. It is because of exactly this problem that the RUP insists that you first build an end-to-end prototype of a system during the Elaboration phase. The prototype enables you to determine if the theory actually works in practice. I highly suggest that you take the same approach with the ZF theory first. Were you to do this I highly suspect that you'll discover it is little more than a paper pushing endeavor, that your enterprise architects will be all but ignored. I'm a big fan of including enterprise architecture efforts into the RUP, as the EUP (www.ronin-intl.com/publications/unifiedProcess.html) attests, but I just don't think that the ZF has much to offer practitioners. > 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. That's because the cost of (re)development and (re)deployment is typically very high in these environments. This isn't the case in software development, or at least shouldn't be if you haven't created a spectacularly inefficient process to follow. Just because a technique works well in one environment doesn't mean it works well in others. The ZF comes from an environment where cost of change is spectacularly high. This isn't the case in software development (or at least doesn't have to be). > Especially in VLSI design, each > chip costs a fortune to be prototyped. Hence software > simulation or theory is vital. Then if that is what you're doing then you should simulate. Use the right approach for the job. > Software engineering > has for long misconstrued engineering to be itself > design. This has what added to the big percentage of > the software project failures. Really? I'm not sure what you're getting at with the first sentence. Do you have any data supporting the second? <snip> ===================================================== From: "Burk, Susan" <[EMAIL PROTECTED]> > 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." There's definitely some value to this. I refer to the ZF as well from time to time. The idea of several views is important, something that I try to hammer home with AM's principle of Multiple Models (www.agilemodeling.com/principles.htm#MultipleModels), as is the various levels of abstraction. I just get very worried when someone comes along and wants to create a set of models for each and every cell. That's just a lot of needless paperwork for the vast, vast, vast majority of organizations. Sue, you've clearly found a way in practice to benefit from some of the theory. This gets back to my prototyping analogy earlier -- you need to prove the theories in practice first. When you do this you quickly discover what works and what doesn't. > > 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. Zachman doesn't actually enforce specific artifacts, unless something has changed recently that I don't know about, for the individual cells. Unfortunately the first column is labeled "Data" and the data community has gravitated towards their preferred collection of artifacts (logical data models, ...) as you'd expect. As Tasker points out, the ZF is flexible in that manner. I'd argue that he's chosen to follow the AM practice Apply the Right Artifact (www.agilemodeling.com/practices.htm#ApplyTheRightArtifact). > > 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). You probably could. The list of artifacts is posted at www.agilemodeling.com/essays/modelingTechniques.htm. Once again, Apply the Right Artifact(s) and choose the one that's most appropriate for your situation. > > 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. I suspect that's because of two issues: 1. The UML is not complete. See www.agilemodeling.com/essays/realisticUML.htm for thoughts on that, and the list of modeling techniques linked to above for a few suggestions. For example, data modeling and user interface modeling are not (yet) parts of the official UML (something that I first pointed out in the October 1997 issue of Object Magazine) and when was the last time you built a business application without a UI or data storage? 2. The RUP isn't complete either. It's pretty good, but no process can be "complete". <snip> From: "Ng, Pan Wei" <[EMAIL PROTECTED]> <snip> > 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. > It does talk about both the RUP and the UML. Yes, there's more mapping of the UML to the ZF than RUP to the ZF but that makes sense to me. I think the article may also be suffering from a common problem in the industry of people misconstruing the relationship between the RUP and the UML. Sigh. <snip> - Scott ===================================================== Scott W. Ambler [EMAIL PROTECTED] Senior Consultant, Ronin International, Inc. http://www.ronin-intl.com/company/scottAmbler.html ************************************************************************ * 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 *************************************************************************
