First Quote Added
April 10, 2026
Latest Quote Added
"The enterprise engineer must be a leader, a designer, and a synthesizer. He is a doer. He understands theory as a guide to practice. He must concern himself with human organization because the pace and success of technology are becoming more dependent on interaction with the social system and less on scientific discovery. In private as well as public research and development, such men must find ways to reverse the deterioration of ethics and efficiency. They will strengthen the information links between physical design and the public so that technology can better serve society. In the public sector they must show the level of wisdom and leadership that can co-ordinate great engineering projects with politics. They will recognise that informing the public and becoming a nucleus for crystallising public opinion is even more important in many programmes than is the underlying science."
"In concept a feedback system is a closed system. Its dynamic behavior arises within its internal structure. Any action which is essential to the behavior of the mode being investigated must be included inside the system boundary."
"Formulating a model of a system should start from the question “Where is the boundary, that encompasses the smallest number of components, within which the dynamic behavior under study is generated?”"
"In complex systems cause and effect are often not closely related in either time or space. The structure of a complex system is not a simple feedback loop where one system state dominates the behavior. The complex system has a multiplicity of interacting feedback loops. Its internal rates of flow are controlled by nonlinear relationships. The complex system is of high order, meaning that there are many system states (or levels). It usually contains positive-feedback loops describing growth processes as well as negative, goal-seeking loops. In the complex system the cause of a difficulty may lie far back in time from the symptoms, or in a completely different and remote part of the system. In fact, causes are usually found, not in prior events, but in the structure and policies of the system."
"The strongest criticism has come from some economists. The objections range from simple misunderstanding, through belief that essential structures have been omitted from the world model, to concern over the costs and feasibility of halting economic growth. Although there is a basis for the criticisms, they have not had sufficient substance to dismiss the central issues. The debate seems to be gradually moving away from the question of whether or not industrial growth must slow to the question of what strategy should be used to limit growth. The latter question, however, remains unanswered."
"In spite of the tentative nature of the world model described here, various conclusions are drawn from it. Man acts at all times on the models he has available. Mental images are models. We are now using those mental models as a basis for action. Anyone who proposes a policy, law, or course of action is doing so on the basis of the model in which he, at that time, has the greatest confidence. Having defined with care the model contained herein, and having examined its dynamic behavior and implications, I have greater confidence in this world system model than in others that I now have available. Therefore, this is the model I should use for recommending actions. Those others who find this model more persuasive than the one they are now using presumably will wish to employ it until a better model becomes available."
"It is to be hoped that those who believe they already have some different model that is more valid will present it in the same explicit detail, so that its assumptions and consequences can be examined and compared. To reject this model because of its shortcomings without offering concrete and tangible alternatives would be equivalent to asking that time be stopped. But the world will continue to turn. We always use the most acceptable model at any point in time. But how should we proceed so that the most acceptable model is also the best one that is available? We should try for three things. First, the best existing model should be identified at each point in time. Second, the best currently existing model should be used in preference to traditional models that may be less clear and less correct. Third, aggressive effort should be devoted to a continual improvement in the available models of the world system."
"It seems traditional for explicit models of social systems to be greeted by vague criticisms about their lack of perfection. Instead, we need equally explicit alternatives with a demonstration that the alternative leads to a different and more plausible set of conclusions. By proposal and counter proposition our understanding of social systems can advance."
"There may be no realistic hope of the present underdeveloped countries reaching the standard of living demonstrated by the present industrialized nations. The pollution and natural-resource load placed on the world environmental system by each person in an advanced country is probably 20 to 50 times greater than the load now generated by a person in an underdeveloped country. With 4 times as many people in the underdeveloped countries as in the present developed countries, their rising to the economic level that has been set as a standard by the industrialized nations could mean an increase of 10 times in the natural-resource and pollution load on the world environment. Noting the destruction that has already occurred on land, in the air, and especially in the oceans, capability appears not to exist for handling such a rise in standard of living. In fact, the present disparity between the developed and underdeveloped nations may be equalized as much by a decline in the developed countries as by an improvement in the underdeveloped countries."
"Mesarovic and Pestel are critical of the Forrester-Meadows world view, which is that of a homogeneous system with a fully predetermined evolution in time once the initial conditions are specified."
"Another tradition in systems theory, known as system dynamics, originated at Massachusetts Institute of Technology. The founder of this tradition was Jay Forrester, a creative engineer who invented the magnetic core memory for computers and who built the , which is now in the Smithsonian Institution."
"At the heart of the book are the functional areas of an industrial firm. Although the data structures are thereby designed according to functional area the integration principle of supra-functional processing of tasks occupies the foreground. This book aims to achieve both a scientifically-based procedural method and a practically relevant, tried and tested approach. The author's experience of developing and introducing integrated information systems in several large industrial firms is incorporated in the treatment presented."
"The creation and implementation of integrated information systems involves a variety of collaborators including people from specialist departments, informatics, external advisers and manufacturers. They need clear rules and limits within which they can process their individual sub-tasks, in order to ensure the logical consistency of the entire project. Therefore, an architecture needs to be established to determine the components that make up the information system and the methods to be used to describe it. The ARIS architecture developed in this book is described in concrete terms as an information model within the entity-relationship approach. This information model provides the basis for the systematic and rational application of methods in the development of information systems. It also serves as the basis for a repository in which the enterprise's application - specific data, organization and function models can be stored. The ARIS architecture constitutes a framework in which integrated applications systems can be developed, optimized and converted into EDP - technical implementations. At the same time, it demonstrates how business economics can examine and analyze information systems in order to translate their contents into EDP-suitable form."
"Business information systems can be either designed as custom applications or purchased as off-the-shelf standard solutions. The development of custom applications is generally expensive and is often plagued by uncertainties, such as the selection of appropriate development tools, the duration of the development cycle, or the difficulties involved in assessing costs. Thus, empirical surveys have shown that between half to two-thirds of information systems projects fail. The current tendency to shift from individual development to standardized, prepackaged software solutions is therefore not surprising."
"There are two fundamental ways of (re-)engineering information systems. The “formal driven” approach is based on the goal of developing and implementing a technical correct running system. The “content driven” approach is based on the goal of developing and implementing an organizational correct running system. By using reference models, content and technology can be combined in a new way"
"Business process engineering aims to achieve the greatest efficiency possible in terms of business-organizational solutions. Organizational departments, reengineering project teams or even business process owners can be responsible for process engineering. While work schedule development for manufacturing processes might be institutionally allocated to a certain department for years as job preparation, other kinds of business processes are not quite as regimented."
"Reference models can be quite comprehensive, consisting of hundreds or thousands of model objects. This is why various levels of aggregation are used. Reference models provide enterprises with an initial process engineering solution, letting them determine the degree of detail of the model and the business content."
"When software applications became larger and larger, people such as Shaw and Garlan coined the term software architecture. This notion of architecture deals with the key design principles underlying software artefacts. In the 1980s and 1990s, people became aware that the development of information technology (IT) should be done in conjunction with the development of the context in which it was used. This led to the identification of the so-called business/IT alignment problem. Solving the business/IT alignment problem requires enterprises to align human, organizational, informational, and technological aspects of systems. Quite early on, the term architecture was also introduced as a means to further alignment, and thus analyzes and solves business?IT alignment problems, Recently, the awareness emerged that alignment between business an IT is not enough, there are many more aspects in the enterprise in need of alignment. This has led to the use of the term architecture at the enterprise level: enterprise architecture."
"Enterprise engineering is an emerging discipline that studies enterprises from an engineering perspective. The first paradigm of this discipline is that enterprises are purposefully designed and implemented systems. Consequently, they can be re-designed and re-implemented if there is a need for change. The second paradigm of enterprise engineering is that enterprises are social systems. This means that the system elements are social individuals, and that the essence of an enterprise's operation lies in the entering into and complying with commitments between these social individuals."
"Enterprise engineering is rooted in both the organizational sciences and the information system sciences. In our current understanding, three concepts are paramount to the theoretical and practical pursuit of enterprise engineering: enterprise ontology, enterprise architecture, and enterprise governance."
"The is about those methods, models and tools which are needed to build the integrated enterprise. The architecture is generic because it applies to most, potentially all types of enterprise. The coverage of the framework spans Products, Enterprises, Enterprise Integration and Strategic Enterprise Management, with the emphasis being on the middle two. The proposal for the architecture follows the architecture itself improving the quality of the presentation and of the outcome. De nitions of Generic Enterprise Reference Architecture, Enterprise Engineering/ Integration Methodology, Enterprise Modelling Languages, Enterprise Models, and Enterprise Modules are given. It is proposed how the above could be developed on the basis of previously analysed architectures (and other results too), such as the , the GRAI Integrated Methodology, , and TOVIE."
"Enterprise Engineering is based on the belief that an enterprise, as any other complex system can be designed or improved in an orderly fashion thus giving a better overall result than ad hoc organisation and design."
"Enterprise Engineering is the collection of those tools and methods which one can use to design and continually maintain an enterprise."
"Enterprise architecture (EA) promotes the belief that an enterprise, as a complex system, can be designed or improved in an orderly fashion achieving better overall results than ad-hoc organisation and design. EA is a co-operative effort of designers, analysts and managers and uses enterprise models in the process... enterprise models carry meaning. This resulted in requirements for the enterprise engineering process, which—if not met—can limit the viability of the process. The analysis of the same factors resulted in requirements for improved Enterprise Modelling Tools."
"provides a Reference Architecture (known as the CIMOSA cube) from which particular enterprise architectures can be derived. This Reference Architecture and the associated enterprise modelling framework are based on a set of modelling constructs, or generic building blocks, which altogether form the CIMOSA modelling languages."
"Many fields use patterns in various ways: In music and literature, a pattern is the coherent structure or design of a song or book. In art, a pattern is the composition or plan of a work of graphic or plastic art. In architecture, a pattern is an architectural design or style. In psychology, a pattern is a thinking mechanism that is basic to the brain's operation, helping one to perceive things quickly. In archeology, a pattern is a group of phases having several distinguishing and fundamental features in common. In linguistics, a pattern is the manner in which smaller units of language are grouped into larger units..."
"Archetypes, color, and components will forever change how you build Java models. We build Java models with teams of developers. In our day-to-day mentoring, we develop and try out new ideas and innovations that will help those developers excel at modeling."
"OOA - Object-Oriented Analysis - is based upon concepts that we first learned in kindergarten: objects and attributes, wholes and parts, classes and members."
"The key books about object-oriented graphical modeling languages appeared between 1988 and 1992. Leading figures included Grady Booch [Booch,OOAD]; Peter Coad [Coad, OOA], [Coad, OOD]; Ivar Jacobson (Objectory) [Jacobson, OOSE]; Jim Odell [Odell]; Jim Rumbaugh (OMT) [Rumbaugh, insights], [Rumbaugh, OMT]; Sally Shlaer and Steve Mellor [Shlaer and Mellor, data], [Shlaer and Mellor, states] ; and Rebecca Wirfs-Brock (Responsibility Driven Design) [Wirfs-Brock]."
"The analysis model will not be a reflection of what the problem domain looks like... The reason is simply to get a more maintainable structure where changes will be local and thus manageable. We thus do not model reality as it is, as object orientation is often said to do, but we model the reality as we want to see it and to highlight what is important in our application."
"A is a complete course of events in the system, seen from a user’s perspective."
"The control objects model functionality that is not naturally tied to any other object... We do not believe that the best (most stable) systems are built by only using objects that correspond to real-life entities, something that many other object-oriented analysis and design techniques claim... Behavior that we place in control objects will, in other methods, be distributed over several other objects, making it hard to change this behavior."
"When a user uses the system, she or he will perform a behaviorally related sequence of transactions in a dialogue with the system. We call such a special sequence a use case."
"The (UML) is a general-purpose visual modeling language that is used to specify, visualize, construct, and document the artifacts of a software system. It captures decisions and understanding about systems that must be constructed. It is used to understand, design, browse, configure, maintain, and control information about such systems. It is intended for use with all development methods, lifecycle stages, application domains, and media. The modeling language is intended to unify past experience about modeling techniques and to incorporate current software best practices into a standard approach. UML includes semantic concepts, notation, and guidelines. It has static, dynamic, environmental, and organizational parts. It is intended to be supported by interactive visual modeling tools that have code generators and report writers. The UML specification does not define a standard process but is intended to be useful with an iterative development process. It is intended to support most existing object-oriented development processes."
"People regard their environment in terms of objects. Therefore it is simple to think in the same way when it comes to designing a model."
"A pattern is a fully realized form original, or model accepted or proposed for imitation. With patterns, small piecework is standardized into a larger chunk or unit. Patterns become the building blocks for design and construction. Finding and applying patterns indicates progress in a field of human endeavor."
"Object-oriented methods tend to focus on the lowest-level building block: the class and its objects."
"With each pattern, small piecework is standardized into a larger chunk or unit. Patterns become the building blocks for design and construction. Finding and applying patterns indicates progress in a field of human endeavor."
"Originally UML was intended to serve as a . But a specification is primarily intended to describe properties of systems that the system developers want to be valid, but to leave open other properties that are not clear already. Today this is partly achieved by having a semantics that is rather vague (and here we mean imprecise as opposed to not detailed). However, this is not an advantage, as the developer cannot fix this kind of impreciseness within UML, but can adapt the individual interpretation only. Furthermore, to get complete (and therefore executable) UML descriptions, often certain details have to be specified, which the developer does not yet know or wants to leave open to a later phase of development or even implementation. It is an intrinsic problem of executable languages that this kind of over-specification frequently occurs. Instead it would be of some help to have flexible concepts of under-specification to postpone detail decisions to situations, where the decisions can and must be made."
"Bernhard Rumpe is chair of the Institute for Software Systems Engineering at the Braunschweig University of Technology, Germany. His main interests are software development methods and techniques that benefit form both rigorous and practical approaches. This includes the impact of new technologies such as model-engineering based on UML-like notations and domain specific languages and evolutionary, test-based methods, software architecture as well as the methodical and technical implications of their use in industry. He has furthermore contributed to the communities of formal methods and UML. He is author and editor of eight books and Co-Editor-in-Chief of the Springer International Journal on Software and Systems Modeling."
"The growing complexity of software is the motivation behind work on industrializing software development. In particular, current research in the area of (MDE) is primarily concerned with reducing the gap between problem and software implementation domains through the use of technologies that support systematic transformation of problem-level abstractions to software implementations. The complexity of bridging the gap is tackled through the use of models that describe complex systems at multiple levels of abstraction and from a variety of perspectives, and through automated support for transforming and analyzing models. In the MDE vision of software development, models are the primary artifacts of development and developers rely on computer-based technologies to transform models to running systems."
"Advances in hardware and network technologies have paved the way for the development of increasingly pervasive software-based that collaborate to provide essential services to society. Software in these systems is often required to (1) operate in distributed and embedded computing environments consisting of diverse devices (personal computers, specialized sensors and actuators), (2) communicate using a variety of interaction paradigms (e.g., SOAP messaging, media streaming), (3) dynamically adapt to changes in operating environments, and (4) behave in a dependable manner. Despite significant advances in programming languages and supporting integrated development environments (IDEs), developing these complex software systems using current code-centric technologies requires herculean effort."
"The term (MDE) is typically used to describe software development approaches in which abstract models of software systems are created and systematically transformed to concrete implementations.... Full realizations of the MDE vision may not be possible in the near to medium-term primarily because of the wicked problems involved. On the other hand, attempting to realize the vision will provide insights that can be used to significantly reduce the gap between evolving software complexity and the technologies used to manage complexity."
"One of the distinct features of XP is the lack of any documentation whatsoever, except for the code itself. This is a contraposition to the modeling techniques like the Unified Modeling Language (UML), which strongly focus on documentation. XP takes an extreme position there, not even documenting the architecture of the system. Often, it is very difficult to extract the overall structure, behavior or interactions with the environment from the code. The code is a rather detailed and fragile representation of the system’s tasks. Even though the code contains all necessary information about the system, this information is often burdened with details and it is tedious to extract the aspects one is interested in. Therefore, it would be useful to have a more compact system representation. The UML does provide a number of notations that are suited for this purpose. However, the tools so far are not capable of supporting UML in such a manner that it can be well-integrated with the approach of Extreme Programming."
"In all engineering disciplines nowadays, software engineering excluded, there exists an established engineering process to develop a system, which is accompanied by a number of suited modeling description techniques. Software engineering, being a rather new field, has not as yet established any clear methodical guidance or a fully standardized modeling notation."
"Extreme Programming is the most prominent new, light-weight (or agile) methods, defined to contrast the current heavy-weight and partially overloaded object-oriented methods. It focuses on the core issues of software technology. One of its principles is not to rely on diagrams to document a system."
"Today some evidence arises that UML will more and more be used not as a but as a high level programming language. This has some advantages, as if the concepts of UML are executable, they can immediately be animated and tested, or the generated code even be used as implementation. Thus UML probably will have an implementation-oriented semantics describing this animation."
"My first serious programming work was done in the very early 1960s, in Assembler languages on IBM and Honeywell machines. Although I was a careful designer — drawing meticulous flowcharts before coding — and a conscientious tester, I realised that program design was hard and the results likely to be erroneous. Into the Honeywell programs, which formed a little system for an extremely complex payroll, I wrote some assertions, with run-time tests that halted program execution during production runs. Time constraints didn't allow restarting a run from the beginning of the tape. So for the first few weeks I had the frightening task on several payroll runs of repairing an erroneous program at the operator’s keyboard ¾ correcting an error in the suspended program text, adjusting the local state of the program, and sometimes modifying the current and previous tape records before resuming execution. On the Honeywell 400, all this could be done directly from the console typewriter. After several weeks without halts, there seemed to be no more errors. Before leaving the organisation, I replaced the run-time halts by brief diagnostic messages: not because I was sure all the errors had been found, but simply because there would be no-one to handle a halt if one occurred. An uncorrected error might be repaired by clerical adjustments; a halt in a production run would certainly be disastrous."
"Computers are not very smart. They don't understand human language, so we have to tell them what to do in a language that both humans and computers can understand."