The reflective consistency principle
(With focus on design, but equally applicable to knowledge management, decision making, and similar disciplines).
A discipline that fosters the practice of its research products within itself and constantly reflects upon these activities to improve them is called a “reflective consistent” discipline (Reich, 2004).
If you
agree that any discipline should embrace this principle you can skip the following story.
If I told you that …
Microsoft selected Linux to help it fight Internet
attacks
You’d probably say: “Can’t be!” You would expect
Microsoft to always use its own products in its practice. Otherwise, you’d lose
your confidence that Microsoft believes in its products and maybe its products
are not as good.
Interestingly, Microsoft indeed employed at least once Linux-based services to fight Internet attacks as the following news item says:
What’s the point?
·
Microsoft would have never done so if it had another choice
·
Microsoft is too proud to use the competing OS as a resource
·
If possible,
Microsoft will always
use its own products to carry out its business!
So should a reflective
consistent discipline!
Reflective consistency in design (but applies well to knowledge management and decision making)
·
We, design researchers, develop design tools
·
We, design researchers, should use design tools
·
It is not a burden, it is an opportunity, a
challenge
·
… it works!
Therefore,
Design researchers should make sure their research products are used by themselves to assist them in their activities. |
Example applications of the reflective consistency principle in design:
1.
n-dim project
The n-dim approach to studying and supporting design
Figure 1: The n-dim approach to building
design support systems
At the foundation (1), there is a software infrastructure designed to address design contexts and also designed to scale up to handle real applications. As additional applications are developed, n-dim would include repositories of various blocks for building applications (2). At the top level (3), our research and development follows the philosophical positions and theories we developed and evolved through empirical studies. These theories guide us in future studies and development projects, and are subject to constant reflection and potential revisions (4).
A project starts as collaboration with industrial or other partner(s). In order to support design and study it at the same time, we adopt participatory action research (PAR) as our development methodology. Together with our collaborators, we study the present state of information management in the organization. The bottlenecks and their severeness suggest priorities in setting goals for collaborative projects. We jointly define the project goals (5). The development process (6) uses the infrastructure and reuses the repositories of previous blocks (7) for prototyping the application (8). This development, in turn, enriches the repositories and the infrastructure. The application is deployed and tested by its end-users. This process iterates until the goals, as understood at each iteration, are satisfied by the evolving application (9). During the evolution, parts of the system that become stable can be re-written quickly in more efficient code. The collaborative project is studied and reflected upon continuously to uncover potential improvements to all aspects of the methodology (10). Its results are used to refine our theories (11). During such projects we also identify critical areas for basic research, prioritize and execute them.
Our
hypothesis is that this process supports the development of support systems in
the best way we know. We have developed a collection of tools that supports the
execution of this process (Subrahmanian
et al., 1997).
2.
Design rational capture (DRC)
Figure 2 shows QFD and Pugh concept selection being used in the design of a new DRC method. In this design, these tools help record significant design rationale. The result of this design turns out to be a tool based on QFD. In the paper, I also mention that it is quite contradictory to talk about design rationale which is never captured in a linear form, by using the linear form of a journal. Instead, each proposal should have described its approach by casting the description (or the rationale behind the approach) in itself. The paper tries to give a feeling of how a description in the tool itself might look like.
Figure 2: QFD and Pugh concept selection
used to design a design rationale capture system
1.
Mechatronics course design
project
Figure 3 depicts the process we used to design the context of
learning design. It consists of two main steps: the design of the course and
its implementation. The course design is subdivided into three steps:
1.
Requirements collection and
analysis: The requirements come from studying designers but also from
anticipating the future needs in future design environments. Design techniques that could be used include:
task analysis, idea generation techniques such as brainstorming, surveys, QFD,
and FMEA.
2.
Goals setting: The requirements or needs of
future designers are translated into course goals and learning activities that
could support them. Supporting design techniques for this step include: QFD, RQFD (Reich and Levi, 2004), and influence graphs (Reich and Kapeliuk,
2005).
3.
Means identification, selection, and generation:
The course goals are matched with specific design methods, learning exercises,
and other means to address them. Supporting design techniques include:
creativity methods, QFD, function-means trees (Hubka
and Eder, 1988) or graphs, AHP (Saaty, 1980), design
for variety (Martin and Ishii, 2000), influence graphs, Pugh concept selection
(Pugh, 1990), and SOS (Ziv-Av and Reich,
2005). In some cases, available methods are insufficient to address the needs
properly. This may lead to suboptimal solution or to the initiation of a
research project to develop suitable methods. This is important feedback that
educational practice could provide to the engineering design community.
Figure 3: Being reflectively consistent about
designing contexts for learning design
Contributed projects:
If you know of a research project that
uses the reflective consistency principle, please email me information (yoram @
eng.tau.ac.il or yreich @
stanford.edu)!
See also research methodology.
Publications include:
1.
Reich, Y. (1994), What is Wrong
with CAE And Can it be Fixed, In Preprints of Bridging the Generations:
An International Workshop on the Future Directions of Computer-Aided
Engineering, (Pittsburgh, PA), Rehak, D. (ed.),
Department of Civil Engineering, Carnegie Mellon University.
The paper analyzes two projects under the guidance of Steven J. Fenves (for
whose honor the workshop was organized) and concludes that contextualized
research is the way to improve CAE research. Such research is exemplified in
the n-dim
project. (Postscript
file, 117K; PDF,
285K gzipped).
2.
Reich, Y. (1992), The Theory
Practice Problem of Technology, Tech. Rep. EDRC 12-51-92, Engineering Design Research Center,
Carnegie Mellon University, Pittsburgh, PA.
This is a long document, very different from the other papers. It has some
history of CAE and design research, some philosophy, and some future directions
connected to the n-dim
project. It is relevant to quality management, knowledge management, and other
practices that involve theory and practice in cultural context. (Gzipped
Postscript 110K; Zipped
PDF, 1.47M)
3.
Subrahmanian, E.,
Reich, Y., Konda, S. L., Dutoit, A., Cunningham, D., Patrick, R., Thomas, M.,
Westerberg, A. W. (1997), The n-dim Approach to Building Design
Support Systems, Proceedings of ASME Design Theory and Methodology DTM
'97 ASME, New York, NY.
(Postscript
file, 263K)
Abstract: Creating practical design support systems is a
complex design endeavor. We approach it with an evolutionary process, one that
studies the design information flow then builds and tests information
management support systems. Through our experience with industrial partners we
have evolved this process into a set of methods and tools that implement these
methods. We have evolved an infrastructure ure called
n-dim, that is composed of a small number of
building blocks that can be composed in ways that match the complexity of
design contexts and work. We have developed this infrastructure to be highly
flexible so as to allow us to conduct this evolutionary process in a practical
project setting.
4.
Y. Reich, E. Subrahmanian, D.
Cunningham, A. Dutoit, S. Konda, R. Patrick, A. Westerberg, and the n-dim
group, “Building
agility for developing agile design information systems,” Research in
Engineering Design, vol. 11, no. 2, pp. 67-83, 1999.
[Get gzipped postscript (last 4 figures missing)|Zipped pdf (last 4 figures
missing)]
5. Y. Reich, “Improving the rationale capture capability of QFD,” Engineering with Computers, 16:(3-4):236-252, 2000.
6.
Reich Y., The
Reflective Consistency Principle of Design Research – A Challenge for Design
Research, 2004.
7. Y. Reich, E. Kolberg, and I. Levin, “Designing contexts for learning design,” International Journal of Engineering Education, 2006.
Last
modified: 2/23/2006 11:57:00 AM