Design Solution Analysis for the Construction of

Situational Design Methods

Robert Winter

Institute of Information Management, University of St. Gallen Muuml;ller-Friedberg-Strasse 8, 9000 St. Gallen, Switzerland

Robert.Winter@unisg.ch

Abstract. Situational design methods provide problem solving guidance that can be configured to fit a range of different design goals and contexts. While the formal aspects of situational method engineering are well researched, the specification of method fragment instances and their configurations is often left open and regarded as specific to the respective design problem class. We propose an approach that analyzes variations of existing design solutions to explore the underlying design factors and to identify design situations. This knowledge is then used to derive method fragments and configuration rules that represent the explored variety of design solutions. The proposed approach has been applied for several design problem classes to construct concrete situational design methods. As an illustrative example, the construction of a situational design method for enterprise architecture management is used in this paper. Based on the exploration of eight design factors and three design situations, six method fragments are derived that are combined into four situational method configurations.

1 Introduction: Contingencies, Design and Situational Methods

“At the most abstract level, the contingency approach says that the effect of one variable on another depends upon some third variable” [1]. In an organisational context, contingency theory argues that success or failure of different organizational structures depends on contingency factors such as size, task uncertainty, and task interdepend-ence [2]. Although its validity is questioned by some [e.g. 3], we agree with Donaldson that “overall, empirical studies show that fit positively affects performance, thereby supporting the central idea of contingency theory” [1].

Design Science Research is a research paradigm that has been, among other application domains, successfully deployed to Information Systems (IS). In the following, we will use DSR to abbreviate Design Science Research in Information Systems. At its core, DSR is about the rigorous construction of useful IS artefacts, i.e. “technology-based solutions to important and relevant business problems.” [4, table 1] Technically, IS artefacts can be constructs, models, methods, or instantiations [5]. While instantiations are usually represent a solution to a singular design problem, constructs, models and methods can have different levels of generality and, as a consequence, “represent [.] a general solution to a class of [design] problems.” [6]

Generality is therefore an important quality of an IS artefact [4]. The two design goals of generality and utility are however conflicting. In their research on reference

J. Ralyteacute;, I. Mirbel, and R. Deneckegrave;re (Eds.): ME 2011, IFIP AICT 351, pp. 19–33, 2011. copy; IFIP International Federation for Information Processing 2011

20 R. Winter

modelling, Becker et al. discuss what they call the [process] reference modelling dilemma: “On the one hand, customers will choose a [process] reference model that [hellip;] provides the best fit to their individual requirements and therefore implies the least need for changes. On the other hand, a restriction of the generality of the model results in higher turn-over risks because of smaller sales markets” [7]. This dilemma is not only apparent in [process] reference modelling, but also exists for design methods. With increasing generality, the individual utility of a solution for solving a specific design problem decreases – and vice versa. The overall, cross-organization sum of individual utilities might be increasing when design solutions have a higher generality – but individual organizations might not be interested in this “overall utility”. As a solution to this dilemma, Becker et al. [7] propose adaptation mechanisms that instantiate a generic [process] reference model according to the specific design problem at hand.

Both design methods and [process] reference models can be understood as (more or less) general problem solutions. As a consequence, situational methods (e.g. [8, 9, 10, 11]) can, like adaptable [process] reference models, aim at solving the trade-off between solution generality and individual solution utility.

As situational method engineering allows to develop artefacts which are adaptable to different design problem instances within a design problem class, a crucial decision during the method construction phase is to delineate the range of addressed design problems (i.e. to specify the design problem class) and to understand the relevant design situations within this class. If a design problem class is understood as a set of “similar” design problems, a design situation can be understood as a subset of design problems which are even more similar, i.e. which share certain contingencies. It has been argued that, in situational method engineering, such contingencies can be represented by a certain design goal vector and/or by a certain context [12]. Depending on the degree of desired generality, a design problem class can be partitioned into few, very generic design situations or a larger number of design situations of lesser generality.

The configuration or adaptation of a situational method to a certain design situation can therefore be understood as an application of contingency theory. If relevant contingencies of the respective design problem class are represented correctly by appropriate design situations and appropriate adaptation/configuration mechanisms, design solutions can be generated that not only solve the [process] reference modelling dilemma, but

剩余内容已隐藏，支付完成后下载完整资料

建筑设计方案的情境设计方法

罗伯特·温特

圣加伦大学信息管理学院，穆勒-弗里德伯格街8号，9000圣加伦，瑞士

摘要：情景设计方法提供了解决问题的指导，可以对其进行配置，以适应一系列不同的设计目标。虽然情景化设计得到了很好的研究，但是方法片段实例及其配置的规范常常是开放的，并且被认为是特定于各自的设计问题类的。我们提出了一种分析现有设计解决方案变化的方法，以探索潜在的设计因素并确定设计情况。然后，使用这些知识来派生方法片段和配置规则，这些方法片段和配置规则表示所探索的各种设计解决方案。该方法已应用于多个设计问题类，构建了具体的情景设计方法。本文以一个企业架构管理的情景设计方法的构建为例进行了说明。通过对8个设计要素和3种设计情境的探索，推导出6个方法片段，并将其组合成4种情境方法配置。

1引言:突发事件、设计与情景方法

在最抽象的层次上，说一个变量对另一个变量的影响取决于第三个变量。在组织背景下，权变理论认为，不同组织结构的成功或失败取决于权变因素，如规模、任务不确定性和任务相互依赖。尽管它的有效性受到一些人的质疑。，我们同意Donaldson的观点，“总的来说，实证研究表明契合度对绩效有积极的影响，从而支持了权变理论的核心思想”。

设计科学研究是一种研究范式，在其他应用领域中已经成功地部署到信息系统中。接下来，我们将使用DSR来缩写信息系统中的设计科学研究。在其核心，DSR是关于严格构建有用的是人工制品，即“基于技术的解决方案的重要和相关的业务问题。从技术上讲，人工制品可以是构造、模型、方法或实例化。虽然实例化通常表示单一设计问题的解决方案，但是构造、模型和方法可以具有不同级别的通用性，因此，“表示[。[英语泛读材料一类[设计]问题的通解。”

因此，通用性是的一个重要特性。然而，通用性和实用性这两个设计目标是相互矛盾的。对他们的研究有借鉴意义，Becker等人讨论了他们所称的参考模型困境:“一方面，客户将选择参考模型，该模型最适合他们的个人需求，因此意味着最不需要更改。另一方面，由于销售市场较小，模型通用性的限制导致了更高的周转风险。这种困境不仅在参考模型中很明显，而且在设计方法中也存在。随着通用性的增加，解决特定设计问题的单个解决方案的实用价值会降低，反之亦然。当设计解决方案具有更高的通用性时，单个实用程序的总体跨组织和可能会增加——但是单个组织可能对这种“总体实用程序”不感兴趣。为了解决这一困境，Becker等人提出了一种适应机制，根据当前的特定设计问题实例化一个通用引用模型。

设计方法参考模型都可以理解为(或多或少)通用的问题解决方案。因此，情景方法可以像可适应的参考模型一样，旨在解决解决方案通用性和单个解决方案效用之间的权衡。情景化设计允许开发的产品适应不同的设计问题实例在一个设计问题类,一个至关重要的决定在构建阶段方法是描述解决设计问题的范围(即指定设计问题类)和理解这门课中的相关设计情况。如果设计问题类被理解为一组“相似的”设计问题，那么设计情况可以被理解为更相似的设计问题的子集，即共享某些偶然事件。有人认为，在情景方法工程中，这种偶然性可以用特定的设计目标向量和/或特定的上下文来表示。根据所期望的通用性的程度，可以将设计问题类划分为很少的、非常通用的设计情况或大量通用性较差的设计情况。

因此，情景方法的配置或对特定设计情景的适应可以理解为权变理论的应用。如果适当的设计情境和适当的适应/配置机制能够正确地表示出各自设计问题类的相关偶然性，那么就可以生成设计解决方案，不仅可以解决参考模型的困境，还可以考虑偶然性因素。然而，要实现这一点，方法工程必须识别设计问题类的偶然性，并正确地派生出一组合适的设计情况，以及将方法片段组合成情景方法的适应/配置机制。

本文的目的是通过分析已有的设计问题类的足够数量的设计解决方案，证明方法构造和权变识别是可以实现的。在第2部分中，我们总结并扩展了现有的设计解决方案分析方法。第3节概述了如何使用设计解决方案分析来派生方法片段和片段配置规则。作为一个示例，使用企业体系结构管理作为设计问题类，并在第4节中导出了相应的情景方法。第五部分对本文进行了总结，并对该领域未来的研究进行了展望。

2现有设计方案分析

温特扩展了Bucher和Klesse的设计问题分析程序，它区分了更多的组件，并假设通常只构建可适应的情景解决方案构件。以下是温特的提案提炼和说明:

1. 提出了设计问题类描述的一种粗略思路。这一步的结果是定义，描述了系统在分析下的设计目标和思想，为各自的设计问题分类。在第3节中，我们将说明设计问题类企业体系结构管理(EAM)的方法。它是通过定义体系结构、企业体系结构和EAM来描述的，通过定义相关工件的范围，以及通过区分潜在的EAM目标来描述的。

2. 通过文献分析，找出针对这类设计问题的潜在的偶然性因素，即在实践中可能影响如何解决这类设计问题的因素。对于EAM，这样的分析产生了诸如“EAM的主要赞助商是IT或业务”、“EAM的主要交付物是地图、分析或项目支持”、“EAM的主要目标是透明性、一致性、简化或灵活性”或“EAM的角色是主动的或被动的”等因素。

3.为了分析这类设计问题的设计解决方案在实际应用中是如何与什么突发事件相关联的，进行了一项实地研究。利用对实地研究数据的主成分分析，将步骤2中可能的偶发因素候选项列表缩减为一组较小的相关“设计因素”。设计因素通常是几个相关偶然性因素的集合，因此需要语义上的解释,像主成分分析实践的解决方案产生了八个设计因素(如IT运营支持,综合作用,商业策略支持,或设计的影响),合计54统计相关突发事件(见第4节)。例如,设计因素的综合作用像她们的骨料的突发事件“像发生在一个跨学科的团队”,

4. 在多维空间中，每个维度都对应一个设计因子，每个观察到的解都可以理解为一个点。现在应该通过为步骤3中确定的设计因素指定值范围来重新定义设计问题类。这意味着“异常值”设计解被排除在进一步的分析之外，以确保解的有用同质性。对于EAM来说，第4步排除了少数可被清楚识别为异常值的观测解，也就是说，这些异常值显然不能与上述多维空间中的任何集群相关联。

5. 对于绝大多数的观测，现在可以计算代表设计方案之间相似性(或差异性)的超度量距离。超度量距离通常基于欧氏距离。观测结果和它们之间的距离可以用树形图来表示的。两种设计方案的相似度对应于其链接的通用性水平。如果两个设计解决方案非常相似，则它们之间的联系在较低的通用性水平上表示。如果两个设计解决方案非常不同，那么它们之间的联系就可以用非常高的通用性来表示。链接可以解释为链接的特定解的泛化。图1展示了这样一个树状图，它表示33个观察到的解决方案(C1hellip;在设计问题C类中，以及它们的超度量距离。将解C11、C12、C13、C14和C15的概化表示为泛型解C11。C15在某种程度上是一般性的。解C1到C15的泛化表示为更一般的解C1hellip;C15在更高层次上的一般性。设计问题C类的最大泛型解在树形图的顶部。

图1所示。C类设计问题的观测设计解的超密树可视化

6. 将聚类算法应用于观测数据，不仅可以可视化，而且可以刻画C语言中的一般解。通过聚集聚类，可以在“完整细节”(即每个原始观察一个集群)和“一刀切”(即针对整个设计问题类的一个通用解决方案描述)之间的任何一般性级别指定解决方案。通过分析聚类误差与聚类数量的关系，可以确定最优的一般性水平(即最优的聚类数量)。经验数据可以用来确定集群的最优数量，即应该区分的不同“方法”的数量，例如，对于实施EAM的特定数量的公司。如果观测集足够大且足够多样化，这一发现可能适用于一般的EAM。

7. 对于步骤6中选择的解决方案描述通用性级别，每个集群表示一种设计情况。这些情况不仅应该被正式定义(即通过指定各个设计因素的值范围)，而且还应该被语义解释(“设计问题类型”)。

设计方案分析为施工现场设计提供了方法

EAM集群在设计因素IT操作支持、集成角色、设计影响、企业范围的焦点和IT策略支持方面的价值尤其不同。这些差异用于将一个集群描述为“平衡的、主动的EAM”，一个集群描述为“业务分析”，另一个集群描述为“关注IT的、被动的EAM”。因此，情境方法工程应该提供三种情境方法。由于集群在某些(但不是所有!)设计因素方面是相似的，这些位于位置的方法将共享某些方法片段。

有一些,但不多,如何识别设计相关工作情况为情境方法工程:有人建议区分“项目大小”,“利益相关者群体数量”或“应用技术”对于每一个情境方法,而其他指定的情况下在个案基础上(如。10、12)。这里提出的程序允许对任何给定类别的设计问题进行系统和可靠的设计情况识别和说明，只要能够观察和分析这类问题的足够数量的问题解决方案。

但是，确定设计因素和设计情境只是构建情境设计方法的第一部分。需要识别设计问题并将其与设计情况联系起来，需要指定一组方法片段，这些方法片段的组合将构成此类设计问题的有用解决方案。下一节将为情景设计方法构建的第二部分提出一个步骤。

然而，应该注意的是，即使是两个施工程序部分也不一定足以解决c语言中的每一个设计问题。参照图1，组合方法片段可以解决情景C1的一般设计问题。15足够了，但仍然可能需要适应设计问题C15，以便有效地解决这个特定的问题实例。

3方法片段和配置规则的推导

对于典型的设计问题类，可以确定4到8个设计因素，充分解释观测到的设计解决方案的方差。这些设计因素跨越了一个解决方案室，在这里，三到六种设计情况是不同的。

关键的一步是在n维设计因素空间中分别定性地解释n个设计因素和m个设计情况，这些设计情况被定量地创建为数据集和集群的主组件。为此,有必要为每个设计状况识别p的子集设计因素(ple;n)最佳描述各自的设计情况,即价值观的因素尤其在集群和/或高或低的因子值只有一个小标准偏差在一个集群中。

理解设计因素与设计情境之间面向问题的关系是构建各自方法的关键:每个方法片段都可以被理解为p维设计因素子空间中的“基本运动”。所述定位方法聚合了某些片段，因此在n维设计因子空间中构成了复杂的多维运动。

8. 对于每一种描述设计因素的设计情况，都需要进行标识。在EAM中，只有在“IT聚焦、被动EAM”的设计情境中，设计要素IT运营支持的价值较高，而设计要素在企业范围内的关注点、集成角色和设计影响的价值较低。相反，EAM设计情况“平衡的、活动的EAM”对于IT操作支持的价值要小得多，但是对于企业范围的焦点、集成角色和设计影响的价值要高得多。在信息供应、业务支持和IT策略以及IT治理支持方面，这两种设计情况并没有太大的不同，因此这些因素对于描述它们并没有什么用处。

9. 现在描述设计因素需要与设计问题联系起来。以上所有程序步骤分析现有的设计解决方案。由于这些设计解决方案是有目的地创建的，所以它们被定性地解释并与设计问题相关联。集中,被动的像的,描述设计因素的综合作用,“企业范围的焦点”和“设计影响”可以关联到一个像设置主要像赞助商是CIO,主要像客户功能,像主要是表现在IT功能和像由业务部门被广泛忽视的。相反，“业务分析”可以与EAM设置相关联，在EAM设置中，业务是主要的涉众和执行者，而实现方面的考虑被广泛忽略。大多数EAM设置可以很容易地与文献中经常描述的主要EAM挑战相关联。例如，EAM的业务参与缺失和业务价值创造缺失对应于第一个EAM设置，而EAM的“基础”/“执行”缺失和过多的“局部性”对应于第二个EAM设置。

10. 现在，通过比较设计解决方案(步骤1-8)和设计问题(步骤9)，可以得到基本的解决问题的操作。这些基本的解决问题的操作构成方法片段。如果如设计问题是,业务涉众参与像她们不够赞助和/或像交付,这似乎不像建议创建足够的商业价值,原有像设置接近“集中,被动的像”,而将来像设置可能是平衡,活跃的像。基本的问题解决活动可以从各自的特征设计因素的“集成角色”、“企业范围的焦点”和“设计影响”中派生出来。片段应该包括一个合适的方法,其中,“像符合业务目标”,“公司内部架构师有一个广泛的网络”,“像团队和业务部门不断交换信息(如在建筑板)”,“像发生在一个跨学科的团队”和“像影响业务架构设计”。例如，如果设计问题是EAM没有得到充分的“实现”，并且没有产生足够的影响，那么现有的EAM设置接近于“业务分析”，而将来的EAM设置也可能是“平衡的、活动的EAM”。基本的解决问题活动可以从各自的特征设计因素“IT治理和IT策略支持”、“IT操作支持”和“EAM治理”派生出来。因此，一个合适的方法片段应该包括“EAM的结果用于IT策略开发”、“架构数据与EAM部门集中在一起”和“EAM的结果用于IT开发”等。

11. 根据一组确定的设计问题和指定的方法片段，现在需要派生方法配置规则。基本上(可重复使用)

设计方案分析为施工现场设计提供了方法

步骤10中标识的方法片段需要与各自的设计情况相关联。描述设计因素越少，识别出的设计问题越少，片段配置就越简单，反之亦然。对于EAM示例，根据设计情况，从总共6个可重用方法片段中最多配置4个位于4个位置的方法片段(参见第4节)。

4企业架构管理——设计解决方案分析的一个示例

4.1步骤1至步骤7:设计方案分析

本小节总结了Aier等人对EAM设计解决方案的经验分析，该解决方案应用了建议过程的步骤1到步骤7——尽管没有详细说明过程本身。Aier等人以Ylimaki的一组EAM成功因素为出发点。为了区分不同的EAM方法，问卷的第一部分要求企业对EAM有一个大致的了解

剩余内容已隐藏，支付完成后下载完整资料

资料编号：[18674]，资料为PDF文档或Word文档，PDF文档可免费转换为Word