Date/Place: 16 October 1995/Austin, TX
We propose an object-based approach which we term coordination structure as the basis of a library of reusable patterns of organizational coordination. Such a library has the potential to assist researchers and managers to:
We argue that coordination structure captures interdependences in an organizational setting at the level of detail and specificity required to make a library of patterns useful.
We first provides a short outline of research to date on coordination structure. We then adapt the format of Gamma et al [Gam95] for describing software design patterns to the task of describing patterns of organizational coordination structures. Next we outline some classification schemes for coordination structures useful for the creation of a library of reusable patterns. We finish by outlining future research directions.
Coordination structure is a configuration of actors (e.g., customer, architect, designer, verification team) that interact by creating, modifying and using an array of shared work-objects (e.g., customer requirements, high level design, test protocol). Both actors and shared work-objects are objects in the sense used in object-oriented analysis and design. We limit associations to those between actors and shared work-objects and exclude those that link two actors or two work-objects. The interdependence between any two actors' responsibilities is represented in terms of the shared work-objects that the actors jointly create, modify and use. Coordination structure provides a systems level view of interdependences between actors, i.e., each association can be considered in relation to the whole structure. The set of interdependences among actors makes coordination necessary. A work-object that is not associated with two or more actors is hidden from the analysis. In organizational situations in which shared work-objects persist for significant lengths of time, the association between an actor and a shared work-object can be a significant property of organization structure. Verbs taken directly from participant descriptions are used to name each association.
Coordination structure makes the disaggregation of organizational responsibility specific at the actor level. This is particularly useful in organizational situations in which there is uncertainty and change. Although coordination structure can change over time, the coordination structure of an organizational situation tends to be much more stable than task structure. The responsibilities of actors for specific shared work-objects change less than the specification of the tasks that they actually perform on the shared work-objects. Coordination structure also provides a micro-level perspective. Using this perspective, there is no need to differentiate between intra- and inter-organizational interdependence and coordination. The fact that coordination structure can be easily diagrammed is another significant advantage to the approach. Coordination structure has been used to model inter-firm technology arrangements [Bai93], the design process of custom silicon chips [Bai94a] and the management of consistency between product development and standards evolution [Bai95a].
Gamma et al [Gam95, pp. 6-7] provide the following format for describing software design patterns: Pattern name and classification; Intent; Also known as; Motivation; Applicability; Structure; Participants; Collaborations; Consequences; Implementation; Sample code; Known uses. We propose that their format can be used for patterns of organizational coordination structure with the following modifications: Coordination structure can be used to capture pattern Structure. A case description of a business situation in which the pattern has been identified can been used to capture Motivation and substitute for Sample code. A data dictionary can capture Participants and Collaborations in coordination structure patterns.
Coordination structure patterns can be classified by application area and by topology of actor interdependences. In product development, application areas would include but not be restricted to the following: external integration including the use of lead users and co-development with users; prototyping including throw-away and evolutionary prototypes developed by internal and external design teams; project team organization; executive integration mechanisms such as gate reviews; system integration and testing; architecture development; and relationships with technology suppliers.
The classification of coordination structure patterns by topology can be approached at various levels of abstraction. To date three approaches have been taken. First, an analysis of 24 coordination structure models developed by graduate students in a course on system design management was used to develop patterns associated with the role of the system architect in system design organizations in linking product specifications with prototypes [Bai94].
A second approach was based on an in-depth study of a single large software development project. A five layered approach to modeling coordination structure [Bai95b] was adapted for use in a project organization environment. The key elements in the five layers are actors and shared work-objects alternatively:
This five layered approach was used to identify patterns among the views of coordination structure held by managers involved in the project.
The third approach took a higher level of abstraction. Using a large sample of coordination structures including those used in approaches one and two, five elemental patterns were identified:
All of these patterns can be captured using coordination structure.
Data collection on organizational coordination structures continues, particularly in the area of product development. Related work is also being carried out on pattern classification schemes which address reusability issues such as pattern search, retrieval, verification, and maintenance.
The focus to date has been the application of developments in the area of software reusability [Mil95] to the design and reuse of organizational coordination structures. However, the potential for going in the other direction is also being explored - for using the same object based approach to apply research and management insights from the study of organizations [Mil93, Lew94] to the design of software systems.
[Bai95a] Bailetti, A.J. and J.R. Callahan (1995) "Managing Consistency between Product Development and Public Standards Evolution", Research Policy, December, 26.
[Bai95b] Bailetti, A.J. and J.R. Callahan (1995) "Specifying the Structure which Integrates a Firm's Skills with Market Needs", R&D Management, 25 (2), April, 1995.
[Bai94a] Bailetti, A.J., J.R. Callahan and P. DiPietro (1994) "A Coordination Structure Approach to the Management of Projects", IEEE Transactions on Engineering Management, 41(4), November, 394-403.
[Bai94b] Bailetti, A.J. and J.R. Callahan (1994) "Examining the Mechanisms which Link Product Specifications with Prototypes", working paper, Software Technology Management, Research Unit in Telecommunications Technology Management, Carleton University, Ottawa, Canada
[Bai93] Bailetti, A.J. and J.R. Callahan (1993) "The Coordination Structure of International Collaborative Technology Arrangements", R&D Management, 23 (2), April, 129-146.
[Gam95] Gamma, Erich, Richard Helm, Ralph Johnson and John Vlissides (1995) Design Patterns: Elements of reusable object-oriented software, Reading, MA: Addison-Wesley Publishing Co.
[Lew94] Lewin, Arie Y. and Carroll U. Stephens (1994) "CEO Attitudes as Determinants of Organization Design: An integrated model", Organization Studies, 15(2), 183-212.
[Mil93] Miller, Danny (1993) "The Architecture of Simplicity", The Academy of Management Review, 18(1), 116-138.
[Mil95] Mili, H., F. Mili and A. Mili (1995) "Reusing Software: Issues and research directions", IEEE Transactions on Software Engineering, 21(6), 528-561.
Business Object Design and Implementation
Page hits since 8/25/95