• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content







Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment


    • Oct. 31 IJASCSE Vol 1, Issue 3, 2012 BARRIERS SURROUNDING KNOWLEDGE TRANSFER IN NON-COLLOCATED SOFTWARE ARCHITECTURE DEVELOPMENT Marzanah, A.J., Salfarina, A., Abdul Azim, A. G., AND Rusli, A. Faculty of Computer Science and Information Technology, University Putra Malaysia Abstract—Abundance of efforts have I. INTRODUCTION been endeavored to investigate the Today, the development of software has barriers of knowledge transfer (KT) that evolved tremendously from being exist in various level within organizations. concentrated at a single site to being The structure of non-collocated team geographically dispersed. The distance amplifies the complication of the KT. between the different teams can vary from a Despite efforts put forth, not much is few meters (when the teams work in adjacent known about KT in software architecture buildings) to different continents (Prikladnicki, development, a setting that is very much 2003). Such distributed environment allows knowledge intensive. KT is crucially team members to be located in various essential as for making design decisions remote sites during the software lifecycle, in developing software architecture, many thus making up a network of distant sub- factors and inputs need to be carefully teams (Jimenez et al. 2009). In some cases, considered and accounted. The purpose these teams may be members of the same of this paper is to discuss and outline our organization; in other cases, collaboration or perspectives regarding the barriers outsourcing involving different organizations towards effective KT in this particular may exist. The primary influence to this environment. We believe that the outcome phenomenon stems from huge savings or sound business reasons that include will deposit valuable contribution reduction in workspace costs, increased in particularly in the study of KT in non- productivity, labor cost, better access to collocated software architecture global markets and environmental benefits. development and enrich the knowledge Notwithstanding these benefits, such management literature in general. environment is fraught with challenges. Software architecture is about making Keywords-Keywords: Knowledge transfer design decisions based from the user (KT), non-collocated software requirements. Typically these design architecture, barriers. decisions are not well explicitly documented but remains to reside in the mind of the software architects or software designers (van der Ven et al. 2006). This has caused lost of www.ijascse.in Page 1
    • Oct. 31 IJASCSE Vol 1, Issue 3, 2012 the important knowledge underlying the II. KNOWLEDGE TRANSFER (KT) decisions (the architectural artifact), including KT is the dissemination of knowledge from the evaluated alternatives, trade-offs and one individual or group to another within the rationale about the decision made. Amplified organization. It may be purposely transferred, by the distance between teams, the or it may occur as an unintended outcome of interdependencies between them are other activities (Joshi et al., 2006). As challenged by the decreased of opportunities asserted by Appelbaum and Steed (2005), for face-to-face interaction while relying “…knowledge are best learned through heavily on the documentation. The challenge exposure to and experience…”. This is further continues in terms of limited utilization of the supported by Newell (2005) where according knowledge areas used and exchanged due to to her, KT implies that each individual or the arising difficulties in establishing an group or organizational unit need not learn effective medium for KT between non- from scratch but can rather learn from the collocated teams to connect with each other. experiences of others. Therefore in this Additionally, the intensification of these paper, we adopted the definition of KT as the challenges is increased by the differences in process through which one unit learns from capabilities and work experiences that exist the experiences of others (Argote & between the teams. Moreover, the importance Todorova, 2007; Darr & Kurtzberg, 2000). of software architecture development is From our perspective, KT is about the acknowledged for it is where the integration of integration of knowledge and experience knowledge mostly happens. It does not only between people from various backgrounds provide the blue print of the whole system or and expertise. This is in line with the software to be developed, but it can knowledge intensive perseverance in determine the success or failure of the software architecture development, which development itself. In this paper, our interest demands such integration. These people is geared into understanding the barriers need not only sharing but also learning from surrounding effective KT in non-collocated each others’ experience to ensure that they software architecture development. It is our can accomplish their tasks. It is also believed belief that in order to achieve effective KT that the definition of KT must cover the use of particularly between non-collocated teams, it knowledge on the part of the receiver is crucial that these obstacles must first be (Devanport & Prusak, 2000; Darr & Kurtzberg, understood so that new perspectives and 2000) and not simply by sharing of the solutions either to overcome or increase knowledge between units. This is particularly those impacts on KT can be provided. important to distinct the overlapping terms In the next sections, the current body of between KT and just knowledge sharing, and literature reviewed in this study is explained, also makes it easier to verify that KT has and followed by the discussion on barriers to occurred by investigating those cases effective KT in non-collocated software involving use, which can be observed and architecture development. The paper then measured (Darr & Kurtzberg, 2000). Given all ends with conclusion section. these definitions, we can foresee that the role KT plays is critical to ensure the continuity of www.ijascse.in Page 2
    • Oct. 31 IJASCSE Vol 1, Issue 3, 2012 success to the organization, and also to the and problems. Secondly, it captures early capability development of those involved in design decisions. In software architecture, the KT. global structure of the system has been decided upon, through the explicit assignment A. Software Architecture of functionality to components of the architecture. These early design decisions are The definition of software architecture important since their ramifications are felt in includes all the usual technical activities all subsequent phases. It is therefore associated with design: understanding paramount to assess the quality at the earliest requirements and qualities; extracting possible moment. Thirdly, architecture is the architecturally significant requirements; primary carrier of a software systems quality making choices; synthesizing a solution; attributes such as performance or reliability. exploring alternatives and validating them The right architecture is the linchpin for (Uphorn & Dittrich, 2010). In software software project accomplishment whereby the development process, software architecture is wrong one is a recipe for guaranteed disaster. generally a part of preliminary design in the design phase. It includes negotiating and B. The Importance of KT in Software balancing of functional and quality requirements on one hand, and possible Architecture Development solutions on the other hand. This means requirements development and software It is agreed that both analysts and software architecture are not subsequent phases that architects play important roles in the are more or less strictly separated, but successful software architecture, and that the instead they are heavily intertwined. There transfer of knowledge is important in the are many reasons describing the importance software architecture development. However, of software architecture phase in software not much is known about KT between development process. Firstly, it is a vehicle for analysts and software architects a setting that communication among stakeholders. is very much knowledge intensive. Initially, Software architecture is a global, often the analyst primarily possesses business graphic, description that can be knowledge, whereas the software architect communicated to the customers, end users, primarily possesses technical (including designers and so on. By developing scenarios architectural) knowledge (Rus and Lindvall, of anticipated use, relevant quality aspects 2002). KT between these two teams invites can be analyzed and discussed with various an intriguing intention for discovery of the flow stakeholders. The software architecture also and nature of the transfer considering the lack supports communication during development. of its descriptions in the literature. The This is consistent with the empirical evidence integration of initial knowledge possessed by by Unphon & Dittrich (2010), where the these teams is seen as a must. More architecture almost always exists as importantly, there are other elements knowledge of people applied and surrounding this process (of KT) alongside communicated answering situated questions the constraints of the environment that need to be taken into consideration. www.ijascse.in Page 3
    • Oct. 31 IJASCSE Vol 1, Issue 3, 2012 Software architecture development is outcome of integration of knowledge where knowledge integration mostly occurs particularly between the analysts and compared to other phases in software software architects. Through KT, both teams development life cycles. It is the encounter of can communicate with each other and two most highlighted roles for developing complete their tasks even when they are software architecture – the analyst and remotely located. Without KT, the software architect teams. Both teams are development of software architecture might specialized in different types of knowledge, be imprecise and does not provide adequate background and capabilities. Although they information to proceed to the next phase of are assigned with different job responsibility, development. they are highly dependent on each other. Making decision is never an easy task. Software architect needs input from the Software architect is held accountable for analyst and vice versa to complete each making early design decisions during other’s objective. But certainly the software architecture development. These dependency that exists between them is not decisions are partly made based on the input only limited to the need for delivering their and requirements provided by the analysts. tasks to develop software architecture. KT is crucially essential as for making these Instead, at the same time it initiates the design decisions, many factors and inputs urgency to learn about each other’s expertise, need to be carefully considered and knowledge and experience, thus creating the accounted. Both teams must provide as much opportunity for KT. As a result, they create information as possible to ensure that they new knowledge and increase their own can come out with the best decision for knowledge possession. Through this software design and at the same time communication, the software engineer who ensuring that the user requirements are shares his knowledge also updates his fulfilled. knowledge (Unphon & Dittrich, 2010). Now that they are well aware on how and where to C. The Context of Non-Collocated Teams in locate and access expertise, they are well Software Architecture Development understood about each other’s accountability, Sundstrom et al. (1990) define teams as the process of developing the software small groups of interdependent individuals architecture will eventually become much smoother, faster and less problematic. who share responsibility for outcomes for their It seems rightly emphasized to rationalize organization. This shared responsibility by team members implies an agreement as to the importance of KT since software the individuals contributing. In many architecture development acts as a vehicle for communication among those who are organizations, the team now serves as the involved. As a blue print that describes the basic unit for transferring and preserving knowledge (Wu et al. 2006). Studies in whole software/system, it is a necessity for it geographically dispersed teams on the other to be effectively delivered and communicated. KT determines this by ensuring that the hand, define non collocated teams as a group software architecture produced is the of geographically distributed and www.ijascse.in Page 4
    • Oct. 31 IJASCSE Vol 1, Issue 3, 2012 organizationally dispersed workers performing non-collocated software architecture one or more tasks that are supported by development. information and communication technology (Hertel, Konradt, & Orlikowski, 2004). Wilson IV. BARRIERS TO EFFECTIVE KT IN NON- (2011) defines distributed team as one whose COLLOCATED SOFTWARE ARCHITECTURE members are separated by distance, such as DEVELOPMENT when team members are in different To date, research in KT has received countries. The distribution is either in (a) time, enormous attention especially in investigating (b) distance, (c) culture, or some combination the barriers or impediments to effective KT of these aspects. Advances in technology (Ko et al., 2005; Wu et al., 2006; Anna et al., have made it easier to organize and manage 2009; Paulin & Suneson, 2012). This dispersed groups of people. And competitive phenomenon is not surprising since the best pressures and the needs of today’s global strategy to implement effective KT is by market workforce have made virtual or identifying and overcoming these distributed teams a necessity for some impediments. Our study takes slightly organizations. As the business environment different approach in that we are not only becomes more global and businesses are determining what the barriers are, but most increasingly in search of more creative ways importantly, we are looking at them from more to reduce operating costs, the concept of positive perspectives. We believe that virtual teams is of paramount importance underneath some of the barriers, lays the (Foley, 2000). Software development hidden potential contribution on teams’ organizations are no exception. In the context capability. Therefore, we decide to use of our research, non-collocated software “external conditions surrounding” KT instead architecture development simply describes of barriers. The following table 1.0 the development of software architecture by summarizes the findings for surrounding non-collocated teams, which in this case the conditions of KT. teams involve the analysts and software architects. TABLE 1. RESULT FOR EXTERNAL CONDITIONS SURROUNDING KT III. METHODOLOGY Percentage External Conditions Frequency We conducted semi-structured interviews (%) with 30 industrial experts ranging from the Physical distance 28 93.3 Functional, experience, analysts, software architects to project and capability 23 76.7 managers from selected MSC (Multimedia differences Super Corridor) organizations in Malaysia. Lacking of time 20 66.7 Lacking of trust 18 60.0 Using a list of barriers identified from the Reluctance to share literature, we constructed appropriate knowledge 13 43.3 questions for the purpose of the interviews. Lacking of motivation 7 23.3 The primary intention was to determine their Low awareness of the value and benefit of agreement in regards to the list we conjecture possessed knowledge 5 16.7 as the most likely to inhibit effective KT in to others www.ijascse.in Page 5
    • Oct. 31 IJASCSE Vol 1, Issue 3, 2012 conditions surrounding KT. A typical nature of As predicted, physical distance was the software project teams (including software most frequently chosen by the participants as architecture development) does not only an external condition surrounding KT. This confined into achieving specified purpose but result is in agreement with Gregory et al. also to work within constraints of time. Time (2009) and Anna et al. (2009) who highlight restrictions have become the possible reason the physical distance as one of the main that drives the teams to hoard their impediments for effective KT. The fact that knowledge rather than transfer and share with two interdependent teams working distantly others. Participants also highlighted the lack from one another has definitely reducing the of time to engage in KT as a result for being ease for KT. The problem with KT becomes too occupied with the assigned task and even more acute as more and more issues reaching the dateline. This comment is arose, particularly when the chances for direct consistent with Michailova and Husted (2003), face-to-face meeting or social communication, in which according to them, people naturally becomes less and less impractical. The fact focus on those tasks that are more beneficial that software architecture development is a to them. There was one participant who also knowledge integration activity, to bridge the commented that due to physical distance, physical gap is very important. This explains they rarely have the time to identify the previous findings of mediums used for KT, colleagues in need of specific knowledge. in which various types of communication By far, lacking of trust has been technologies have been employed to cater nominated by the literature as one of the most the communication problems between the common impediments to effective KT non-collocated teams. (Naftanaila, 2010; Falconer, 2006; Lucas, The findings are continued by the selection 2006; Reige, 2005; Hildreth & Kimble, 2004). of functional, experience and capability According to findings in Reige (2005), there differences as second most frequently chosen are two terms concerning this issue. Firstly, external conditions surrounding KT. Software there is a lack of trust in people because they architecture development witnesses the may misuse knowledge or take unjust credit integration of team members from diverse for it and secondly there is a lack of trust in backgrounds, experiences, and capabilities. accuracy and credibility of knowledge due to In addition, being assigned with different roles the source, which the latter was studied by and functions has consequently increased the Sarker et al. (2002), in their research that gap between teams. Sarker et al. (2002), in investigate KT among information system their study found that difference in individual development (ISD) team members. capabilities undermines KT. Reige (2005) Naftanaila (2010) asserts that most people also mentions the difference in experience in are unlikely to share their knowledge and his study regarding barriers in sharing of experience without a feeling of trust. This is knowledge. particularly true when according to some The numbers are closely entailed by participants, lack of trust is mainly due to lack lacking of time (Roux et al. 2006; Reige, of social communication between teams, 2005; Ramirez, 2007) as one of the external since they are not physically collocated. www.ijascse.in Page 6
    • Oct. 31 IJASCSE Vol 1, Issue 3, 2012 Social communication often realized through perceived by the participants is lack of informal networks, which is very limited motivation. There is an indication that it is the considering the nature of non-collocated primary trigger for KT (Ajmal & Koskinen, teams. Additionally, “…the nature of inter 2008; Frey & Osterloh, 2000;). Many studies community social relation…where people have been conducted to investigate the extent have limited sense of shared identity, makes of effect the lack of motivation has, upon KT the existence of trust less likely…” (Hildreth & (Mclaughlin et al., 2008; Disterer, 2001; Frey Kimble, 2004). & Osterloh, 2000). Lack of motivation, particularly extrinsic motivation has been Reluctance to share knowledge can be raised by many as closely related with possibly caused by the specialized nature of managerial or organizational issues. This type the knowledge both analyst and software of motivation is about expected organizational architect teams possessed. The specialist rewards and reciprocal benefits. On the other nature of their knowledge, combined with the hand, intrinsic motivation refers to knowledge extensive lack of interaction which had been self-efficacy and enjoyment in helping others typical, meant that they had very poor and is very important to help perform complex understanding of how other functions worked, or creative tasks such as developing or what their constraints or requirements were architecture. In neither ways, both team (Hildreth & Kimble, 2004). When asked leader and project manager plays a significant further about the extent of their agreement role in cultivating the sense of motivation concerning this as a reason why there is a among team members. In order to fulfill their reluctance to share knowledge with others, tasks during software architecture there were seemed to be no deniable. development, KT between teams should be of However, there were few participants who importance despite of physical distance. An added personal gain and power (job security) observation reported by one participant as the causes to become reluctant to share regarding this is that KT has always been knowledge. This finding is in line with seen as laborious especially in terms of time Paghaleh et al. (2011). Another finding and effort. The tendency to fully concentrate perceived from the participants concerning in one’s work in order to catch the dateline the cause for this reluctance is the inability to explains why KT is seen in such a way. It is absorb new knowledge due to incompetence important to note, as is mentioned by Milne or limitation in their existing stock of (2007), that individuals are often motivated to knowledge: keep their tacit knowledge for themselves “Sometimes, we feel hesitant to share rather than share it. In software architecture because we are not so sure we can correctly development, both analyst and software convey to others what we really want to tell architect teams need to be able to exploit them …it is better to keep that to ourselves these tacit knowledge. than giving them the wrong ideas” The participants also chose low awareness of the value and benefit as one of the external Another external condition surrounding KT conditions surrounding KT, during software during software architecture development as architecture development. One possible www.ijascse.in Page 7
    • Oct. 31 IJASCSE Vol 1, Issue 3, 2012 reason that drives this issue is that they do based organisations. In McCaffer, Ron (Ed.) not believe these benefits from transferring Proceedings of the 2009 International Conference knowledge. Even worst, they did not actually on Global Innovation in Construction Proceedings, Loughborough University UK, Holywell Park, experience KT although they make claim that Loughborough University, 220-230. they have. As displayed in typical scenario of 3. Appelbaum SH, Steed, AJ (2005) The critical general software development teams, they success factors in the client-consulting often create island of knowledge due to low relationship. Journal of Management Development awareness that the knowledge possessed by 24(1), 68-93. the other teams is valuable and useful, which 4. Argote L and Todorova G (2007) Organizational can help accelerate the completion of their learning: Review and future directions. G. P. Hodgkinson, J. K. Ford, eds. International Review tasks. Parallel to this, the intention to transfer of Industrial and Organizational Psychology. knowledge is refrained by the thought that Wiley, New York, 193–234. they already possessed a certain level of 5. Darr ED and Kurtzberg TR (2000) An Investigation knowledge, and thus KT is not much in need. of Partner Similarity Dimensions on Knowledge When asked their opinion regarding this, the Transfer. Organizational Behavior and Human participants were unanimously agreed to have Decision Processes, 82(1), 28-44. been in such state of condition. A few added 6. Davenport TH and Prusak L (2000) Working Knowledge: How Organizations Manage What by stressing their uncertainty of the presence They Know. Harvard Business School Press, of KT, due to lack of understanding of the Boston, USA. process involved. 7. Disterer G (2001) Individual and Social Barriers to Knowledge Transfer. Conference Proceedings IV. CONCLUSIONS 34th Annual Hawaii International Conference on The main contribution of this paper lies in System Sciences, Los Alamitos, CA:IEEE Press. the understanding of the barriers or external 8. Falconer L (2006) Organizational learning, tacit information, and e-learning: a review. The conditions surrounding KT particularly in non- Learning Organization, 13(2), 140-151. collocated software architecture development. 9. Foley SP (2000) The Boundless Team: Virtual It alarms the presence of these external Teaming. Seminar in Industrial and Engineering conditions so that those involved may prepare Systems, Master of Science in Technology (MST) better strategy to facilitate effective KT in the Graduate Program, Northern Kentucky University. future that can benefit each one of them. It 10. Gregory R, Beck R and Prifling M (2009) also serves as a useful base for prospective Breaching the knowledge transfer blockade in it researchers to expand future research in offshore outsourcing projects: A case from the financial services industry‘. Proceedings of the barriers of KT. 42nd Hawaii International Conference on System Sciences. Wikoloa, Big Island, Hawaii. REFERENCES 11. Hertel G, Konradt U, and Orlikowski B (2004) Managing Distance by Interdependence: Goal 1. Ajmal MM and Koskinen KU (2008) Knowledge Setting, Task Interdependence and Team-based transfer in project-based organizations: an Rewards in Virtual Teams. European Journal of organizational culture perspective. Project Work and Organizational Psychology, 13(1), 1-28. Management Journal, 39(1), 7-15. 12. Hildreth P, Kimble C (2004) Knowledge Networks: 2. Anna W, Bambang T, Glen MD, Chen L (2009) Innovation through Communities of Practice. IGI Barriers to effective knowledge transfer in project- Global. www.ijascse.in Page 8
    • Oct. 31 IJASCSE Vol 1, Issue 3, 2012 13. Jimenez M, Piattini M, Vizcaino A (2009) 24. Paulin D and Suneson K (2012) Knowledge Challenges and Improvements in Distributed Transfer, Knowledge Sharing and Knowledge Software Development: A Systematic Review. Barriers – Three Blurry Terms in KM. The Advances in Software Engineering. Electronic Journal of Knowledge Management 14. Joshi, KD and Sarker S (2006) Examining the 10(1), 81-91. Role of Knowledge, Source, Recipient, Relational, 25. Prikladnicki R, Audy JLN and Evaristo JR (2003) and Situational Context on Knowledge Transfer Distributed software development: toward an among Face-to-Face ISD Teams. In: HICSS 2006 understanding of the relationship between project - 39th Hawaii International Conference on team, users and customers. Proceedings of the Systems Science 4-7 January, 2006, Kauai, HI, 5th International Conference on Enterprise USA. Information Systems (ICEIS 03), 417–423. 15. Ko DG, Kirsch LJ, and King WR (2005). 26. Ramirez A (2007) To Blog or Not to Blog: Antecedents of Knowledge Transfer From Understanding and Overcoming the Challenge of Consultants to Clients in Enterprise System Knowledge Sharing, Journal of Knowledge Implementations. MIS Quarterly, 29(1), 59-85. Management Practice, 8(1). 16. Lucas LM (2006) The role of culture on knowledge 27. Riege A (2005) Three-dozen knowledge sharing transfer: the case of the multinational corporation. barriers managers must consider. Journal of The Learning Organization, 13(3), 257-275. Knowledge Management, 9(3), 18-35. 17. McLaughlin S, Paton RA and Macbeth DK (2008) 28. Roux DJ, Rogers KH, Biggs HC, Ashton PJ and Barrier impact on organizational learning within Sergeant A (2006) Bridging the science– complex organizations. Journal of Knowledge management divide: moving from unidirectional Management 12(2), 107-123. knowledge transfer to knowledge interfacing and 18. Michailova S and Husted K (2003) Knowledge sharing. Ecology and Society 11(1), 4. sharing in Russian companies with western 29. Rus I and Lindvall M (2002) Knowledge participation. Management International, 6(2), 19- Management in Software Engineering. IEEE 28. Software, 19(3), 40-59. 19. Milne P (2007) Motivation, incentives and 30. Sarker S, Sarker S, Nicholson D, and Joshi KD organisational culture. Journal of Knowledge (2002) Knowledge Transfer in Virtual Information Management, 11, 28-38. Systems Development Teams: An Empirical 20. Naftanaila I (2010) Factors affecting Knowledge Examination of Key Enablers. Proceedings of the Transfer in Project Environment. Review of Hawaii International Conference on System International Comparative Management, 11(5), Sciences (HICSS-36), Big Island, Hawaii. 834. 31. Sundstrom E, De Meuse KP and Futrell D (1990) 21. Newell S (2005) Knowledge Transfer and Work teams: applications and effectiveness, Learning: Problems of Knowledge Transfer American Psychologist, February, 120 – 133. Associated with Trying to Short-circuit the 32. Uphorn H and Dittrich Y (2010) Software Learning Cycle. Journal of Information Systems architecture awareness in long term software and Technology Management. 2(3), 275-290. product evaluation. The Journal of Systems and 22. Osterloh M, Frey BS (2000) Motivation, knowledge Software, 83. transfer, and organizational form. Organization 33. Van der Ven JS, Jansen GJ, Nijhuis JAG, Bosch J Science, 11(5), 38-50. (2006) Design Decisions: The Bridge between 23. Paghaleh MJ, Shafizadeh E and Mohammadi M Rationale and Architecture. In Rationale (2011) Information Technology and its Management in Software Engineering. Allen H. Deficiencies in Sharing Organizational Knowledge. Dutoit, Raymond McCall, Ivan Mistrik, Barbara International Journal of Business and Social peach (Eds.), 329-246. Springer Verlag. Science 2(8). 34. Wu WL, Hsu BF and Yeh RS (2006) Fostering the determinants of knowledge transfer: a team-level www.ijascse.in Page 9
    • Oct. 31 IJASCSE Vol 1, Issue 3, 2012 analysis. Journal of Information Science, 33(3) 326–339.35. Wilson, E. M. (2011). Dimensions of Team Distribution within a Software Team. Book Chapter in Distributed Team Collaboration in Organizations: Emerging Tools and Practices- IGI Global. www.ijascse.in Page 10