“Every software system needs to have a simple yet powerful organizational philosophy (think of it as the software equivalent of a sound bite that describes the system's architecture)… [A] step in [the] development process is to articulate this architectural framework, so that we might have a stable foundation upon which to evolve the system's function points.”

—  Grady Booch

Source: Object-oriented design: With Applications, (1991), p. 320

Adopted from Wikiquote. Last update June 3, 2021. History

Help us to complete the source, original and additional information

Do you have more details about the quote "Every software system needs to have a simple yet powerful organizational philosophy (think of it as the software equiva…" by Grady Booch?
Grady Booch photo
Grady Booch35
American software engineer 1955

Related quotes

“The software architecture of a system or a family of systems has one of the most significant impacts on the quality of an organization's enterprise architecture. While the design of software systems concentrates on satisfying the functional requirements for a system, the design of the software architecture for systems concentrates on the nonfunctional or quality requirements for systems. These quality requirements are concerns at the enterprise level. The better an organization specifies and characterizes the software architecture for its systems, the better it can characterize and manage its enterprise architecture. By explicitly defining the systems software architectures, an organization will be better able to reflect the priorities and trade-offs that are important to the organization in the software that it builds.”

Scott W. Ambler (1966) Canadian software engineer/consultant/author

James McGovern, Scott W. Ambler and M. E Stevens (2004) A Practical Guide to Enterprise Architecture. p. 35

“Software engineering concerns methods and techniques to develop large software systems. The engineering metaphor is used to emphasize a systematic approach to develop systems that satisfy organizational requirements and constraints.”

Hans van Vliet (1949) Dutch computer scientist

Source: Software Engineering: Principles and Practice, 2007, p. 2

“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.”

Erik Proper (1967) Dutch computer scientist

Martin Op 't Land, Erik Proper (2009) Enterprise Architecture: Creating Value by Informed Governance. p. 26-27

Gerrit Blaauw photo

“The architecture of a system can be defined as the functional appearance of the system to the user.”

Gerrit Blaauw (1924–2018) Dutch computer scientist

Blaauw (1972) cited in: Gerritt A Blaauw (1976) Digital system implementation. p. 6

Barry Boehm photo

“If a project has not achieved a system architecture, including its rationale, the project should not proceed to full-scale system development. Specifying the architecture as a deliverable enables its use throughout the development and maintenance process.”

Barry Boehm (1935) American software engineer

Barry Boehm (1995); quoted in: L. Bass, P. Clements, and R. Kazman (1998) Software Architecture in Practice, Addison Wesley Longman. Chapter 2

August-Wilhelm Scheer photo

“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.”

August-Wilhelm Scheer (1941) German business theorist

August-Wilhelm Scheer, I. Cameron (1992) Architecture of integrated information systems: foundations of enterprise modelling. Abstract.

Ernest Flagg photo

“There have always seemed to the writer sound reasons for using the module system in architectural design.”

Ernest Flagg (1857–1947) American architect

Small Houses: Their Economic Design and Construction (1922), Ch. II

Ed Yourdon photo

“Designed as a companion volume to the acclaimed Object-Oriented Analysis, this book focuses on the middle part of the software lifecycle: the activity of design. It shows readers how to apply object-oriented design, and how to tailor and expand the method to suit specific organization and project needs. Readers will explore the major issues in OOD; the role of OOD in the systems lifecycle; how to use graphical notation; strategies for creating design; and hints for evaluating the efficiency of a design created with OOD. For software engineers and other users undertaking real-world systems development projects and designing overall software architecture for systems will find this reference approach to improving systems design indispensable.”

Ed Yourdon (1944–2016) American software engineer and pioneer in the software engineering methodology

Abstract.
Object-oriented design (1991)

“But how does it come about, step by step, that some complex Systems actually function? This question, to which we as students of General Systemantics attach the highest importance, has not yet yielded to intensive modern methods of investigation and analysis. As of this writing, only a limited and partial breakthrough can be reported, as follows: A COMPLEX SYSTEM THAT WORKS IS INVARIABLY FOUND TO HAVE EVOLVED FROM A SIMPLE SYSTEM THAT WORKED”

John Gall (1925–2014) American physician

Source: Systemantics: the underground text of systems lore, 1986, p. 65 cited in "Quotes from Systemantics – Funny, But Scary Too" Posted on agileadvice.com March 3, 2006 by Mishkin Berteig. This quote was mentioned in General systemantics (1975, p. 71)

Gerrit Blaauw photo

“In computer design three levels can be distinguished: architecture, implementation and realisation; for the first of them, the following working definition is given: The architecture of a system can be defined as the functional appearance of the system to the user, its phenomenology.”

Gerrit Blaauw (1924–2018) Dutch computer scientist

Although the term architecture was introduced only ten years ago in computer technology (Buchholz), the concept of architecture is as old as the use of mechanism by man. When a child is taught to look at a clock, it is taught the architecture of the clock. It is told to observe the position of the short and the long hand and to relate these to the hours and the minutes. Once it can distinguish the architecture from the visual appearance, it can tell time as easily from a wrist watch as from the clock on the church tower.
The inner structure of a system is not considered by the architecture: we do not need to know what makes the clock tick, to know what time it is. This inner structure, considered from a logical point of view, will be called the implementation, and its physical embodiment the realisation.
Source: Computer architecture (1972), p. 154

Related topics