This paper delineates the possible components of a design theory for IS, providing an ontological language for the discussion of these theories.
Previous work and flaws
- Philosophy of science and technology (Dubin): omission of explanations
- The sciences of the artificial (Simon): omitted detailed examination of the artifact nature of theory
- Information systems design theory (Walls et al.):
- product or process or both should be concerned;
- Omission of mandatory constructs and system states
- Design instantiation
- Unnecessary distinction between kernel theory for process and kernel theory for products.
Components of design theory
- Purpose and scope: what the system is for
- Constructs: entities of interest in the theory
- Principles of form and function: define the structure, organization and functioning of the design product or method
- Artifact mutability: IS artifact
- Testable propositions: If a system or method that follows certain principles is instantiated then it will work, or it will be better in some way than other systems or methods
- Justificatory knowledge: justificatory, explanatory knowledge that links goals, shape, processes, and materials
- Principles of implementation: the design is brought into being─a process involving agents and actions.
- Expository instantiation: (practical feature)
- Codd’s theory: well-known product-type design theory
- Software threshold fault policy: method-type theory
- Managing risk in software development: wider conceptualization of IS artifact
- Clear and detailed guidelines for us to better develop design theory.
- Extend design theorizing into implementation, which is consistent with the concept of the artifact as a theory nexus that involves rearticulation of theories in experience.
- What’s the difference between methodology theory (special practical theory) and product theory?
- Why does design science have theories while case study or simulation doesn’t have?