A. Wayne Wymore
Albert Wayne Wymore (February 1, 1927 – February 24, 2011) was an American mathematician, systems engineer, Professor Emeritus of Systems and Industrial Engineering of the University of Arizona, and one of the founding fathers of systems engineering.
- [The process of system design is]... consisting of the development of a sequence of mathematical models of systems, each one more detailed than the last.
- A. Wayne Wymore (1970) Systems Engineering Methodology. Department of Systems Engineering, The University of Arizona, p. 14/2; As cited in: J.C. Heckman (1973) Locating traveler support facilities along the interstate system--a simulation using general systems theory. p. 43.
- [The word system is often defined in a way] that seems the most appropriate for the purpose of any given discussion.
- A. Wayne Wymore (1972) Systems Engineering Methodology for Interdisciplinary Teams. Department of Systems Engineering, The University of Arizona; As cited in: J.C. Heckman (1973, p. 39).
- The problem of the design of a system must be stated strictly in terms of its requirements, not in terms of a solution or a class of solutions.
- A Wayne. Wymore (2004) "The nature of research in systems engineering"; As cited in: Eric David Smith (2006) Tradeoff Studies and Cognitive Biases. p. 31.
A Mathematical Theory of Systems Engineering (1967)
A. Wayne Wymore (1967) A Mathematical Theory of Systems Engineering.
- Every author has several motivations for writing, and authors of technical books always have, as one motivation, the personal need to understand; that is, they write because they want to learn, or to understand a phenomenon, or to think through a set of ideas.
- p. v;
- If all the theories pertinent to systems engineering could be discussed within a common framework by means of a standard set of nomenclature and definitions, many separate courses might not be required.
- p. vi; cited in: Jack Murph Pollin (1969) Theoretical Foundations for Analysis of Teleological Systems. p. 63.
- Only if mathematical rigor is adhered to, can systems problems be dealt with effectively, and so it is that the systems engineer must, at least, develop an appreciation for mathematical rigor if not also considerable mathematical competence.
- p. 3.
- All that can be done pedagogically is to show the student how some phenomena have been modeled, let him model some phenomena under supervision, and then hope he will be successful on his own—or know enough to secure assistance.
- p. 68 About the teaching of modeling: As cited in: J.C. Heckman (1973, p. 5)".
- In the minds of many writers systems engineering is synonomous with component selection and interface design; that is, the systems engineer does not design hardware but decides what types of existing hardware shall be coupled and how they shall be coupled. Complete agreement that this function is the essence of systems engineering will not be found here, for, besides the very important function of systems engineering in systems analysis, there is the role played by systems engineering in providing boundary conditions for hardware design.
- p. 193.
Engineering Modeling and Design (1992)
Chapman, Bahill and Wymore (1992) Engineering Modeling and Design.
- Over 80 million people have participated in Cub Scout Pinewood Derbies. Pinewood is a case study of the design of a Cub Scout Pinewood Derby for one particular scout pack. The system helps manage the entire race from initial entry through final results. Many alternatives for race format, scoring, and judging are presented.
- p. 83; As cited in: Eric David Smith (2006, p. 42).
Systems Movement: Autobiographical Retrospectives (2004)
A. Wayne Wymore (2004) in: "Systems Movement: Autobiographical Retrospectives". In: International Journal of General Systems, Vol. 33, No. 6, December 2004, pages 593-610.
- After earning the PhD degree and acquiring some relatively extensive experience in digital computers… It was time to leave the University. The result of an extensive search for the right job was a family move to Arlington Heights, Illinois, where it was a short commute to the Research Laboratories of the Pure Oil Company at Crystal Lake. I was given the title of Mathematical and Computer Consultant. The Labs were set in a beautiful campus, the professional personnel were eager to learn what I had to teach and to include me in many interesting projects where my knowledge and skills could be put to good use. I was encouraged to initiate my own program of research. I went to work with enthusiasm.
The corporate headquarters of Pure Oil were located in down town Chicago. Pure Oil had been trying to install an IBM 705 computer system for all their accounting needs including calculation of all data necessary for the management of exploration, drilling, refining and distribution of oil products and even royalties to shareholders in oil wells. Typical for those early days, the programming team was in deep difficulties and needed help; they lacked adequate resources and suitable training. The Executive Vice President of Pure Oil, when he heard that there was a computer expert already on the payroll at the Crystal Lake lab, ended our family blissful dream and I was reassigned to the down town office.
- During this period I was able to carry out only one project of real interest to me. Pure Oil was a fully integrated oil company in the sense that they engaged in exploration for oil, construction of oil wells, production of crude oil, transportation to refineries, distribution of refinery products to company owned storage facilities and to gas stations. We developed a linear programming model of the whole network hoping to discover the optimum allocation to and from connected nodes in order to meet required deliveries at minimum cost. Then we collected all the data needed by our model and ran the model. The computations took several days and the results were disappointing: The optimum allocations were not significantly different from their current practices. Is it possible that we had discovered a system of human beings in which everyone knew the payoff functions and constraints, and, over time, had evolved behavior patterns that enabled them to achieve near optimum performance? Or was it possible that our model was not detailed enough as it was based so closely on current practice that no new behavior could emerge? Or was our data incorrect? This was disappointing but great experience.
- [In the year 1957] I have just returned from an exciting meeting of the American Society for Engineering Education where I heard a paper on the new discipline of systems engineering. It is no longer sufficient for engineers merely to design boxes such as computers with the expectation that they would become components of larger, more complex systems. That is wasteful because frequently the box component is a bad fit in the system and has to be redesigned or worse, can lead to system failure. We must learn how to design large-scale, complex systems from the top down so that the specification for each component is derivable from the requirements for the overall system. We must also take a much larger view of systems. We must design the man-machine interfaces and even the system-society interfaces. Systems engineers must be trained for the design of large-scale, complex, man-machine-social systems.
- In the folklore of systems engineering, there are sayings, “If it isn't testable, it isn't a requirement,” and, “If it is not quantifiable, it is not testable.” I had always tended to subscribe to the particle of wisdom in these sayings. One of the many lessons that I learned from the CATIE experience, however, was that systems engineering had to be able to deal directly and purposively with what are usually considered to be strictly qualitative (unquantifiable) aspect of systems, such as quality of life, for example. The agricultural practices of these small farmers in Central America is such a large part of their lives that to change any part of their agricultural practices might be seen as diminishing their quality of life - even with respect to the color of the beans that the new practices might require. But even if we cannot deal directly with quality of life or user friendliness or enmity/sympathy, we can identify quantifiable figures of merit relating to these qualitative aspects and if we find enough figures of merit and combine them suitably, we might eventually obtain agreement that we have captured the essence of the qualitative aspect, at least as far as this particular set of stakeholders is concerned.
Quotes about A. Wayne Wymore
- General systems theory is considered as a formal theory (Mesarovic, Wymore), a methodology (Ashby, Klir), a way of thinking (Bertalanffy, Churchman), a way of looking at the world (Weinberg), a search for an optimal simplification (Ashby, Weinberg), didactic method (Boulding, Klir, Weinberg), metalanguage (Logren), and profession (Klir).
- George Klir cited in: James T. Ziegenfuss (1983) Patients' rights and organizational models: sociotechnical systems research on mental health programs. p. 104.
- Wayne Wymore is now well established as an important leader in systems engineering and a founder of a highly original "school of thought" in the area of systems design. His contribution to this area, which will be the subject of a special issue of this journal in the near future, is best exposed in a trilogy consisting of this book and its two predecessors [Wymore, 1967, 1976]. Wymore's approach to systems design is characterized by mathematical rigor, comprehensiveness, and broad applicability.
- George Klir (1996) "Review of Model-Based Systems Engineering", in the International Journal of General Systems, Vol 25 (2). p. 179.
- A. Wayne Wymore founded the first academic department of Systems Engineering in the world at the University of Arizona in 1960. He pioneered Mathematical-based Systems Engineering and later led Model-based Systems Engineering. He was an early and ardent supporter of the fomenting of INCOSE. He has led self-evaluation of Systems Engineering education, and continues to be one of the most prominent theoreticians of the Systems Engineering community. In addition to his teaching, writing, and consulting, he has participated in pro bono projects to bring a Systems Engineering approach to social service organizations.
- System design can be requirements based, function based, or model based. Model based system engineering and design has an advantage of executable models that improve efficiency and rigor. One of the earliest developments of this technique was Wymore’s (1993) book entitled Model-based System Engineering, although the phrase “model-based system design” was in the title and topics of Rosenblit’s (1985) PhD dissertation. Model-based systems engineering depends on having and using well-structured models that are appropriate for the given problem domain.
- A. Terry Bahill, Rick Botta (2008) "Fundamental Principles of Good System Design" Engineering Management Journal Vol. 20 No. 4. p. 9.
- Wayne’s book, A Mathematical Theory of Systems Engineering: The Elements, John Wiley, New York  appeared in an era that spawned the concept of a mathematical system as a generalization of the control systems of engineers and the automata theories of computer scientists. Wymore employed the unusual term “Tricotyledon Theory of System Design” to portray the tri-partite nature of his theory. Tricotyledon, or three leaved seed, pictures a leaf for the class of models of the behavior of the system being designed, a second leaf for the technologies that are available to implement the system, and a leaf for the intersection of the two previous classes, namely, the technologies that can implement the models according to specified evaluation criteria. In subsequent work over three decades, he deepened the theory and applied it to numerous system engineering problems. The theory became the basis for his book, Model-based System Engineering, CRC Press, Inc. Boca Raton, FL, USA © 1993 and helped to spawn the trend toward use of systems modeling tools for systems design. However, Wayne himself did not emphasize the use of modeling and simulation as essential tools in systems engineering practice.