The Journal of Systems and Software 83 (2010) 67–76

Contents lists available at ScienceDirect

The Journal of Systems and Software

journal homepage: www.elsevier.com/locate/jss

From integration to composition: On the impact of software product lines,

global development and ecosystems
Jan Bosch a,*, Petra Bosch-Sijtsema b,c
a
Intuit Inc., Mountain View, CA, USA
b
Helsinki University of Technology, Finland
c
Visiting Scholar Stanford University, Stanford, CA, USA

a r t i c l e i n f o a b s t r a c t

Article history: Three trends accelerate the increase in complexity of large-scale software development, i.e. software
Received 8 November 2008 product lines, global development and software ecosystems. For the case study companies we studied,
Received in revised form 21 May 2009 these trends caused several problems, which are organized around architecture, process and organiza-
Accepted 26 June 2009
tion, and the problems are related to the efficiency and effectiveness of software development as these
Available online 7 July 2009
companies used too integration-centric approaches. We present five approaches to software develop-
ment, organized from integration-centric to composition-oriented and describe the areas of applicability.
Keywords:
Ó 2009 Elsevier Inc. All rights reserved.
Software product lines
Software ecosystems
Global development
Software integration
Software composition

1. Introduction adoption of development centers in Asia, e.g. India, and other con-
tinents has elevated the complexity of dependency management to
For most software systems companies, large-scale software a new level. Finally, especially on the internet, but also in other do-
development is complicated, expensive, slow and unpredictable. mains, the importance of building a software ecosystem, i.e. a com-
Four decades of software engineering research have resulted in a munity of 3rd party application developers, around a successful
wide range of techniques to manage the complexity of software product, is becoming increasingly popular and central to the strat-
systems development. However, the growth in size of modern soft- egy of many companies. The consequence, however, is that the
ware systems and the scale of the R&D organizations responsible complexity of software development is increased due to the depen-
for these systems is such that we constantly need new approaches dencies between the platform company and the 3rd party
to manage the complexity. developers.
Now, however, we can identify three trends that further accel- Based on empirical studies that we performed at several case
erate the complexity of software development and we need to ana- study companies, mostly through action research, we have come
lyze and understand the resulting challenge even better than to the conclusion that many of the challenges that exist in large-
earlier. The first trend is the wide-spread adoption of software scale software development are the consequence of the organiza-
product lines. Over the last decade, the structured approach to in- tion applying an overly integration-centric approach. A significant
tra-organizational reuse of software assets has reached a new level simplification of software development can be achieved by transi-
of sophistication. However, the adoption of software product lines tioning from an integration-centric approach to composition-ori-
also brings a new level of dependency in the organization that did ented approach to software development. However, achieving
not exist in a product-centric approach, causing added complexity. this transition requires deep understanding because of the close
The second trend is the broad globalization of software develop- interconnection between architecture, process and organization.
ment in many organizations. Although especially global companies Consequently, we discuss all these factors and their relationship
have always had distributed development, the industry-wide in this paper.
The contribution of the paper is threefold. First, we provide a
detailed description of the three main trends that are driving and
* Corresponding author. even accelerating complexity in modern large-scale software
E-mail addresses: [email protected] (J. Bosch), [email protected] (P. Bosch- development. Second, we analyze the architectural, process and
Sijtsema).
organizational problems that an organization may experience
URL: http://www.janbosch.com.

0164-1212/$ - see front matter Ó 2009 Elsevier Inc. All rights reserved.
doi:10.1016/j.jss.2009.06.051
68 J. Bosch, P. Bosch-Sijtsema / The Journal of Systems and Software 83 (2010) 67–76

when it applies the wrong approach to its software development. front-end of the development cycle, plans and roadmaps are
Finally, we present five approaches to large-scale software devel- shared, discussed and aligned between the teams. During develop-
opment, organized along a continuum ranging from integration- ment, often interaction takes place to coordinate interfaces and to
centric to fully composition-oriented. Although the approaches in verify that next versions of components are still compatible, even
themselves are not necessarily novel, our framework in which though these are under development. At the end of the develop-
we present them as well as our discussion of applicability and ment cycle, each product team aims to integrate the platform
the implications on architecture, process and organizations is. and product-specific components into a reliable and consistent
The remainder of the paper is organized as follows. The next product (see, e.g. Bosch, 2000 for details).
section presents and discusses the three trends that, in our opinion, Software product lines, when applied successfully, can provide
are driving the transition from an integration-centric to an increas- enormous benefits. In (HOF2), cases are described where adopting
ingly compositional approach of software engineering. In the sub- software product lines allowed for reducing development expenses
sequent section, we introduce the case study companies that, in with 50–75%, decrease defect density with similar numbers and in-
part, underlie our research. Then, we present the problems we ob- creases the size of product portfolio with up to an order of
served in our case studies, in which we capture the consequences magnitude.
of companies not transitioning to more compositional architec-
tures, processes and organizational approaches. The next section 2.2. Global development
presents a taxonomy of five approaches to large-scale software
development organized from integration-centric to increasingly For many companies, software development is going global
composition-oriented. Finally, we end the paper with a conclusion (Carmel and Agarwal, 2001; Herbsleb and Moitra, 2001; Sanwan
section. et al., 2006). More and more global companies have either intro-
duced several software development sites or engaged in strategic
2. Three trends partnerships with remote companies, especially in India and China,
due to several reasons; e.g., reduction of cycle time, reduction of
Large-scale software development is a very complex, effort con- travel cost, use of expertise when needed, or entering new markets,
suming and expensive activity. Although decades of software engi- responsiveness to market and customer needs (Cascio and Shuryg-
neering research have resulted in innovation and improvements, ailo, 2003). Global development has many advantages but brings
including increasing the abstraction level at which software devel- along its own set of challenges due to differences in culture, time
opment takes place, new software development processes and no- zone, software engineering maturity and technical skills between
vel approaches to architecting systems, the fact is that large-scale teams in different parts of the world.
software development still is largely unpredictable, inefficient and From an organizational perspective, geographically dispersed
error-prone. teams that develop components that are part of a system or family
Although the companies that we have studied as part of our re- of systems have significantly more difficulty in implementing the
search have found ways to manage their software engineering to necessary coordination. The challenge is that companies tend to
the best of their abilities, these approaches tend to be rather inte- copy their development processes and ways of working when
gration-centric, i.e. significant effort is placed on the last stage of changing development from local to global and then work to ad-
the software development lifecycle where the independently dress the symptoms by technology and coordination processes.
developed parts are manually integrated and validated. However, As a consequence, the coordination cost may start to significantly
there are three trends that have started to require software compa- affect the benefits normally associated with global development
nies to make significant changes to their approaches as the cost (cf. Kraut et al., 1999).
and complexity of an integration-centric approach is increasingly
rapidly. In this paper, we describe the approaches companies can 2.3. Software ecosystems
apply to transition to a composition-oriented approach. First, how-
ever, we need to present the three trends that drive this need to The most recent trend, especially in the domain of Web 2.0
transition, i.e. software product lines, global development and soft- companies but also in other domains, is the adoption of a software
ware ecosystems. ecosystem strategy (Messerschmitt and Szyperski, 2003). We de-
fine software ecosystem as follows: A software ecosystem consists
2.1. Software product lines of a software platform, a set of internal and external developers
and a community of domain experts in service3 to a community
Over the last decade, software product lines (Bosch, 2000, 2002; of users that compose relevant solution elements to satisfy their
Clements and Northrop, 2001; SPLC1) have enjoyed major adoption needs.
in the industry. Companies have adopted the technique for a vari- Taking a close look at the definition, one can see a clear path
ety of reasons, e.g. to decrease cost of development, to reduce time from software product lines to software ecosystems, i.e. there is a
to market, to expand the product portfolio or to achieve common- platform and a set of internal developers building products on top
ality in user experience between different products. Although a of the platform. However, in addition to that, there is a set, or
variety of alternatives exist, a software product line, in its basic community, of external developers that build on top of the same
form, consists of a software platform shared by a set of products. platform as well as extend the products released by the company.
Each product can typically select and configure components in A software ecosystem approach takes a community perspective,
the platform for its own purposes and extend the platform with including external developers, domain experts and users, and
product specific functionality. hence requires a community-centric way of collaborating and
Organizationally, teams exist for each of the products as well as coordinating. In this sense, whereas the scope of a software prod-
for the platform. In many cases, the platform consists of several uct line is intra-organizational, the scope of a software ecosystem
components with associated teams. Software development is coor- is much broader, including external developers and the
dinated between the teams in several different ways. During the

2
http://www.sei.cmu.edu/productlines/plp_hof.html.
1 3
http://www.splc.net/. http://en.wikipedia.org/wiki/Software_as_a_Service.
 J. Bosch, P. Bosch-Sijtsema / The Journal of Systems and Software 83 (2010) 67–76 69

extensions that they provide as well as other parties providing head of the team and lead architect still needed to coordinate
contributions. over geographical and architectural boundaries, but the amount
Similar to the transition from a product-centric to a product line of communication was significantly less due to the smaller num-
centric approach to software development, software ecosystems ber of people involved and the smaller number of issues on archi-
build dependencies between components and their associated tectural boundaries.
organizations that did not exist earlier. In this case, not only does The company also adopted a software ecosystem approach on
the evolution of the platform and products developed on top of it top of its platform, allowing external developers to develop appli-
need to be coordinated with the teams within the company, but cations and extensions on the platform that can be deployed on the
also the external developers and development teams need to be in- products that it ships. In several cases, decisions had to be taken
volved in the coordination. This coordination process affects all that forced management to choose between the responsibilities to-
phases of the lifecycle. During the road mapping and planning pro- wards the external developers in the ecosystem and the needs for
cess, external developers often have strong views on the priorities differentiation and time to market of new products or new releases
and sequencing of platform functionality. During development, the of existing products.
architecture, specifically the interfaces between the platform and
the products, should be developed in collaboration with the exter- 3.2. Case company B
nal developer community, not just published. Finally, during the
validation of the new release of the platform, the external devel- Company B is a Fortune 500 company developing software
oper community needs to be involved in order to minimize the products and services operating, primarily, on personal comput-
unintended breaks in functionality when rolling out the next plat- ers. The company’s products address both consumer and business
form release. markets and the company releases several products per year,
including new releases of existing products and completely new
3. Case companies products.
The products developed by the company range in the multi- to
The research and approach presented in this paper is based on tens of millions lines of code and tend to contain very complex
an action research methodology applied by the authors in components that implement national and international regula-
numerous software-intensive system companies as well as in tions. Although significant opportunities for sharing between dif-
other industries. The action research method seeks to bring to- ferent products exist, the company has organized its
gether action and reflection, theory and practice, in participation development based on a product-centric approach, i.e. teams are
with others, in the pursuit of practical solutions to issues of organized around a product and tend to be geographically local.
pressing concern to people, and more generally the flourishing Consequently, little or no sharing takes place between teams.
of individual persons and their communities (Reason and Brad- The company is predominantly present in a few western coun-
bury, 2001, p. 1). The basis for this paper is formed by three cases tries, but is in the process of expanding its business to global mar-
that we have worked with in detail during the last years, but the kets, specifically focusing on emerging (BRIC) markets. As part of
conclusions and premise of the paper is influenced by tens of its strategy to globalize, the company has established a major
other companies that the authors have worked with during their development center in Asia. Since it has a limited history of in-
careers. Although we describe the case study companies holisti- ter-team dependencies, the main approach to achieving the bene-
cally, our focus is on the software R&D part of each of the fits of global development was to move the responsibility for
companies. complete legacy products to the development center in Asia. The
developers at the western development site were, consequently,
3.1. Case company A freed up and these developers were assigned to work on the devel-
opment of new products and the evolution of rapidly growing re-
Company A is a Fortune 100 company developing embedded cently released products.
products, i.e. products that include mechanical, hardware and soft-
ware parts. The company releases several new products per year 3.3. Case company C
and uses a software product line approach to decrease the per-
product software R&D expenditure. As a consequence a significant The third company is a Fortune 100 company that builds a wide
part, i.e. more than half, of the software R&D is performed in the variety of embedded systems for different markets. We mainly fo-
central platform organization. The size of the software ranges in cus on the division that develops products for the global consumer
the 7–15 million lines of code range. market, basically servicing all continents.
The company, being global, has development sites in several The business strategy of the company is focused on having a
locations in Europe, the Americas and Asia, specifically India. The rich set of consumer products in the market, while minimizing
software platform organization is, consequently, also distributed the development effort through the application of software prod-
across the world. The company has aligned teams with the soft- uct line principles.
ware architecture of the platform and initially organized teams The size of the software in the products ranges in the several
in a distributed fashion where the head for the component team, million lines of code. The development teams are distributed
the lead architect as well as key members of the development team across three continents, resulting in global development that re-
were located in the company’s home country and the rest of the quires careful coordination as the company employs a product line
team was located at remote sites. approach. Although each product is built from a standard platform,
The aforementioned approach resulted in very low productiv- the development of the platform is not centralized, but rather the
ity in the distributed teams due to major communication over- platform components are owned by distributed teams, but can still
head, cultural differences and motivational issues for team be used, extended and changed by product teams in other loca-
members at the remote sites. The organizational setup was chan- tions. This approach provides significant independence for product
ged and full component responsibility was assigned to a geo- teams, but it does risk inefficiency in the system due to duplicate
graphically local team when it became clear that no learning extensions to components and too product-specific extensions to
effect would compensate for the perceived inefficiencies. The the shared components.
70 J. Bosch, P. Bosch-Sijtsema / The Journal of Systems and Software 83 (2010) 67–76

4. Problems observed at case study companies platform development is significantly affected in a negative
fashion.
Despite decades of research, large-scale software engineering is More precisely, we identify below the primary software archi-
challenging and, as we discussed earlier in the paper, there are sev- tecture problems as observed in the case study companies and
eral trends that are complicating collaboration even further. In this present some examples found from the cases.
section, we discuss the key challenges or problems that we have
identified in our research. These problems are based on the re-  Failing to keep it simple: We found that all case study companies
search at the three case study companies, but we have identified suffered from this problem, but especially company B suffered
the same problems at case companies not presented in the previ- from this in its legacy products. The key role of the software
ous section. architect is to take the key software architecture design deci-
The problem statement is organized according to three areas, sions that decompose the system into consistent parts that can
i.e. software architecture, engineering processes and the R&D orga- continue to evolve in relative independence. However, as has
nization. The industrial reality is that these areas are deeply inter- been studied by several researchers, e.g. (Tarr et al., 1999), no
connected, but we use this structure intentionally. Ideally, architectural decomposition is perfect and each has cross-cut-
architecture and technology choices are derived from the business ting concerns as a consequence. These concerns cause additional
strategy and should drive process and tools choices. These, in turn, dependencies between the components that, as discussed above,
should drive the organizational structure of the R&D organization need to be managed and add to the complexity of the system.
(van der Linden et al., 2004). In industrial practice, however, the Techniques exist to decrease the ‘‘tightness” of dependencies,
three areas mentioned above are not always aligned. Often, the such as factoring out the cross-cutting concerns and assigning
current organizational structure defines the processes and through them to a separate component or by introducing a level of indi-
that the architectural structure for the product or platforms and rection that allows for run-time management of version incom-
this consequently constrains the set of business strategies that patibilities. In the initial design of the system, but especially
the company can aspire to implement. When companies define during its evolution, achieving and maintaining the absolutely
new growth strategies, the business strategy often collides with simplest architecture is frequently not sufficiently prioritized.
the existing organizational structure and consequently the process In addition, although complexity can never be avoided com-
and architecture choices. pletely for any non-trivial system, it can easily be exacerbated
The paradox is that the R&D department still is responsible for by architects and engineers in response to addressing symptoms
releasing existing products and platforms while at the same time, rather than root causes, e.g. through overly elaborate version
needs to embark on the implementation of the new business strat- management solutions, heavy processes around interfaces or
egy. This factor contributes to the problems discussed in this sec- too effort consuming continuous integration approaches.
tion, which we have collected and generalized empirically  Lock-step evolution: Case study companies A and B suffered from
through action research. In our experience, the main cause for the lock-step evolution problem, i.e. all software assets have to
the problems discussed below is that the architecture, process move to the next iteration or release simultaneously otherwise
and organization approaches allow for too tight coupling and the the system or platform breaks down. When the system or plat-
problems discussed later in this section can almost always be ad- form can only evolve in a lock-step fashion, this is often caused
dressed by increasing the decoupling between architecture or by evolution of one asset having unpredictable effects on other,
organization elements. dependent assets. In the worst case, with the increasing amount
For each of the areas, we present a set of key problems associ- of functionality in the assets, the cycle time at which the whole
ated with that area. Problems discussed in later areas may have system is able to iterate may easily lengthen to the point where
bearing on earlier areas, but we have structured the section such the product or platform turns from a competitive advantage to a
that each problem is discussed in the area that it is predominantly liability. The root cause of the problem is the selection of inter-
related to. face techniques that do not sufficiently decouple components
from each other. APIs may expose the internal design of the
component or be too detailed that many change scenarios
4.1. Software architecture require changes to the API as well. The cross-cutting concerns
discussed under the previous point, obviously exacerbate the
As discussed in the introduction, the premise of the paper is lock-step evolution problem.
that a significant transition is necessary from a process-centric,  Insufficient quality attribute management: Even in a case where
manual integration approach to an architecture-centric automated the functional aspect of the API has been designed properly,
composition approach. This stresses the importance of software the quality attributes and the design decisions to achieve certain
architecture for achieving the necessary decoupling. Composition quality attributes, may cause implicit inter-component depen-
often breaks down due to too many unnecessary dependencies be- dencies. For instance, subsequent versions of a component, hav-
tween components and the teams responsible for those compo- ing different resource requirements and timing behavior may
nents. Each dependency requires effort to manage it, but the cause other components to fail. Although quality attributes are
primary consequence is that overall system complexity grows inherently cross cutting, one can use mechanisms, such as con-
exponentially with a growing number of dependencies, reducing tainers, to minimize the impact of these kinds of changes. Espe-
productivity further. cially the case study companies developing embedded systems
One may see several symptoms in cases where the architecture used solutions that bypassed the architectural design and prin-
does not provide sufficient decoupling for the R&D organization, ciples. Often these solutions were introduced as a temporary,
and potentially for the external partners or ecosystem participants. product-specific extension to solve a particular quality attribute
Examples include ripple effects in cases where one team’s delays problem but over time these solutions became part of the plat-
spread throughout the software stack, high integration cost and form architecture as they were ‘‘sanctioned” as the exception
lock-step evolution. Although these examples may be part of the tends to be turned into a rule.
process, the inefficiency is clearly caused by the software architec-
ture. When the architecture does not allow for sufficient decou- Although the problems discussed above are real concerns for
pling between teams, the overall efficiency of product and the case study companies, it is important to note that architects
 J. Bosch, P. Bosch-Sijtsema / The Journal of Systems and Software 83 (2010) 67–76 71

need to optimize for a conflicting set of functional, quality and the coordination costs between teams easily become excessive,
business requirements, sometimes causing them to sacrifice sim- resulting in a general perception in the organization that signif-
plicity and decoupling in favor of other requirements. When this icant inefficiencies exist.
occurs in an objective and explicit fashion, the higher integration  High and unpredictable product integration cost: A third problem,
and evolution cost associated with the architecture are a justifiable observed in all case study companies and to a significant
consequence. In our experience, however, most architectures suffer extent caused by the earlier discussed problems is that during
from the problems discussed above due to a lack of objective and product integration, incompatibilities between components are
explicit decision making. Typically, design evolution is reactive detected during system test and quality attributes break down
and symptom oriented and there is a severe lack of architecture in end-to-end test scenarios. This causes a costly and unpre-
refactoring efforts. As a consequence, these architectures require dictable integration process that, being at the end of the devel-
a manual, integration-oriented approach instead of allowing for opment cycle, causes major difficulties at the affected
an automated, compositional approach during product creation companies.
and evolution.  Lack of process discipline: We found that some teams in our
case study organizations, especially case company B, suffer
4.2. Engineering processes from a lack of process discipline. Although processes have been
defined, we observed that engineers and teams sometimes sim-
The software architecture is central in providing the decoupling ply ignore them. For example, in one organization, case com-
in the system that allows for a compositional approach. However, pany A, engineers in different teams worked out additional,
software architecture is only an enabler of compositionality and detailed interfaces between their respective components,
actual compositionality can be jeopardized by implementation despite the fact that the designed architecture did not allow
and process. The engineering processes, both formal and informal, for any connections between these components. As a result,
define the concrete collaboration between teams and between independent validation of the components became impossible.
individuals. The architectural integrity was violated and during the evolu-
Engineering process seems to have lost in popularity over re- tion of the system, these implicit dependencies caused major
cent years, both as a backlash against CMM and CMMI initiatives inefficiencies in the development process. Although engineers
in many companies, including the case companies reported upon and teams are aware of and understand the defined processes,
in this paper, and in response to the wide-spread adoption of agile the typical argument is that in this particular case the process
development processes. Therefore, it is important to realize that is not applicable and that following the process would have
analogous to any system having an architecture, any individual, negative consequences, e.g. cause delays. Once the difficulties
team and organization employs a process, be it implicit or explicit, begin to mount, this behavior is reinforced resulting in an
ingrained in the culture or read from a cookbook-like recipe. The increasingly lax process attitude.
observations from the case study companies show that the largest  Mismatched engineering processes: Another case is when the
challenges around processes typically exist at the inter-team level engineering processes are defined and followed, but the pro-
and often in response to addressing the symptoms of inter-compo- cesses are simply not suitable for the type of system or platform
nents and/or inter-team issues, causing complexities and and the organizational setup. For instance, processes relying on
inefficiencies. face-to-face communication or processes that assume interac-
Below, we present the key engineering processes problems that tion between teams during iterations cause significant ineffi-
we have identified at the case study companies. It is important to ciencies in large R&D organizations and especially global
note that these symptoms may occur even if the architecture is organizations. For example in case company A, the delivery of
optimal from the perspective of decoupling. The inefficiencies oc- the next version of a component to the integration team
cur because the engineering processes are not properly aligned required verbal communication between the integration team
with the needs of system or platform: and the component team who, after the company adopted glo-
bal development, worked in a distributed setting with 12 h time
 Insufficient pre-iteration cycle work: In some of the teams in case difference. The ability to have verbal communication was obvi-
company B that we studied, features that cross component ously highly impacted by the time difference.
boundaries were underspecified before the development cycle  Disconnected business and engineering processes: Finally, even
started and were ‘‘worked out” during the development. In prac- when the proper engineering processes have been defined and
tice, this requires close interaction between the involved teams used, the connection to business processes, especially product
and causes significant overhead that could easily be avoided by management, may be missing. Especially while implementing
more upfront design and interface specification. A consequence a new business strategy, not only the R&D organization, but also
of this approach is that it builds an ‘‘addiction” between teams the rest of the organization has to change significantly. We
in that there is a need for frequent (daily) developer-to-devel- found two major problems: (a) the business strategy is defined
oper drops of code that is under development in order to avoid at a level of abstraction that still requires significant interpreta-
integration problems later on. This, in turn, often results in lar- tion that cannot be performed by the R&D organization, espe-
gely manual testing of new functionality because requirements cially with respect to prioritization and sequencing of
solidify during the development cycle and automated tests functionality. (b) In the mature existing products, the product
could not be developed in time. management has grown accustomed to defining the next release
 Unintended resource allocation: Resource allocation is a tool used in terms of features to be added to the existing product. The new
by companies to align resources with the business strategy. In business strategy requires the definition of a completely new
practice, however, at two of the case study companies, i.e. A product or platform that has to be defined as an entirety and
and B, teams frequently assign part of their resources to other not as a delta of last year’s product and the product manage-
software components and their associated teams. The reason is ment function is unable to provide necessary guidance. For
that they are dependent on the other components to be able instance, in case company B, the new platform offered signifi-
to get their own functionality developed and released. One can cant new business opportunities, but product management
view this as a lack of road mapping activities and in that sense, was unable or unwilling to exploit these for fundamentally
it supports the previous point. The consequence is again, that new products.
72 J. Bosch, P. Bosch-Sijtsema / The Journal of Systems and Software 83 (2010) 67–76

4.3. R&D organization When teams need to closely cooperate during iteration planning
and have a need to exchange intermediate developer releases
During our research at the case study companies, including between teams during iterations in order to guarantee interop-
those reported on in this paper, we found that the organizational erability, the coordination cost of shared asset teams is starting
structure and context are important for the architecture and the to significantly affect efficiency.
software process. We observed problems in the following scopes:

 Globalization: Having software engineers located at different 4.4. Concluding remarks

geographical locations or even crossing country boundaries
has significant implications for the communication and collabo- Our research with the case study companies concludes that
ration of the engineer teams. Working geographically distrib- most often a too integration-centric approach is applied to soft-
uted increases the amount of time required to accomplish ware development, i.e. architects and engineers insufficiently ad-
tasks due to cultural differences, time zone differences and engi- dress decoupling of assets that would allow teams to work more
neers need to spend more time in coordinating their work across independently. This results in the problems and associated ineffi-
the globe (Powell et al., 2004). Engineers have to shift their time ciencies discussed in this section. We have organized these issues
for valuable work and global coordination, which makes devel- around architecture, process and organization, but as is clear from
opment less efficient. Cultural and language differences are evi- the examples that we provided in the section, there are deep inter-
dent in globalization and cultural differences appear to lead to connections and inter-dependencies between each of the areas.
coordination difficulties and create obstacles to effective com- This is the reason for addressing these in an integrated fashion in
munication (cf. Kraut et al., 1999). For example, in one organiza- this paper, as most of the existing work related to this area ad-
tion that we worked with, case company A, teams were dresses only a slice or segment of the overall problem area.
geographically split, with the team lead architect and senior
engineers located at the main site of the organization in Europe
and the remaining engineers in a remote site in India. This 5. From integration to composition
required significant communication taking place over geograph-
ical boundaries resulting in very inefficient development pro- The main thesis of this paper is that software development
cesses as well as a de-motivated team at the remote site, due organizations need to transition from a more integration-centric
to a lack of autonomy and responsibility of the remote site. to a more composition-oriented approach because of the trends
 Tacit knowledge: Tacit knowledge is implicit and deeply rooted discussed earlier in the paper affecting them. Although we believe,
(Nonaka, 1994), and is an important aspect for working in global based on our research, most companies fit this category; it does not
teams. Work practices, awareness of cultural differences as well automatically mean that applying the most compositional ap-
as contextual awareness of a location can be defined as tacit proach is the best approach for all companies. There are good rea-
knowledge of the local team members, which is difficult to share sons for using an approach that contains more integration-oriented
or transfer to remote teams. Another aspect in which tacit elements, as we discuss below. In this session, we outline five ap-
knowledge is important to take into account is in organizational proaches to organizing large-scale software development, i.e. inte-
change processes. Tacit knowledge in this respect is a good gration-centric development, release groupings, release trains,
match for the existing legacy of products and platforms. When independent deployment and open (eco-) system development.
a new business strategy is implemented, part of the existing These approaches are, as the names indicate, organized from more
tacit knowledge needs to be changed. However, as it is implicit integration-oriented to more composition-oriented. For each ap-
knowledge it becomes difficult to implement the necessary proach, we first describe the approach and then analyze when this
changes. For example, in case company C, the culture allowed approach could be applied.
teams to add product specific code in all areas of the architec-
ture, which initially caused inefficiencies when the company 5.1. Integration-centric development
transitioned to a product line approach. It took significant effort,
especially by the lead architects, to convert the implicit, tacit 5.1.1. Description
assumptions into a formalized description of behavior, explain When applying an integration-centric approach, the organiza-
the negative consequences and to enforce a different approach tion relies almost exclusively on the integration phase of the soft-
to engineering. ware development lifecycle. During the early stages of the lifecycle,
 Mismatch between architectural and organizational structure. there is allocation of requirements to the components. During the
One of the organizations, i.e. case company B, transitioned from development phase, teams associated with each component imple-
a product-centric to a product-line centric approach to software ment the requirements allocated to the component. When the
development. This requires a shared platform that is used by all development of the components making up the system is finalized,
business units. The organization, however, was unwilling to the development enters the integration phase in which the compo-
adjust the organizational structure and instead asked each busi- nents are integrated to form the overall system and system level
ness unit to contribute a part of the platform. Now each business testing takes place. During this stage, typically, many integration
unit had to prioritize between its own products and contributing problems are found that need to be resolved by the component
to the shared platform and as a consequence the platform effort teams, in collaboration with the integration team.
suffered greatly. Although the importance of aligning the organi- If the component teams have not tested their components to-
zation with the architecture has been known for decades (Con- gether during the development phase, this phase may also uncover
way, 1968), in practice many organizations violate this large numbers of problems that require analysis, allocation to com-
principle constantly. ponent teams, coordination between teams and requiring continu-
 Coordination cost: A problem observed in all case study compa- ous retesting of all functionality as fixing one problem may
nies is that when decoupling between shared software assets introduce others. Consequently, several organizations use continu-
is insufficiently achieved is excessive coordination cost between ous integration (Larman, 2004) in combination with automated
teams. One might expect that alignment is needed at the road regression testing to address the symptoms of this approach.
mapping level and to a certain extent at the planning level. Although this does alleviate the symptoms, it does not address
 J. Bosch, P. Bosch-Sijtsema / The Journal of Systems and Software 83 (2010) 67–76 73

the root cause: the organization is using the wrong approach for its cation domains that require high integration within the application
software development, i.e. an approach that provides insufficient domain, but much less integration between application domains.
decoupling. For instance, a system consisting of video processing and video
A second technique component teams often resort to, in re- storage functionality may require high integration between the vi-
sponse to the challenges discussed above, is sharing versions of deo processing components, but a relatively simple interface be-
their software even though it is under development. Although this tween the storage and processing parts of the system. In this
offers a means of simplifying the integration phase, the challenge is case, making each domain a release grouping is a good decision.
that the untested nature of the components being shared between
component teams causes significant inefficiency that could have
5.2.3. Summary
been avoided if only more mature software assets would be shared.
Architecture: In this approach, the architecture has been decom-
posed into its top level components, which are aligned with the re-
5.1.2. When to apply
lease groupings. Often, the organization has run into the limits of
Although the integration-oriented approach has its disadvan-
the previously discussed approach and has taken the action to
tages, as discussed above, it is the approach of choice when two
decouple the top level parts of the system.
preconditions are met. First, if conditions exist that require a very
Process: Similar to the architecture, the process is now also dif-
deep inter-dependencies between the components of a system or a
ferent between the release groupings, but the same as the previ-
family of systems, e.g. due to severe resource constraints or chal-
ously discussed approach within the release grouping. The
lenging quality requirements, the integration-oriented approach
decoupling allows the release groupings to be composed, with rel-
is, de-facto, the only viable option. Second, if the release cycle of
atively few issues. This is often achieved by more upfront work to
a system or family of systems is long, e.g. 12–18 months, the
design and publish the interface of each release group before the
amount of calendar time associated with the integration phase
start of the development cycle.
may be acceptable. Finally, it has great benefits if the R&D organi-
Organization: As discussed in the description, the allocation of
zation is local rather than distributed, because of the amount of
release groupings often mirrors the geographical location of teams
communication and coordination that needs to take place between
and the definition of release grouping interfaces the level of the
the teams.
geographical boundaries significantly decreases the amount of
communication and coordination that needs to take place and,
5.1.3. Summary
consequently, efficiency is improved.
Architecture: The architecture of the system or system family is
typically not specified and if documentation exists, the documen-
tation is often outdated and plays no role except for introducing 5.3. Release trains
new staff to the course grain design of the system. Because of this,
the de-facto architecture often contains inappropriate dependen- 5.3.1. Description
cies between the components that increase the coupling in the sys- In the third approach, the decoupling is extended from groups
tem and cause unexpected problems during development. of components to every component in the system. All interfaces
Process: Although most organizations employing this approach between components are decoupled to the extent possible and
employ techniques like continuous integration and inter-team each component team can by and large work independently during
sharing of code that is under development, the process tends to each iteration. The key coordination mechanism between the
be organized around the integration phase. This often means a sig- teams is an engineering heartbeat that is common for the whole
nificant peak in terms of work hours and overtime during the R&D organization. With each iteration, e.g. every month, a release
weeks or sometimes months leading up to the next release of the train leaves with the latest releases of all production-quality com-
product. ponents on the train. If a team is not able to finalize development
Organization: The R&D organization has a strong tendency to and validation of its component, the component is not accepted by
concentrate all important work to one location. Even if the organi- the release management team. Once the release team has collected
zation is distributed, there is often a constant push to concentrate all components that passed the component quality gates, the next
development and the team members in remote locations tend to step is to build all the integrations for the software product line.
travel extensively. For those components that did not pass the component quality
gates, the last validated version is used.
5.2. Release groupings The system level validation phase has two stages. During the
first stage, each new release of each component is validated in a
5.2.1. Description configuration consisting of the last verified versions of all other
In this approach, the development organization aims to break components. Component that do not pass this stage are excluded
the system into groups of components that are pre-integrated, from the train as the backward compatibility requirements are
i.e. a release group, whereas the composition of the release groups not met. During the second stage, the new versions of all compo-
is performed using high decoupling techniques such as SOA-style nents that passed the first stage are integrated with the last veri-
interfaces (Newcomer and Lomow, 2005). Within the context of a fied versions of all other components and integration testing is
release group, the integration-centric approach is applied, whereas performed for each of the configurations that are part of the prod-
at the inter-release group level coordination of development is uct family. In the case where integration problems are found dur-
achieved using periodic releases of all release groups in the stack. ing this stage, the components at fault are removed from the
release train. The release train approach concludes each iteration
5.2.2. When to apply with a validated configuration of components, even though in the
The release grouping approach is particularly useful in situa- process a subset of the planned features may have been withdrawn
tions where teams responsible for different subsets of components due to integration issues between components. The release trains
are geographically dispersed. Aligning release groupings with loca- approach provides an excellent mechanism for organizational
tion is, in that case, an effective approach to decreasing the ineffi- decoupling by providing a heartbeat for the engineering system
ciencies associated with coordination over sites and time zones. A that allows teams to synchronize on a frequent basis while work-
second context is where the architecture covers a number of appli- ing independently during the iterations.
74 J. Bosch, P. Bosch-Sijtsema / The Journal of Systems and Software 83 (2010) 67–76

One of the main changes that need to be implemented when ponents dependent on it and that any deprecation of interfaces is
moving from release groupings to release trains is the discipline handled in a structured way over a significant amount of time. In
to perform the necessary upfront work before the start of the addition, the teams develop and commit to roadmaps and plans.
development cycle. Each components needs to commit to the fea- The lack of an organization-wide heartbeat does not free any team
tures that it will develop and announce the changes to its interface. from the obligation to keep their promises. However, the validation
The second change is to enforce the discipline to ‘‘throw a compo- of a component before being released is more complicated in this
nent off the train” when it causes problems during the composition model as any component team, at any point in time, may decide
stage. Although it is acceptable to allow for a few hours or days to release its latest version.
during the composition stage to work out minor mismatches, any
component that causes major issues needs to be rejected. Espe- 5.4.2. When to apply
cially during the transition process, this may cause significant ten- The independent deployment approach is particularly useful in
sion in the organization while the new rules are being enforced. cases where different layers of the stack have very different ‘‘natu-
ral” iteration frequencies. Typically, lower layers of the stack that
5.3.2. When to apply are abstracting external infrastructure iterate at a significantly
The release train approach is particularly suited for organiza- lower frequency. This is both because the release frequency of
tions that are required to deliver a continuous stream of new func- the external components typically is low, e.g. one or two releases
tionality in their products or platform, either because new per year, and because the functionality captured in those lower
products are released with a high frequency or because existing layers often is quite stable and evolves more slowly. The higher
products are released or upgraded frequently with new functional- layers of the software stack, including the product-specific soft-
ity. The organization has a business benefit from frequent releases ware, tend to iterate much more frequently and require a shorter
of new functionality and, consequently, derives a competitive development cycle.
advantage. Companies that provide web services provide a typical The key factor in the successful application of the independent
example of the latter category. Customers expect a continuous deployment approach is the maturity of the development organi-
introduction of new functionality in their web services and expect zation. The processes surrounding road mapping, planning, inter-
a rapid turnaround on requests for new functionality. face management and, especially, verification and validation,
The release train approach does require a relatively mature need to be mature and well supported by tools in order for the
development organization and infrastructure. For instance, the model to be effective.
amount and complexity of validation and testing that is required
demands a high degree of test automation. In addition, interface 5.4.3. Summary
management and requirements allocation processes need to be Architecture: Similar to the release trains approach, the architec-
mature in order to achieve sufficient decoupling, backward com- ture needs to be fully specified at the component level. Architec-
patibility and independent deployment of components. ture refactoring and evolution is becoming more complicated to
coordinate and execute on.
5.3.3. Summary Process: The perception in the organization easily becomes that
Architecture: The architecture now needs to be fully specified at there no longer is an inter-team process for development as any
the component level, including its provided, required and compo- team can develop and release at their leisure. In practice, this is
sition interfaces. No dependencies between components may exist caused because the process is no longer a straightjacket but more
outside the interfaces of the components. provides guardrails within which development takes place. The
Process: The key process challenges, as discussed above, are the cultural aspects of the software development organization, espe-
pre-development cycle work around interface specification and cially commitment culture and never allowing deviations from
content commitment and the process around the acceptance or backward compatibility requirements, needs to be deeply en-
rejection of components at the end of the cycle. In addition, espe- grained and enforced appropriately.
cially when the organization uses agile development approaches, Organization: Similar to the release trains approach, the organi-
sequencing the development of new features such that dependent, zation can take many shapes and forms as long as the development
higher level features are developed in the cycle following the re- teams associated with a component are not distributed
lease of lower level features allows for significantly fewer ripple ef- themselves.
fects when components are rejected.
Organization: As the need for coordination and communication 5.5. Open ecosystem
between the teams has been reduced and is much more structured
in terms of time and content, the organization can be distributed 5.5.1. Description
without many of the negative consequences found in the earlier The final approach discussed is an approach in which inter-
approaches. organizational collaboration is strived after. Successful software
product lines are likely to become platforms for external parties
5.4. Independent deployment that aim to build their own solutions on top of the platform pro-
vided by the organization. Although this can, and should, be con-
5.4.1. Description sidered as a sign of success, the software product line typically
The independent deployment approach assumes an organiza- has not been designed as a development platform and providing
tional maturity that does not require an engineering heartbeat (a access to external parties without jeopardizing the qualities of
heartbeat in the engineering system allows teams to synchronize the products in the product line is typically less than trivial. Even
on a frequent basis while working independently during iterations) if the product line architecture has been well prepared for acting
including all the processes surrounding a release train. The notion as a platform, the problem is that external developers often de-
of product populations as studied by van Ommering (2001) is a mand deeper access to the platform than the product line organi-
illustrative example of the independent deployment approach. In zation feels comfortable to provide.
this approach, each team is free to release new versions of their The typical approach to address this is often twofold. First,
component at their own iteration speed. The only requirement is external parties that require deep access to the platform are certi-
that the component provides backward compatibility for all com- fied before access is given. Second, any software developed by the
 J. Bosch, P. Bosch-Sijtsema / The Journal of Systems and Software 83 (2010) 67–76 75

certified external parties needs to get validated in the context of opens up as much useful platform functionality for external devel-
the current version of the platform before being deployed and opers and on the other hand provides an even higher level of qual-
made accessible to customers. ity and stability as the evolution of interfaces published to the
Although the aforementioned approach works fine in the tradi- ecosystem is very time and effort consuming as well as constrain-
tional model, modern software platforms increasingly rely on their ing. In addition, security precautions have to be embedded in the
community of users to provide solutions for market niches that the interface to provide the best defense mechanisms for accidental
platform organization itself is unable to provide. The traditional or intended harm to the customers in the ecosystem.
certification approach is infeasible in this context, especially as Process: As the ecosystem participants are independent organi-
the typical case will contain no financial incentive for the commu- zations, no common process approach can be enforced, except for
nity contributor and the hurdles for offering contributions should gateways, such as security validation of external applications.
be as low as possible. Consequently, in these cases, a mechanism However, each limitation put in place causes hurdles for external
needs to be put in place that allows software to exist within the developers that inhibit success of the ecosystem, so one has to be
platform but to be sandboxed to an extent that minimizes or re- very careful to rely on such mechanisms.
moves the risk of the community-offered software affecting the Organization: The organization in this approach is best de-
core problem to any significant extent. scribed as a networked organization, i.e. the platform providing
The open ecosystem development model allows unconstrained organization has a rather central role, but the external developers
releasing of components in the ecosystem not only by the organi- provide important parts, often the most differentiating and valu-
zation owning the platform but by also by certified 3rd parties as able parts of the functionality.
well prosumers and other community members providing new
functionality. Illustrative examples in the web 2.0 space include
Salesforce.com4 and Facebook.5 However, it is clear that a success- 6. Conclusion
ful application of this approach requires run-time, automated solu-
tions for maintaining system integrity for all different Large-scale software development is complex, effort consuming
configurations in which the ecosystem is used, especially as cus- and unpredictable and after decades of software engineering re-
tomer often have significant possibilities to match and mix, i.e. search we still have problems managing the constantly evolving
compose their own configuration of functionality. complexity. Three trends are driving an acceleration of the com-
plexity, i.e. software product lines, global development and soft-
5.5.2. When to apply ware ecosystems. In this paper, we discuss the resulting
The open ecosystem model is a natural evolution from the re- problems, organized around architecture, process and organiza-
lease train and independent deployment models when the organi- tion. The conclusion is that the case study companies described
zation decides to open up the software product line to external in this paper, as well as others that are not, typically employ a
parties, either in response to demands by these parties or as a stra- too integration-centric approach that causes significant inefficien-
tegic direction taken by the company in order to drive adoption by cies in the system.
its customers. In this paper, we outlined five approaches to organizing large-
The key in this model, however, is the ability to provide proper scale software development, i.e. integration-centric development,
architectural decoupling between the various parts of the ecosys- release groupings, release trains, independent deployment and
tem without losing integrity from a customer perspective. In cer- open ecosystem development. These approaches are, as the names
tain architectures and domains, the demand for deep integration indicate, organized from more integration-oriented to more com-
is such that, at this point in the evolution of the domain, achieving position-oriented. The collaboration models are summarized in Ta-
sufficient decoupling is impossible, either because quality attri- ble 1. Selecting the right inter-team software development
butes cannot be met or because the user experience becomes unac- approach is perhaps the most important lever for achieving high-
ceptable in response to dynamic, run-time composition of quality, efficient and effective software engineering practices and
functionality. results in virtually any software developing organization. Although
Two areas where this approach is less desirable are concerned our research suggests that most companies use an approach that is
with the platform maturity and the business model. Although the too much integration-oriented, one should not conclude that a
pull to open up any software product line that enjoys its initial suc- more composition-oriented approach is always preferable. As dis-
cess in the market place, the product line architecture typically cussed earlier in the paper, there are cases where a more integra-
goes through significant refactoring that can’t be hidden from the tion-oriented approach is preferable.
products in the product line or the external parties developing The contribution of the paper is threefold: (1) we provided a de-
on top of the platform defined by the architecture. Consequently, tailed description of the three main trends that are driving and
any dependents on the product line architecture are going to expe- even accelerating complexity in modern large-scale software
rience significant binary breaks and changes to the platform inter- development. (2) We analyzed the architectural, process and orga-
face. Finally, the transition from a product to a platform company nizational problems that an organization may experience based on
easily causes conflicts in the business models associated with both intense data collection from action research when it applies the
approaches. If the company is not sufficiently financially estab- wrong approach to its software development. (3) We presented
lished or the platform approach not deeply ingrained in the busi- five approaches to large-scale software development, organized
ness strategy, adopting the open ecosystem approach may fail along a continuum ranging from integration-centric to fully com-
due to internal organizational conflicts and mismatches. position-oriented. Although our research shows that the case study
companies applied an approach that was too integration-oriented
5.5.3. Summary and would have benefitted from adopting a more compositional
Architecture: The main architectural focus when adopting this approach, this is not an absolute truth. Our recommendation is that
approach is to provide a platform interface that on the one hand each software development organization takes a conscious and in-
formed decision to adopt the approach that is optimal for the par-
ticularities of the organization. When in doubt, however, typically
4
www.salesforce.com. the more composition-oriented approach should be preferred as it
5
www.facebook.com. offers better abilities to assign small teams to parts of the system
76 J. Bosch, P. Bosch-Sijtsema / The Journal of Systems and Software 83 (2010) 67–76

Table 1
Collaboration models for large global software development, from integration-centric to fully composition-oriented approaches.

Approaches Integration- Release grouping Release trains Independent deployment Open (eco-) system
centric development
1. Architecture Strongly High integration within release High decoupling between High decoupling between Highly decoupled with
interconnected grouping, high decoupling between components components sand boxes for third party
architecture groupings functionality
2. Process Continuous Continuous coordination within Short iteration cycles; Each team selects length Each team selects length of
coordination grouping only coordination at start/ of iteration cycle iteration cycle
between teams end of cycle
3. Organization High Teams responsible for different Distributed teams within Distributed teams within Distributed teams across
interdependency release groupings can be organization organization organizational boundaries
teams distributed
4. Applicability 1. Release cycle 1. Geographical distribution of 1. Frequent releases 1. Different iteration 1. Market approach
long teams aligned with release beneficial for firm frequencies for different
groupings parts of system
2. Co-location of 2. High level of maturity 2. High level of maturity 2. Teams highly dispersed
team needed needed
3. High level of maturity
needed

and to adhere to short release cycles, allowing one to experiment International Conference on Software Engineering (ICSE’1999). IEEE Computer
Society Press, pp. 107–119.
more rapidly in the market place with real customers.
van der Linden, F., Bosch, J., Kamsties, E., Känsälä, K., Krzanik, L., Obbink, H., 2004.
Software product family evaluation. In: Proceedings of the Third Conference
References Software Product Line Conference (SPLC 2004). LNCS 3154. Springer-Verlag, pp.
110–129.
Bosch, J., 2000. Design and Use of Software Architectures: Adopting and Evolving a van Ommering, R., 2001. Techniques for independent deployment to build product
Product Line Approach, Pearson Education, Addison-Wesley & ACM Press, ISBN populations. In: Proceedings of WICSA 2001, pp. 55–64.
0-201-67494-7. Jan Bosch is VP, Engineering Process at Intuit Inc. Earlier, he was head of the
Bosch, J., 2002. Maturity and evolution in software product lines: approaches, Software and Application Technologies Laboratory at Nokia Research Center, Fin-
artifacts and organization. In: Proceedings of the Second Software Product Line land. Before joining Nokia, he headed the software engineering research group at
Conference (SPLC). the University of Groningen, The Netherlands, where he holds a professorship in
Carmel, E., Agarwal, R., 2001. Tactical approaches for alleviating distance in global software engineering. He received a M.Sc. degree from the University of Twente,
software development. IEEE Software 1 (2), 22–29.
The Netherlands, and a Ph.D. degree from Lund University, Sweden. His research
Cascio, F. Wayne., Shurygailo, S., 2003. E-leadership and virtual teams.
activities include software architecture design, software product families, software
Organizational Dynamics 31 (4), 362–376.
variability management and component-oriented programming. He is the author of
Clements, P., Northrop, L., 2001. Software Product Lines: Practices and Patterns.
Addison-Wesley. a book ‘‘Design and Use of Software Architectures: Adopting and Evolving a Product
Conway, M.E., 1968. How do committees invent. Datamation 14 (5), 28–31. Line Approach” published by Pearson Education (Addison-Wesley & ACM Press),
Herbsleb, J.D., Moitra, D., 2001. Global software development. IEEE Software 18 (2), (co-)editor of several books and volumes in, among others, the Springer LNCS series
16–20. and (co-)author of a significant number of research articles. He is editor for Science
Kraut, R., Steinfield, C., Chan, A.P., Butler, B., Hoag, A., 1999. Coordination and of Computer Programming, has been guest editor for several journal issues, chaired
virtualization: the role of electronic networks and personal relationships. several conferences as general and program chair, served on many program com-
Organization Science 19 (6), 722–740. mittees and organized numerous workshops.
Larman, C., 2004. Agile and Iterative Development: A Manager’s Guide. Addison-
As a consultant, as a professor and as an employee, he has worked with and for
Wesley.
many companies on strategic reuse in general and software product lines specifi-
Messerschmitt, D.G., Szyperski, C., 2003. Software Ecosystem: Understanding an
Indispensable Technology and Industry. MIT press. cally, including Philips, Thales Naval Netherlands, Robert Bosch GmbH, Siemens,
Newcomer, E., Lomow, G., 2005. Understanding SOA with Web Services, Addison- Nokia, Ericsson, Tellabs, Avaya, Tieto Enator and Det Norska Veritas. Around soft-
Wesley, ISBN 0-321-18086-0. ware product lines, he has published on, advised and implemented specific tech-
Nonaka, I., 1994. The Knowledge Creating Company. How Japanese niques and methods around, among others, software architecture, software
Companies Create the Dynamics of Innovation. Oxford University Press, variability management, the link to business strategy, organizational models,
New York. assessment frameworks, adoption frameworks and quality attributes. More infor-
Powell, A., Piccoli, G., Ives, B., 2004. Virtual teams: a review of current literature and mation about his background can be found at his website.
directions for future research. The Database for Advances in Information
Petra Bosch-Sijtsema is currently a visiting scholar at Stanford University, USA at
Systems 35 (1), 6–36.
the Project Based Learning Lab, and a researcher at Helsinki University of Tech-
Reason, P., Bradbury, H. (Eds.), 2001. Handbook of Action Research. Sage Publishing,
Thousand Oaks. nology, Laboratory of Work Psychology and Leadership in Finland. She received her
Sanwan, R., Bass, M., Mullick, N., Paulish, D.J., Kazmeier, J., 2006. Global Software licentiate from Lund University (Sweden) and her Ph.D. from the University of
Development Handbook. CRC Press. Groningen (The Netherlands) in Management and Organization. She has worked at
Tarr, P., Ossher, H., Harrison, W., Sutton Jr., S.M., 1999. N degrees of separation: universities in Sweden, the Netherlands, Canada, Finland and the US. Her research
multi-dimensional separation of concerns. In: Proceedings of the 21st focuses on global distributed organizations and teams.