barriers surrounding knowledge transfer in non-collocated software architecture development

IJASCSE Vol 1, Issue 3, 2012

www.ijascse.in

Oct. 31

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 been endeavored to investigate the barriers of knowledge transfer (KT) that exist in various level within organizations. The structure of non-collocated team amplifies the complication of the KT. Despite efforts put forth, not much is known about KT in software architecture development, a setting that is very much knowledge intensive. KT is crucially essential as for making design decisions in developing software architecture, many factors and inputs need to be carefully considered and accounted. The purpose of this paper is to discuss and outline our perspectives regarding the barriers towards effective KT in this particular environment. We believe that the outcome will deposit valuable contribution particularly in the study of KT in non-collocated software architecture development and enrich the knowledge management literature in general.

Keywords-Keywords: Knowledge transfer (KT), non-collocated software architecture, barriers.

I. INTRODUCTION

Today, the development of software has evolved tremendously from being concentrated at a single site to being geographically dispersed. The distance between the different teams can vary from a few meters (when the teams work in adjacent buildings) to different continents (Prikladnicki, 2003). Such distributed environment allows team members to be located in various remote sites during the software lifecycle, thus making up a network of distant sub-teams (Jimenez et al. 2009). In some cases, these teams may be members of the same organization; in other cases, collaboration or outsourcing involving different organizations may exist. The primary influence to this phenomenon stems from huge savings or sound business reasons that include reduction in workspace costs, increased in productivity, labor cost, better access to global markets and environmental benefits. Notwithstanding these benefits, such environment is fraught with challenges.

Software architecture is about making design decisions based from the user requirements. Typically these design 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

Oct. 31

the important knowledge underlying the decisions (the architectural artifact), including the evaluated alternatives, trade-offs and rationale about the decision made. Amplified by the distance between teams, the interdependencies between them are challenged by the decreased of opportunities for face-to-face interaction while relying heavily on the documentation. The challenge continues in terms of limited utilization of the knowledge areas used and exchanged due to the arising difficulties in establishing an effective medium for KT between non-collocated teams to connect with each other. Additionally, the intensification of these challenges is increased by the differences in capabilities and work experiences that exist between the teams. Moreover, the importance of software architecture development is acknowledged for it is where the integration of knowledge mostly happens. It does not only provide the blue print of the whole system or software to be developed, but it can determine the success or failure of the development itself. In this paper, our interest is geared into understanding the barriers surrounding effective KT in non-collocated software architecture development. It is our belief that in order to achieve effective KT particularly between non-collocated teams, it is crucial that these obstacles must first be understood so that new perspectives and solutions either to overcome or increase those impacts on KT can be provided.

In the next sections, the current body of literature reviewed in this study is explained, and followed by the discussion on barriers to effective KT in non-collocated software architecture development. The paper then ends with conclusion section.

II. KNOWLEDGE TRANSFER (KT)

KT is the dissemination of knowledge from one individual or group to another within the organization. It may be purposely transferred, or it may occur as an unintended outcome of other activities (Joshi et al., 2006). As asserted by Appelbaum and Steed (2005), “…knowledge are best learned through exposure to and experience…”. This is further supported by Newell (2005) where according to her, KT implies that each individual or group or organizational unit need not learn from scratch but can rather learn from the experiences of others. Therefore in this paper, we adopted the definition of KT as the process through which one unit learns from the experiences of others (Argote & Todorova, 2007; Darr & Kurtzberg, 2000). From our perspective, KT is about the integration of knowledge and experience between people from various backgrounds and expertise. This is in line with the knowledge intensive perseverance in software architecture development, which demands such integration. These people need not only sharing but also learning from each others’ experience to ensure that they can accomplish their tasks. It is also believed that the definition of KT must cover the use of knowledge on the part of the receiver (Devanport & Prusak, 2000; Darr & Kurtzberg, 2000) and not simply by sharing of the knowledge between units. This is particularly important to distinct the overlapping terms between KT and just knowledge sharing, and also makes it easier to verify that KT has occurred by investigating those cases involving use, which can be observed and measured (Darr & Kurtzberg, 2000). Given all these definitions, we can foresee that the role KT plays is critical to ensure the continuity of


www.ijascse.in

Oct. 31

success to the organization, and also to the capability development of those involved in KT.

A. Software Architecture

The definition of software architecture includes all the usual technical activities associated with design: understanding requirements and qualities; extracting architecturally significant requirements; making choices; synthesizing a solution; exploring alternatives and validating them (Uphorn & Dittrich, 2010). In software development process, software architecture is generally a part of preliminary design in the design phase. It includes negotiating and balancing of functional and quality requirements on one hand, and possible solutions on the other hand. This means requirements development and software architecture are not subsequent phases that are more or less strictly separated, but instead they are heavily intertwined. There are many reasons describing the importance of software architecture phase in software development process. Firstly, it is a vehicle for communication among stakeholders. Software architecture is a global, often graphic, description that can be communicated to the customers, end users, designers and so on. By developing scenarios of anticipated use, relevant quality aspects can be analyzed and discussed with various stakeholders. The software architecture also supports communication during development. This is consistent with the empirical evidence by Unphon & Dittrich (2010), where the architecture almost always exists as knowledge of people applied and communicated answering situated questions

and problems. Secondly, it captures early design decisions. In software architecture, the global structure of the system has been decided upon, through the explicit assignment of functionality to components of the architecture. These early design decisions are important since their ramifications are felt in all subsequent phases. It is therefore paramount to assess the quality at the earliest possible moment. Thirdly, architecture is the primary carrier of a software system's quality attributes such as performance or reliability. The right architecture is the linchpin for software project accomplishment whereby the wrong one is a recipe for guaranteed disaster.

B. The Importance of KT in Software

Architecture Development

It is agreed that both analysts and software architects play important roles in the successful software architecture, and that the transfer of knowledge is important in the software architecture development. However, not much is known about KT between analysts and software architects a setting that is very much knowledge intensive. Initially, the analyst primarily possesses business knowledge, whereas the software architect primarily possesses technical (including architectural) knowledge (Rus and Lindvall, 2002). KT between these two teams invites an intriguing intention for discovery of the flow and nature of the transfer considering the lack of its descriptions in the literature. The integration of initial knowledge possessed by these teams is seen as a must. More importantly, there are other elements surrounding this process (of KT) alongside the constraints of the environment that need to be taken into consideration.


www.ijascse.in

Oct. 31

Software architecture development is where knowledge integration mostly occurs compared to other phases in software development life cycles. It is the encounter of two most highlighted roles for developing software architecture – the analyst and software architect teams. Both teams are specialized in different types of knowledge, background and capabilities. Although they are assigned with different job responsibility, they are highly dependent on each other. Software architect needs input from the analyst and vice versa to complete each other’s objective. But certainly the dependency that exists between them is not only limited to the need for delivering their tasks to develop software architecture. Instead, at the same time it initiates the urgency to learn about each other’s expertise, knowledge and experience, thus creating the opportunity for KT. As a result, they create new knowledge and increase their own knowledge possession. Through this communication, the software engineer who shares his knowledge also updates his knowledge (Unphon & Dittrich, 2010). Now that they are well aware on how and where to locate and access expertise, they are well understood about each other’s accountability, the process of developing the software architecture will eventually become much smoother, faster and less problematic.

It seems rightly emphasized to rationalize the importance of KT since software architecture development acts as a vehicle for communication among those who are involved. As a blue print that describes the whole software/system, it is a necessity for it to be effectively delivered and communicated. KT determines this by ensuring that the software architecture produced is the

outcome of integration of knowledge particularly between the analysts and software architects. Through KT, both teams can communicate with each other and complete their tasks even when they are remotely located. Without KT, the development of software architecture might be imprecise and does not provide adequate information to proceed to the next phase of development.

Making decision is never an easy task. Software architect is held accountable for making early design decisions during software architecture development. These decisions are partly made based on the input and requirements provided by the analysts. KT is crucially essential as for making these design decisions, many factors and inputs need to be carefully considered and accounted. Both teams must provide as much information as possible to ensure that they can come out with the best decision for software design and at the same time ensuring that the user requirements are fulfilled.

C. The Context of Non-Collocated Teams in

Software Architecture Development

Sundstrom et al. (1990) define teams as small groups of interdependent individuals who share responsibility for outcomes for their organization. This shared responsibility by team members implies an agreement as to the individuals contributing. In many organizations, the team now serves as the basic unit for transferring and preserving knowledge (Wu et al. 2006). Studies in geographically dispersed teams on the other hand, define non collocated teams as a group of geographically distributed and


www.ijascse.in

Oct. 31

organizationally dispersed workers performing one or more tasks that are supported by information and communication technology (Hertel, Konradt, & Orlikowski, 2004). Wilson (2011) defines distributed team as one whose members are separated by distance, such as when team members are in different countries. The distribution is either in (a) time, (b) distance, (c) culture, or some combination of these aspects. Advances in technology have made it easier to organize and manage dispersed groups of people. And competitive pressures and the needs of today’s global market workforce have made virtual or distributed teams a necessity for some organizations. As the business environment becomes more global and businesses are increasingly in search of more creative ways to reduce operating costs, the concept of virtual teams is of paramount importance (Foley, 2000). Software development organizations are no exception. In the context of our research, non-collocated software architecture development simply describes the development of software architecture by non-collocated teams, which in this case the teams involve the analysts and software architects.

III. METHODOLOGY

We conducted semi-structured interviews with 30 industrial experts ranging from the analysts, software architects to project managers from selected MSC (Multimedia Super Corridor) organizations in Malaysia. Using a list of barriers identified from the literature, we constructed appropriate questions for the purpose of the interviews. The primary intention was to determine their agreement in regards to the list we conjecture as the most likely to inhibit effective KT in

non-collocated software architecture development.

IV. BARRIERS TO EFFECTIVE KT IN NON-COLLOCATED SOFTWARE ARCHITECTURE

DEVELOPMENT

To date, research in KT has received enormous attention especially in investigating the barriers or impediments to effective KT (Ko et al., 2005; Wu et al., 2006; Anna et al., 2009; Paulin & Suneson, 2012). This phenomenon is not surprising since the best strategy to implement effective KT is by identifying and overcoming these impediments. Our study takes slightly different approach in that we are not only determining what the barriers are, but most importantly, we are looking at them from more positive perspectives. We believe that underneath some of the barriers, lays the hidden potential contribution on teams’ capability. Therefore, we decide to use “external conditions surrounding” KT instead of barriers. The following table 1.0 summarizes the findings for surrounding conditions of KT.

TABLE 1. RESULT FOR EXTERNAL CONDITIONS

SURROUNDING KT

External Conditions Frequency Percentage

(%)

Physical distance 28 93.3 Functional, experience, and capability differences

23 76.7

Lacking of time 20 66.7 Lacking of trust 18 60.0 Reluctance to share knowledge

13 43.3

Lacking of motivation 7 23.3 Low awareness of the value and benefit of possessed knowledge to others

5 16.7


www.ijascse.in

Oct. 31

As predicted, physical distance was the

most frequently chosen by the participants as an external condition surrounding KT. This result is in agreement with Gregory et al. (2009) and Anna et al. (2009) who highlight the physical distance as one of the main impediments for effective KT. The fact that two interdependent teams working distantly from one another has definitely reducing the ease for KT. The problem with KT becomes even more acute as more and more issues arose, particularly when the chances for direct face-to-face meeting or social communication, becomes less and less impractical. The fact that software architecture development is a knowledge integration activity, to bridge the physical gap is very important. This explains the previous findings of mediums used for KT, in which various types of communication technologies have been employed to cater the communication problems between the non-collocated teams.

The findings are continued by the selection of functional, experience and capability differences as second most frequently chosen external conditions surrounding KT. Software architecture development witnesses the integration of team members from diverse backgrounds, experiences, and capabilities. In addition, being assigned with different roles and functions has consequently increased the gap between teams. Sarker et al. (2002), in their study found that difference in individual capabilities undermines KT. Reige (2005) also mentions the difference in experience in his study regarding barriers in sharing of knowledge.

The numbers are closely entailed by lacking of time (Roux et al. 2006; Reige, 2005; Ramirez, 2007) as one of the external

conditions surrounding KT. A typical nature of software project teams (including software architecture development) does not only confined into achieving specified purpose but also to work within constraints of time. Time restrictions have become the possible reason that drives the teams to hoard their knowledge rather than transfer and share with others. Participants also highlighted the lack of time to engage in KT as a result for being too occupied with the assigned task and reaching the dateline. This comment is consistent with Michailova and Husted (2003), in which according to them, people naturally focus on those tasks that are more beneficial to them. There was one participant who also commented that due to physical distance, they rarely have the time to identify colleagues in need of specific knowledge.

By far, lacking of trust has been nominated by the literature as one of the most common impediments to effective KT (Naftanaila, 2010; Falconer, 2006; Lucas, 2006; Reige, 2005; Hildreth & Kimble, 2004). According to findings in Reige (2005), there are two terms concerning this issue. Firstly, there is a lack of trust in people because they may misuse knowledge or take unjust credit for it and secondly there is a lack of trust in accuracy and credibility of knowledge due to the source, which the latter was studied by Sarker et al. (2002), in their research that investigate KT among information system development (ISD) team members. Naftanaila (2010) asserts that most people are unlikely to share their knowledge and experience without a feeling of trust. This is particularly true when according to some participants, lack of trust is mainly due to lack of social communication between teams, since they are not physically collocated.


www.ijascse.in

Oct. 31

Social communication often realized through informal networks, which is very limited considering the nature of non-collocated teams. Additionally, “…the nature of inter community social relation…where people have limited sense of shared identity, makes the existence of trust less likely…” (Hildreth & Kimble, 2004).

Reluctance to share knowledge can be

possibly caused by the specialized nature of the knowledge both analyst and software architect teams possessed. The specialist nature of their knowledge, combined with the extensive lack of interaction which had been typical, meant that they had very poor understanding of how other functions worked, or what their constraints or requirements were (Hildreth & Kimble, 2004). When asked further about the extent of their agreement concerning this as a reason why there is a reluctance to share knowledge with others, there were seemed to be no deniable. However, there were few participants who added personal gain and power (job security) as the causes to become reluctant to share knowledge. This finding is in line with Paghaleh et al. (2011). Another finding perceived from the participants concerning the cause for this reluctance is the inability to absorb new knowledge due to incompetence or limitation in their existing stock of knowledge:

“Sometimes, we feel hesitant to share because we are not so sure we can correctly convey to others what we really want to tell them …it is better to keep that to ourselves than giving them the wrong ideas”

Another external condition surrounding KT

during software architecture development as

perceived by the participants is lack of motivation. There is an indication that it is the primary trigger for KT (Ajmal & Koskinen, 2008; Frey & Osterloh, 2000;). Many studies have been conducted to investigate the extent of effect the lack of motivation has, upon KT (Mclaughlin et al., 2008; Disterer, 2001; Frey & Osterloh, 2000). Lack of motivation, particularly extrinsic motivation has been raised by many as closely related with managerial or organizational issues. This type of motivation is about expected organizational rewards and reciprocal benefits. On the other hand, intrinsic motivation refers to knowledge self-efficacy and enjoyment in helping others and is very important to help perform complex or creative tasks such as developing architecture. In neither ways, both team leader and project manager plays a significant role in cultivating the sense of motivation among team members. In order to fulfill their tasks during software architecture development, KT between teams should be of importance despite of physical distance. An observation reported by one participant regarding this is that KT has always been seen as laborious especially in terms of time and effort. The tendency to fully concentrate in one’s work in order to catch the dateline explains why KT is seen in such a way. It is important to note, as is mentioned by Milne (2007), that individuals are often motivated to keep their tacit knowledge for themselves rather than share it. In software architecture development, both analyst and software architect teams need to be able to exploit these tacit knowledge.

The participants also chose low awareness of the value and benefit as one of the external conditions surrounding KT, during software architecture development. One possible


www.ijascse.in

Oct. 31

reason that drives this issue is that they do not believe these benefits from transferring knowledge. Even worst, they did not actually experience KT although they make claim that they have. As displayed in typical scenario of general software development teams, they often create island of knowledge due to low awareness that the knowledge possessed by the other teams is valuable and useful, which can help accelerate the completion of their tasks. Parallel to this, the intention to transfer knowledge is refrained by the thought that they already possessed a certain level of knowledge, and thus KT is not much in need. When asked their opinion regarding this, the participants were unanimously agreed to have been in such state of condition. A few added by stressing their uncertainty of the presence of KT, due to lack of understanding of the process involved.

IV. CONCLUSIONS

The main contribution of this paper lies in the understanding of the barriers or external conditions surrounding KT particularly in non-collocated software architecture development. It alarms the presence of these external conditions so that those involved may prepare better strategy to facilitate effective KT in the future that can benefit each one of them. It also serves as a useful base for prospective researchers to expand future research in barriers of KT.

REFERENCES

1. Ajmal MM and Koskinen KU (2008) Knowledge transfer in project-based organizations: an organizational culture perspective. Project Management Journal, 39(1), 7-15.

2. Anna W, Bambang T, Glen MD, Chen L (2009) Barriers to effective knowledge transfer in project-

based organisations. In McCaffer, Ron (Ed.) Proceedings of the 2009 International Conference on Global Innovation in Construction Proceedings, Loughborough University UK, Holywell Park, Loughborough University, 220-230.

3. Appelbaum SH, Steed, AJ (2005) The critical success factors in the client-consulting relationship. Journal of Management Development 24(1), 68-93.

4. Argote L and Todorova G (2007) Organizational learning: Review and future directions. G. P. Hodgkinson, J. K. Ford, eds. International Review of Industrial and Organizational Psychology. Wiley, New York, 193–234.

5. Darr ED and Kurtzberg TR (2000) An Investigation of Partner Similarity Dimensions on Knowledge Transfer. Organizational Behavior and Human Decision Processes, 82(1), 28-44.

6. Davenport TH and Prusak L (2000) Working Knowledge: How Organizations Manage What They Know. Harvard Business School Press, Boston, USA.

7. Disterer G (2001) Individual and Social Barriers to Knowledge Transfer. Conference Proceedings 34th Annual Hawaii International Conference on System Sciences, Los Alamitos, CA:IEEE Press.

8. Falconer L (2006) Organizational learning, tacit information, and e-learning: a review. The Learning Organization, 13(2), 140-151.

9. Foley SP (2000) The Boundless Team: Virtual Teaming. Seminar in Industrial and Engineering Systems, Master of Science in Technology (MST) Graduate Program, Northern Kentucky University.

10. Gregory R, Beck R and Prifling M (2009) Breaching the knowledge transfer blockade in it offshore outsourcing projects: A case from the financial services industry‘. Proceedings of the 42nd Hawaii International Conference on System Sciences. Wikoloa, Big Island, Hawaii.

11. Hertel G, Konradt U, and Orlikowski B (2004) Managing Distance by Interdependence: Goal Setting, Task Interdependence and Team-based Rewards in Virtual Teams. European Journal of Work and Organizational Psychology, 13(1), 1-28.

12. Hildreth P, Kimble C (2004) Knowledge Networks: Innovation through Communities of Practice. IGI Global.


www.ijascse.in

Oct. 31

13. Jimenez M, Piattini M, Vizcaino A (2009) Challenges and Improvements in Distributed Software Development: A Systematic Review. Advances in Software Engineering.

14. Joshi, KD and Sarker S (2006) Examining the Role of Knowledge, Source, Recipient, Relational, and Situational Context on Knowledge Transfer among Face-to-Face ISD Teams. In: HICSS 2006 - 39th Hawaii International Conference on Systems Science 4-7 January, 2006, Kauai, HI, USA.

15. Ko DG, Kirsch LJ, and King WR (2005). Antecedents of Knowledge Transfer From Consultants to Clients in Enterprise System Implementations. MIS Quarterly, 29(1), 59-85.

16. Lucas LM (2006) The role of culture on knowledge transfer: the case of the multinational corporation. The Learning Organization, 13(3), 257-275.

17. McLaughlin S, Paton RA and Macbeth DK (2008) Barrier impact on organizational learning within complex organizations. Journal of Knowledge Management 12(2), 107-123.

18. Michailova S and Husted K (2003) Knowledge sharing in Russian companies with western participation. Management International, 6(2), 19-28.

19. Milne P (2007) Motivation, incentives and organisational culture. Journal of Knowledge Management, 11, 28-38.

20. Naftanaila I (2010) Factors affecting Knowledge Transfer in Project Environment. Review of International Comparative Management, 11(5), 834.

21. Newell S (2005) Knowledge Transfer and Learning: Problems of Knowledge Transfer Associated with Trying to Short-circuit the Learning Cycle. Journal of Information Systems and Technology Management. 2(3), 275-290.

22. Osterloh M, Frey BS (2000) Motivation, knowledge transfer, and organizational form. Organization Science, 11(5), 38-50.

23. Paghaleh MJ, Shafizadeh E and Mohammadi M (2011) Information Technology and its Deficiencies in Sharing Organizational Knowledge. International Journal of Business and Social Science 2(8).

24. Paulin D and Suneson K (2012) Knowledge Transfer, Knowledge Sharing and Knowledge Barriers – Three Blurry Terms in KM. The Electronic Journal of Knowledge Management 10(1), 81-91.

25. Prikladnicki R, Audy JLN and Evaristo JR (2003) Distributed software development: toward an understanding of the relationship between project team, users and customers. Proceedings of the 5th International Conference on Enterprise Information Systems (ICEIS '03), 417–423.

26. Ramirez A (2007) To Blog or Not to Blog: Understanding and Overcoming the Challenge of Knowledge Sharing, Journal of Knowledge Management Practice, 8(1).

27. Riege A (2005) Three-dozen knowledge sharing barriers managers must consider. Journal of Knowledge Management, 9(3), 18-35.

28. Roux DJ, Rogers KH, Biggs HC, Ashton PJ and Sergeant A (2006) Bridging the science–management divide: moving from unidirectional knowledge transfer to knowledge interfacing and sharing. Ecology and Society 11(1), 4.

29. Rus I and Lindvall M (2002) Knowledge Management in Software Engineering. IEEE Software, 19(3), 40-59.

30. Sarker S, Sarker S, Nicholson D, and Joshi KD (2002) Knowledge Transfer in Virtual Information Systems Development Teams: An Empirical Examination of Key Enablers. Proceedings of the Hawaii International Conference on System Sciences (HICSS-36), Big Island, Hawaii.

31. Sundstrom E, De Meuse KP and Futrell D (1990) Work teams: applications and effectiveness, American Psychologist, February, 120 – 133.

32. Uphorn H and Dittrich Y (2010) Software architecture awareness in long term software product evaluation. The Journal of Systems and Software, 83.

33. Van der Ven JS, Jansen GJ, Nijhuis JAG, Bosch J (2006) Design Decisions: The Bridge between Rationale and Architecture. In Rationale Management in Software Engineering. Allen H. Dutoit, Raymond McCall, Ivan Mistrik, Barbara peach (Eds.), 329-246. Springer Verlag.

34. Wu WL, Hsu BF and Yeh RS (2006) Fostering the determinants of knowledge transfer: a team-level


www.ijascse.in

Oct. 31

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.

barriers surrounding knowledge transfer in non-collocated software architecture development

Documents