A framework for the co-design of business and IT systems

College of Information Science and Technology

Drexel E-Repository and Archive (iDEA)
http://idea.library.drexel.edu/

Drexel University Libraries
www.library.drexel.edu

The following item is made available as a courtesy to scholars by the author(s) and Drexel University Library and may contain materials and content, including computer code and tags, artwork, text, graphics, images, and illustrations (Material) which may be protected by copyright law. Unless otherwise noted, the Material is made available for non profit and educational purposes, such as research, teaching and private study. For these limited purposes, you may reproduce (print, download or make copies) the Material without prior permission. All copies must include any copyright notice originally included with the Material. You must seek permission from the authors or copyright owners for all uses that are not allowed by fair use and other provisions of the U.S. Copyright Law. The responsibility for making an independent legal assessment and securing any necessary permission rests with persons desiring to reproduce or use the Material.

Please direct questions to archives@drexel.edu

A Framework For The Co-Design of Business and IT Systems ${ }^{1}$

Susan Gasson, the iSchool at Drexel, Drexel University, Philadelphia, USA
email: sgasson@ischool.drexel.edu

Abstract

This study deals with the intersection of knowledge and action: how knowledge is developed, transformed, interpreted and used to change systems of business process and IT so that stakeholders may make effective decisions and take effective action in their work. The co-design of business and IT systems is a process within which business systems of human activity and IT systems of information processing are mutually constituted. It requires the negotiation of competing technological frames across multiple knowledge domains. Three major challenges hinder effective innovation: (i) a mismatch between goal-driven IS design methods and the need for cross-functional knowledge-sharing, (ii) the distributed and partial knowledge possessed by stakeholders from diverse groups; (iii) the need to maintain interpretive flexibility across cycles of discovery and analysis. This paper develops an analytical framework for integrating knowledge frames across stakeholder groups, to provide a common language for the codesign of business and IT systems…

1. Introduction

The traditional waterfall approach appears to dominate the design of IT systems in organizations, even when this approach is patently inappropriate to the type of IS or the degree of organizational uncertainty (Barry [2, 16, 17, 20, 48]. This may be because we have no compelling alternative model with which to replace it. We have “spiral” process models [6], that reflect an evolutionary approach to solutiondefinition. But the detailed activities required for emergent design are ill-understood. The most common spiral models are overly goal-directed, focusing on problem closure through a “try it and see” engineering approach, rather than legitimizing the problem inquiry
and synthesis required for situated design [22]. A new generation of interaction design and agile design methods has recently emerged, based on a recognition that interactive mechanisms are required for user involvement, for design requirements to emerge. But these methods lack theoretical underpinnings and also adopt the goal-directed, consensus assumptions of traditional methods [19]. We still lack a framework that focuses on the processes involved in the design of an organizationally-situated information system: the co-design of business (process) and IT systems. The study discussed in this paper examines this need, not from the perspective of defining a prescriptive process model, but to produce a framework and meta-models of the socially-situated processes of knowledge integration in the co-design of business and IT systems, so that we may better understand and manage this process.

2. Design for Business and IT Systems

2.1 Design framing as social construction

The social and technological contexts of action are mutually constituted through the application of relevant “technological frames” [4, 5]. Various social groups ascribe sets of meanings to their understanding of the role and purpose of technology in a particular context. Some of these frames are shared across stakeholder groups and some are radically different, leading to consensus over some aspects of related change and conflict over others. Relevant social groups interpret and redefine the artifact as they adapt it to their purposes, based on their prior experience of similar technologies or applications [5]. The eventual form of a technology is determined through a process of closure, “by which facts or artifacts in a provisional state characterized by controversy are molded into a stable state characterized by consensus” [35, page

^[1]

109]. The social construction of technology literature asks under what circumstances is the “black box” of technology closure taken up and reexamined by different groups [26].

Framing has appeared in the organizational and MIS literatures in a number of forms. These reflect the need to account for differences in the frame of reference applied to organizational design or management decisions. Orlikowski and Gash [38] employ the concept of technological frames to explore the mismatch between the intent of managers, who introduce IT in order to change the organization in specific ways, and the outcome. This use of technological frames focuses on using IT primarily as a management tool, investigating how to build consensus around management goals for organizational change by means of a gap analysis between organizational groups with conflicting technological frames [28]. Designed systems and artifacts possess interpretive flexibility: their role, purpose, and forms are subject to negotiation by various social groups of stakeholders in the design. The perception of whether an information system or artifacts “works” or does not “work” depends upon who uses them and how they are used. Groups will modify or refine the artifact’s form to solve the problems that they experience within their context of action. “Each problem and each solution, as soon as they are perceived by a relevant social group, changes the artifact’s meaning, whether the solution is implemented or not” [5, page 52]. Other studies of technological frames have examined change as emergent and socially-embedded, exploring interactions between the norms and values that pertain in various organizational groups, or examining how to maintain interpretive flexibility in IT-related organizational change (Davidson, 2000; Markus et al., 2002). That is the approach taken here. An organizationally-situated design process must integrate and legitimate a synthesis of situated knowledge across multiple stakeholder groups. Business and IT systems may be perceived as mutually constituted through the process of negotiating technological frames. The co-design of business and IT systems constantly cycles between determining change requirements for the organizational context and determining change requirements for the technology context.

But while design may be cyclical, it is cyclical for two different purposes. Design-in-action consists of a dialectic between two cycles: inquiry/discovery and closure. One cycle of action consists of surfacing and debating the possibilities for organizational and process change. The second cycle requires that
stakeholders debate courses of action and achieve closure. Once a technology artifact acquires a stable form, it tends to support an “investment in form”, where a commitment to the proceduralization and forms of work overshadows the adaptation needs of specific contingencies [43]. But as each phase of changes are implemented, these introduce new organizational processes and problems, that eventually necessitate a new cycle of discovery and inquiry. This will be followed by a further cycle of closure, and so on [21]. Situated design is not goal driven - at least in the sense posited by Simon [40, 41]. Short-term goals may drive short term change requirements. But organizational design is too complex for stakeholders to agree a coherent set of shared goals for change. Multiple organizational groups pursue diverse workgoals and engage in distinct “systems of human activity” [10]. Goals for change emerge, over time, and as a result of observing the impact of initial organizational changes. Similarly, the goals of IT change follow the goals of business change.

2.2 The Mismatch Between Design Methods and Design Practice

Multiple - and often conflicting, in terms of goal setting - systems of purposeful human activity are supported by an integrated set of business processes and a supporting set of computer-based information systems. Simon’s [40] assumptions of a goal-driven process have received remarkably little attention in the IS literature [10]. Yet empirical research into software design processes reveals a much less goal-directed, emergent approach. In the “psychology of programming” literature, the behavior of experienced designers is categorized as “opportunistic” because it diverges from a breadth-first or depth-first decompositional strategy [1, 24, 25]. Expert designers reuse known solutions, by identifying partial sets of requirements that fit with these solutions, incorporating implicit knowledge and implied requirements into the “framing” of new solutions [23, 34]. If change requirements do not fit with available solutions, it is the system “problem” that is reframed, not the requirements for an IT solution. As designers interact with users and other stakeholders, new information emerges that makes existing goals a poor fit with emerging requirements [34]. Goals are not only redefined, but they are gradually and partially reframed - often implicitly and subjectively. Far than being planned or guided, definitions of a design problem and solution converge in tandem [13, 22, 33]. “The issue becomes identifying what guides the discrimination between significant and insignificant”

[44, page 105]. Far from being considered merely illstructured, problems that pertain in the co-design of business and IT systems may be viewed as “wicked problems”, which are incapable of definition and thus suggest no criteria for evaluation of the solution. Such problems can only be resolved through approaches that permit the surfacing and evolution of design goals and solution forms, until a consensus is achieved between the multiple organizational stakeholder groups spanned by the business process and information systems to be changed [39].

2.3 Establishing a common language for knowledge-exchange across groups

So how may we surface and reconcile such diverse technological frames in the co-design of business and IT systems? Innovative change results when individuals who belong to multiple social groups integrate two or more technological frames, or when members of various stakeholder groups learn from each others’ framing perspectives [5, 45]. Communicating, coordinating, and translating relevant knowledge are key elements in design, especially when this process spans organizational boundaries [9, 14, 27]. Mechanisms that support knowledge externalization allow design stakeholders to understand what they know and to share it with others [37]. But this process may be complicated by the competing claims to knowledge of different organizational groups [11, 29]. Various groups possess only partial knowledge of the organization and draw on different bases of expertise. We lack effective mechanisms for knowledge framing and translation across group boundaries: a “common language.”

The ability of design stakeholders to share knowledge effectively across domain boundaries evolves as they learn to work together. Groups of people who regularly work together on shared tasks develop a repertoire of shared technological frames. These provide cognitive shortcuts which permit them to determine how to act without conflict or the need for complex explanations. Shared frames are demonstrated in the use of shared language constructs and graphical representations (Boland [7, 8, 15, 30]. For example, IT developers share a spoken and representational vocabulary that is often unintelligible to other workers, but which allows them to communicate effectively, using shorthand terms such as “this is a blue screen error,” or modeling techniques such as flowcharts or use-cases, that embody a specific set of technological frames about their criteria for design closure. In IT system development projects, shared understanding is achieved by means of argumentation around a
representational model of the problem and potential solutions [18, 27]. This process works because IT developers share a similar background, employing a common vocabulary and using shared diagrammatic representations that allow them to interpret novel situations in the same way. But a shared language for the co-design of business and IT systems must encompass a much wider set of framing constructs than those employed in IT development projects: it must span stakeholder group boundaries.

The negotiation of technological frames across functional or organizational domain boundaries may be achieved through the mediating action of boundary objects. These are knowledge-representations or artifacts that convey sufficient information about the intersection between two knowledge domains for people from the separate domains to coordinate their work, but which are sufficiently elastic for them to support multiple interpretations at the locus of intersection between domains [42]. For example, your doctor may write a prescription that is filled by a pharmacist. Neither of the two needs to understand the work of the other to coordinate their part of the work of providing you with treatment. The pharmacist does not need to understand what is wrong with you, to dispense the medicine, nor does the doctor need to worry that a cheaper package is available over-thecounter. But you (as the patient at the intersection of their two jobs) need the physician to write a prescription that the pharmacist can understand and need the pharmacist to dispense the drug in a manner consistent with the physician’s instructions and to provide you with a written label instructing you how the drug should be taken. The intersection of three domains: the work of the physician, the work of the pharmacist, and your actions as a patient are coordinated by means of the prescription boundary object.

A boundary-spanning framework for design must adapt knowledge across multiple domains of application by reconciling various local frameworks for action [14]. This type of tacit knowledge-resource is not amenable to codification or externalization in a written form. Boundary objects contain the potential for the transfer, translation or transformation of knowledge, as members of various organizational groups collaborate in shared work. Maps and models representing the intersections of organizational domains provide the greatest potential for knowledge transformation, as they permit stakeholders to project their own interpretations of content onto the boundary object [9]. Other forms of boundary object enable tighter coordination. The definition of shared forms and procedures permit one group to impose control

over ways in which another group performs certain tasks, while shared repositories permit groups to share informational resources without adopt another group’s categorization schemes [42].

The discussion in this section has not dealt with shared frames, simply because it is apparent that many fewer framing perspectives are shared than are held (partially) in common [15, 32, 36]. A technological frame cannot be viewed as pertaining to an individual or a group, but is seen as “located between actors” [4]. It denotes a shared construct to the group, that they call upon to guide their joint actions and interactions, but does not indicate a totally shared understanding of the domain to which the frame relates. A technological frame appears to correspond to a form of implicit consensus, that represents the intersections of individual group members’ frames of reference. The construct is therefore relevant to the analysis of requirements across various organizational or social groups.

3. Elements of a method for the co-design of business and IT systems

One possible solution is provided by the suggestion that collective design framing may be driven by the early definition of a particular type of boundary object. Darke [12], in a study of architectural design groups, observed that they mobilized their understanding around a “primary generator” concept. This concept provides an integrative example of the form that the design will take, enabling the group to visualize the designed product [31]. For example, an architect described how his team was inspired to produce a design: “Once we’d flipped from a stack dwelling to a house on the ground, we assumed a terrace would be the best way of doing it” (Darke, 1979, page 185). In a prior study, it was observed that the development of shared meaning in boundaryspanning design was driven by the production of a series of mobilizing objects (reference withheld for review). The need to produce a collaborative artifact that communicated the form of the design to external stakeholders caused periodic, catalytic breakdowns [46] in collective understanding. These resulted in a more highly-shared understanding of organizational change goals and mechanisms. In turn, this leads to a more informed debate about process and IT system change requirements (reference withheld for review). The breakdown concept has been used to understand individual design behavior [3], but has not been applied to group design in boundary-spanning contexts. To manage change successfully, we need a framework for action that mediates across communities
of practice to provide a common language for design participants, in the form of accessible boundary objects that translate knowledge between stakeholder domains, and that manages consensus and diversity of technological frames around an evolving mobilizing vision. There are multiple “systems” to be reconciled in the co-design of business and IT systems, as shown in Figure 1.

Figure 1. Systems of change in the co-design of business and IT systems

The IT professional clearly has a role to play facilitating the co-design of business and IT systems, if they are capable of analyzing and balancing the multiple perspectives and interests involved. Most technology design approaches are highly reductionist, providing a poor basis for the resolution of equivocality in organizational or technical change [10, 47]. To enable their involvement, we need a replicable approach or framework for the co-design of business and IT systems. It was argued above that model or map type boundary objects were most useful for establishing a ‘common language’ to support knowledge translation and transfer across knowledge domain boundaries.

The methodological framework shown in Table 1 was developed to identify suitable forms of boundary object for the co-design of business and IT systems. It implements the constructs of interpretative flexibility and creating a common language for boundaryspanning design, that were discussed above.

The following section presents an example of how the framework was applied, reflecting on its use by experienced IT analysts to facilitate co-design.

Table 1. Analysis framework

4. Applying the framework

The case example was developed from a graduate student project: to investigate the diverse requirements for business and IT systems change in a car dealership employing approx. 45 people. This example provides an excellent example of the interrelatedness of the framework elements.

4.1 Analyzing Wicked Problems

The first element in the analysis framework is the identification of core problems to be resolved by the co-design of business and IT systems. The core task in starting a design investigation is most frequently that of identifying a problem in sufficient depth that a set of goals for change may be defined. The technique applied for the framework has been developed over several years, as a way of modeling wicked problems. There appear to be three key issues for problem stakeholders in defining wicked problems:

• “Root-cause” problems are conflated with “symptom” problems, as people most often experience the symptoms and do not understand their system of work processes in sufficient breadth to determine the cause of these problems.
• Problems are interrelated: to be useful, a problem analysis must reflect a systemic view of the situation. In particular, problems related to one area of operations are often mis-categorized as problems relating to a different area of operations when these share a common consequence
• Most people only experience part of a complex problem: to be useful, a problem analysis must reflect a multivocal view of the situation.

Figure 2 provides an example of this phenomenon. Due to space constraints, this is a partial model.

Figure 2. A Cause-Effect Model of Car Dealership Problems

When the owner of the car dealership was asked what his core problem was, he stated that he was not making as much profit as he thought he should and ascribed this to wastage in the business. The element of wastage that seemed to be of most significance to him was the need to buy new car keys frequently because the keys were lost. This is the cluster of problems to the right of the model (in blue, if you are viewing this in color). After talking to sales staff, managers, lot attendants, car delivery people, mechanics, and other employees, it became obvious that the problems were much more complex than a few lost keys. In particular, there are two “vicious cycles” of problem causality, where the behavior of staff in a variety of different operations is exacerbating the cashflow problems experienced by the business. This is indicated by the heavy, feedback arrows in Figure 2. Unless these vicious cycles of causality are broken, the business will continue to lose money

4.2 Modeling Business Processes

The next stage was to produce a business process model: this is shown in Figure 3. The red boundary shows the scope of systems change agreed by the stakeholders involved in the co-design initiative. This took two iterations to agree, as described below.

Figure 3. Business process model of car dealership
This proved complicated: it necessitated repeated interviews with various staff, as none of them understood what other employees did, in other parts of the business, even though they interacted with them on
a daily basis. But the key issues in generating a business process model arose with the (experienced) IT analyst and with staff and other actors and stakeholders in the car dealership. The experienced IT analyst was used to defining processes around the data processing requirements (through the production of use-cases). Business actors and employees were too familiar with their day-to-day work tasks and goals to conceptualize these as part of a bigger system of work. This has been a frequently encountered problem when applying the framework of business analysis.

Modeling business processes appeared to be antiintuitive and too abstract a task to understand (for both the IT analyst and participant-stakeholders). IT analysts are uncomfortable with the increased scope of processes that they are modeling. They are trained to reduce the scope of a business to elements that are relevant to information processing with IT. The next element of the framework appears to countermand the reductionist tendency and leads to enriched (wider scope) business processes, when used in combination with the two elements discussed so far.

4.3 Modeling human activity and automation processes

To counterbalance the difficulty of modeling business processes, this element of the framework emphasizes integrating the stages of human activity required to run the business. This element models the high-level tasks in which human actors engage, to perform the business processes, divided into a set of swimlanes that represent different organizational functions or groups. This type of representation predates the use of swimlanes for UML activity diagrams and is more helpful than activity diagrams in this type of very early change analysis, for a number of reasons. If one models what people do, rather than how the information-flows work, then problems with the current system of work become apparent fairly quickly. Initially, IT analysts find this to be antiintuitive, as it breaks many rules of formal dataprocessing models. Activities must be completely “joined-up”, so that human processes are privileged equally with computer-based data-processing. Information-flows can appear to originate from a datastore, because the availability of information triggers a time-delayed process. This was resolved by use of a notation that converts the data-store entry into a “record information” process, and so avoids modeling data-stores. A model for the car dealership is shown in Figure 4. I have found that it helps to impose a rule that no automated (computerized) processes may be modeled until all of the human-activity processes have

been modeled. This maintains the interpretive flexibility of the model, enabling it to act as a boundary object that is meaningful to the people performing the work tasks. Where an automated process is shown, this is represented as a human process that is partially or completely shaded, to indicate the extent of automation. Very few processes are completely automated. This form of model requires the analyst to engage in a dialog with actors about how they would like to use information technology. This stimulates learning across actors and stakeholders about the ways
in which information is used by others and the consequences of recording, or not recording information, leading to productive breakdowns in which they redefine their collective understanding of how the various systems of work interact. If they debated in a meeting of stakeholder representatives, the findings of this element of the analysis often result in changes to what information individuals decide to record, regardless of whether a computer-based information system is implemented.

Figure 4. Human-activity & automation swimlane model of business processes (shading indicates automated processes)
In the case of the car dealership, production of the swimlane model enabled the IT analyst to return to the business process diagram and fill in the blanks. Unlike the initial attempt to validate this with staff, people who worked at the car dealership were able to contribute helpfully in validating the higher level business process model and in suggesting a suitable boundary for systems change.

4.4 Analyzing stakeholder change requirements

The fourth part of the framework requires a stakeholder analysis. I have found that IT analysts, particularly those with most professional experience, will not engage fully with stakeholders in producing
this analysis. Instead, they prefer to produce an “analysis” based on their own understanding of what each stakeholder wishes to change. I have found that requiring the analyst to validate what actions should be taken to meet their goals with each stakeholder produces a much richer set of goals for change - and leads to a “ready made” set of requirements for the new information system. A sample analysis is presented in Table 2. This also has the advantage of providing grounds for the “mobilizing vision” of process and system change. I have observed that discussion of the changes as prioritized by each stakeholder tend to lead to productive breakdowns, resulting in a deeper, consensus understanding of how the various parts of the business process system interact. Then conflicts between various stakeholder

change requirements are assessed (these are shown in bold type in the strategies column of Table 3). It is the task of the business owner or senior management to determine how these should be resolved. This part of the process - the ranking and discussion of tradeoffs between changes - provides a mobilizing vision to
guide the implementation of the first cycle of change. Following these changes, the models produced as a result of applying the framework presented here provide a way of benchmarking the results of the changes and suggesting a new mobilizing vision for the next cycle of change.

Table 2. Stakeholder analysis for the car dealership changes

5. Conclusions

It was argued that we need new methods to support the effective co-design of business and IT systems in a mutually constitutive way. The analysis framework and the study presented here demonstrated how a “common language” may be employed to integrate group knowledge about the ways in which people need to work across diverse functional groups., The framework treats the co-design of busing and IT systems as a wicked problem, possessing interrelated and often conflicting systems of problem perspectives. A method to resolve such problems must surface
implicit knowledge and reconcile conflicting or competing perspectives of change goals and requirements. The models presented as part of the analysis framework achieve knowledge surfacing and complex knowledge transfer across group domain boundaries simply because they are complex model or map type boundary objectss that enable knowledge translation at the boundary [9]… The specific form of presentation is intended to maintain interpretive flexibility [5], where the role, purpose, and forms of technology and procedural change are kept open across multiple cycles of modeling, analysis, and debate by various social groups of stakeholders in the design.

The perception of whether an information “works” or does not “work” depends upon the point of view represented in the model, which in turn affects how problems are defined and articulated as the basis for change. Maintaining the equivocality of design “knowledge” across multiple cycles of analysis is critical to this objective. It allows goals to emerge, reducing the mismatch between the design method and the expectation that goals will drive the co-design of business and IT systems - even when these goals are unclear.

Within the space constraints of a short paper, I have attempted to explore the role that various types of boundary object play in mediating distributed understanding and knowledge. Once we have this understanding, we may be able to use boundary objects to “surface” implicit knowledge and to integrate the knowledge of multiple various stakeholders in design. From the sample analysis presented above, it can be understood that technological frames may be surfaced and elucidated through the production of boundary objects that reflect the organizational understanding and change requirements held by various stakeholder groups. The integration of technological frames across stakeholder groups may be progressed by the need to produce a shared boundary object for external consumption, such as a design vision document. Some types of boundary object (models & maps) may be more productive in catalyzing dissonance between groups, causing a collective form of the breakdowns hypothesized by Winograd and Flores [46] to be productive. It has been observed that a collective breakdown is productive under these circumstances, as it forces stakeholders from various functional groups to reconcile and integrate contradictory technological frames. This results in improved collective models of the organization, an increased understanding across groups of their common purposes, and the production of an aligned set of goals for change.

The contribution of this paper is to demonstrate how interpretive flexibility may be maintained across cycles of discovery and analysis, so that all stakeholder perspectives may be privileged equally in the design. This study presented a conceptual and pragmatic framework for integrating technological frames across stakeholder groups, to provide them with a common language for the co-design of business and IT systems.

6. References

1. Ball, L.J. and T.C. Ormerod “Structured and opportunistic processing in design: A critical discussion.” Int. Journal of Human-Computer Interaction, (43:1) 1995, pp. 131-151.
2. Barry, C. and M. Lang “A comparison of ‘traditional’ and multimedia information systems development practices.” Information and Software Technology, (45:4) 2003, pp. 217-227.
3. Beynon-Davies, P. and S. Holmes “Design breakdowns, scenarios and rapid application development.” Information and Software Technology, (44) 2002, pp. 579-592.
4. Bijker, W.E. “The Social Construction of Bakelite,” in The Social Construction of Technological Systems: New Directions in the Sociology and History of Technology, W.E. Bijker, T.P. Hughes, and T.J. Pinch, Editors. 1987, MIT Press: Cambridge MA. p. 159-187.
5. Bijker, W.E. Of Bicycles, Bakelites, and Bulbs: Toward a Theory of Sociotechnical Change. 1996, Cambridge, MA: MIT Press.
6. Boehm, B.W. “Spiral Development: Experience, Principles, and Refinements.” 2000, Carnegie-Mellon Software Engineering Institute: Pittsburgh, PA.
7. Boland, R.J. and R.V. Tenkasi “Perspective Making and Perspective Taking in Communities of Knowing.” Organization Science, (6:4) 1995, pp. 350-372.
8. Brown, J.S. and P. Duguid “Organizational Learning and Communities of Practice: Toward a Unified View of Working, Learning, and Innovation.” Organization Science, (2:1) 1991, pp. 40-57.
9. Carlile, P.R. “Transferring, Translating, and Transforming: An Integrative Framework for Managing Knowledge Across Boundaries.” Organization Science, (15:5) 2004, pp. 555-568.
10. Checkland, P. and S. Holwell Information, Systems and Information Systems: Making Sense of the Field. 1998, Chichester UK: John Wiley & Sons.
11. Compeau, D., C.A. Higgins, and S. Huff “Social cognitive theory and individual reactions to computing technology: A longitudinal study.” MIS Quarterly, (23:2) 1999, pp. 145-158.
12. Darke, J. “The Primary Generator And The Design Process.” Design Studies, (1:1) 1979, pp. Reprinted in N. Cross [Ed.] Developments In Design Methodology, 1984, J. Wiley & Sons Chichester, pp. 175-188.
13. Dorst, C.H. and N.G. Cross “Creativity in the design process: co-evolution of problem-solution.” Design Studies, (22:5) 2001, pp. 425-437.
14. Engestrom, Y., R. Engestrom, and M. Karkkainen “Polycontextuality and boundary crossing in expert cognition: Learning and problem solving in complex work activities.” Learning and Instruction, (5:4) 1995, pp. 319336.
15. Fiol, C.M. “Consensus, Diversity and Learning In Organizations.” Organization Science, (5:3) 1994, pp. 403-420.
16. Fitzgerald, B. “An Investigation Of The Use Of Systems Development Methodologies In Practice,” in Proceedings of 4th European Conference on Information Systems. 1996. Lisbon Portugal.
17. Fitzgerald, B., N.L. Russo, and E. Stolterman Information Systems Development : Methods-In-Action, McGraw-Hill, 2002.

18. Flor, N.V. and E.L. Hutchins. “Analyzing distributed cognition in software teams: a case study of team programming during perfective software maintenance,” in Empirical Studies of Programmers - Fourth Workshop Norwood NJ: Ablex. 1991.
19. Fowler, M. “The New Methodology.” (Available online at http://www.martinfowler.com) 2003.
20. Gasson, S. and N. Holland “The Nature And Processes Of IT-Related Change,” in Information Technology and Changes in Organizational Work, W.J. Orlikowski, et al., Editors. 1996, Chapman & Hall: London.
21. Gasson, S. “Framing Design: A Social Process View of Information System Development,” in Proceedings of The Nineteenth International Conference on Information Systems (ICIS 98). 1998. Helsinki Finland.
22. Gasson, S. “A Cognitive Perspective On BoundarySpanning IS Design,” in IS-CORE, AIS Pre-ICIS Workshop. 2003.
23. Guindon, R. “Knowledge Exploited By Experts During Software System Design.” International Journal of ManMachine Studies, (33) 1990, pp. 279-304.
24. Guindon, R. “Designing the design process: Exploiting opportunistic thoughts.” Human-Computer Interaction, (5:2/3) 1990, pp. 305-344.
25. Khushalani, A., R. Smith, and S. Howard “What Happens When Designers Don’t Play By The Rules: Towards a Model of Opportunistic Behaviour In Design.” Australian Journal of Information Systems, (1:2) 1994, pp. 13-31.
26. Kline, R. and T. Pinch “The social construction of technology,” in The Social Shaping Of Technology, D.A. MacKenzie and J. Wajcman, Editors. 1999, Open University Press: Milton Keynes UK. p. 113-115.
27. Krasner, H., B. Curtis, and N. Iscoe “Communication breakdowns and boundary spanning activities on large software projects,” in Empirical Studies of Programmers: Second Workshop, G.M. Olson, S. Sheppard, and E. Soloway, Editors. 1987, Ablex: New Jersey.
28. Lamb, R. “A Review: Of Bicycles, Bakelites, and Bulbs: Toward a Theory of Sociotechnical Change by W.E. Bijker.” Information Processing and Management, (32:5) 1996, pp. 644-646.
29. Latour, B. “Where Are the Missing Masses? The Sociology of a Few Mundane Artifacts,” in Shaping Technology/Building Society: Studies In Sociotechnical Change, W.E. Bijker and J. Law, Editors. 1992, MIT Press: Cambridge MA.
30. Lave, J. and E. Wenger Situated Learning: Legitimate Peripheral Participation. 1991, Cambridge UK: Cambridge University Press.
31. Lawson, B. How Designers Think: The Design Process Demystified. 3rd. ed. 2000, Oxford UK: Architectural Press
32. Lin, A. and L. Silva “The social and political construction of technological frames.” European Journal of Information Systems, (14) 2005, pp. 49-59.
33. Maher, M.L. and J. Poon “Modelling design exploration as co-evolution.” Microcomputers in Civil Engineering, (11:3) 1996, pp. 195-210.
34. Malhotra, A., et al. “Cognitive Processes In Design.” International Journal of Man-Machine Studies, (12) 1980, pp. 119-140.
35. Misa, T.J. “Controversy and Closure in Technological Change: Constructing “Steel”,” in Shaping Technology, Building Society, W.E. Bijker and J. Law, Editors. 1992, MIT Press: Cambridge MA.
36. Mohammed, S. and B.C. Dumville “Team mental models in a team knowledge framework: expanding theory and measurement across disciplinary boundaries.” Journal of Organizational Behavior, (22:2) 2001, pp. 89-106.
37. Nonaka, I. and N. Konno “The concept of `Ba: building foundation for knowledge creation.” California Management Review, (40:3) 1998, pp. 40-54.
38. Orlikowski, W.J. and D.C. Gash “Technological Frames: Making Sense of Information Technology in Organizations.” ACM Transactions on Information Systems, (12:2) 1994, pp. 174-207.
39. Rittel, H.W.J. “Second Generation Design Methods.” 1972, Interview in: Design Methods Group 5th Anniversary Report: DMG Occasional Paper 1. p. 5-10.
40. Simon, H.A. “The Structure of Ill-Structured Problems.” Artificial Intelligence, (4) 1973, pp. 145-180.
41. Simon, H.A. The Sciences of The Artificial. 3rd. ed. Vol. (1st edition 1969) 1996, Cambridge MA: MIT Press
42. Star, S.L. “The Structure of Ill-Structured Solutions: Boundary Objects and Heterogeneous Distributed Problem Solving,” in Distributed Artificial Intelligence, Vol. II., L. Gasser and M.N. Huhns, Editors. 1989, Morgan Kaufmann: San Mateo CA. p. 37-54.
43. Star, S.L. “The Trojan Door: Organizations, Work, and the ‘Open Black Box’.” Systems Practice, (5:4) 1992, pp. 395-410.
44. Turner, J.A. “Understanding The Elements Of Systems Design,” in Critical Issues In Information Systems Research, B. R.J. and H. R.A., Editors. 1987, Wiley: New York, NY. p. 97-111.
45. Wenger, E. Communities of Practice - Learning Meaning and Identity. 1998, Cambridge UK: Cambridge University Press.
46. Winograd, T. and F. Flores Understanding Computers And Cognition. 1986, Norwood New Jersey: Ablex
47. Zack, M.H. “If managing knowledge is the solution, then what’s the problem?,” in Knowledge management and business model innovation, Y. Malhotra, Editor. 2001, Idea Group Publishing: Hershey, PA.
48. Zhu, Z. “Evaluating contingency approaches to information systems design.” International Journal of Information Management, (22:5) 2002, pp. 343-356.