Planning Distributed Development through Software Architecture

Min Chen, Bharat Gorantla, Okeno Palmer, Lutz Wrage

Master of Software Engineering Program
Carnegie Mellon University
Pittsburgh, PA 15213, USA
{minc1, bgorantl, orp, lw}@andrew.cmu.edu

Abstract Moreover, it has a strong influence on the

Coordination among distributed teams is the major
challenge in global software development projects
because effective communication is difficult to achieve.
Software architecture, when designed appropriately,
helps to increase coordination while minimizing the
need for communication among teams. Software
architecture for globally developed systems must take
into consideration the communication problems that are
exacerbated by distance, different languages and
cultures, time difference, and work environment.
Furthermore, techniques to assign architecture elements
to distributed teams must consider module
dependencies, technologies, development effort, and
end-to-end functionality for each development iteration.
This facilitates project administration by providing the
necessary insight and flexibility when managing global
development projects.
1. Introduction
Global software development projects face
coordination problems because of ineffective
communication and inter-dependencies among teams.
Effective communication is difficult to achieve in a
distributed environment because of distance, different
languages and cultures, time difference, and work
environment. Previous research suggests that the use of
well-designed architectures, processes, and tools help to
coordinate the work of distributed teams while
minimizing the need of communication across these
teams [1].
Software architecture is defined as "the structure or
structures of the system, which consist of elements, their
externally visible properties, and the relationships among
them." It allows groups of people separated by
organizational, geographical, and even temporal
boundaries to work cooperatively and productively [2].
communication patterns of the development teams
because it determines the module dependencies of the
system that will be developed by these teams.
Consequently, a well-designed architecture can be used
to study distribution, in the sense of suggesting which
software modules should be developed by which teams.
Software architecture is driven by functional
requirements, quality attributes, and constraints. Quality
attributes are often addressed as non-functional
requirements such as performance, security, and
interoperability of the system. Distributability, on the
other hand, is an attribute of the architecture that makes
the system suitable for development by distributed
teams.
Architecture documentation is comprised of a
collection of views. The static, runtime, and physical are
the three main perspectives of a system that can be
represented with views. Module views contain classes,
functions, and interfaces to represent properties of the
system from the static perspective. Component-and-
connector (C&C) views encompass processes and
sequence diagrams to represent the properties from the
runtime perspective. Allocation views of computers,
devices, and networks are used to represent properties of
the system from the physical perspective. Every view
focuses on quality attributes of the architecture. For
example, module views can be used to reason about
interoperability and portability; C&C views to address
performance and security; and allocation views to
address disk capacity and memory properties.
However, distributability is not addressed by any of
the views alone. Module views are useful when
analyzing inter-dependencies among modules to decide
which architecture elements can be assigned to which
teams. C&C views are important when studying whether
the structures of the system are independently testable.
Allocation views provide the assignment of modules to
teams.
 This paper describes our experiences and lessons
learned when working as a development team in a global
development project at Carnegie Mellon University
(CMU), and as the architecture team responsible for re-
designing a software architecture suitable for distributed
development and proposing the assignation of
architecture elements to distributed teams.
2. Project Overview
The project on which we base this paper was a Studio
project in the Master of Software Engineering program
at CMU. Our Studio team consisted of 4 graduate
students. This team was one of seven teams distributed
across the world who were chosen by the client to work
on a global development research project named "JOY".
The goals of the JOY project were to:
• Learn from experimentation of processes in a
globally distributed context. That is, to experiment
with processes and to observe the influence of
requirements, architecture, and process
documentation on development in a globally
distributed environment.
• Determine how having a stable set of requirements, a
sound architecture and a well documented
lightweight process can influence development in a
distributed context. The focus of the project was on
observing the teams and distilling lessons learned for
distributed development. It was not to create a
product for use in a production environment.
The JOY project was planned for a duration of three
years; the first iteration started in September 2004 and
was planned to end in August 2005. The client had
prepared an initial, high-level software architecture of
the system, and each team would develop one or more
components of this architecture. The CMU team was
mainly responsible for developing a basic component
called system object model. However, due to
coordination problems that arose, the CMU team was
later given the responsibility of recreating the
architecture for the same system to make it suitable for
distributed development and proposing an initial work
unit assignment for the new distributed development
teams based on the revised architecture.
2.1. First Iteration Problems
The main problems we encountered while trying to
implement the original JOY architecture were in the
areas of communication, requirements elicitation, work
assignments, and distributed implementation.
2.1.1. Communication Issues. The project was
organized following a hub-and-spoke model. The client
had a central team, the hub, and the student teams were
arranged around the center. Student teams could directly
communicate with the central team, but all
communication between student teams had to be
facilitated by the central team. The goal of this
organizational structure was to limit the number of
communication channels and thus control the
communication overhead in the distributed environment.
However, the software architecture was not well suited
for this model because it required close collaboration of
student teams, for example, to define component
interfaces that needed to be shared among teams.
2.1.2. Requirements Elicitation Issues. The original
JOY software architecture was based on a set of
architectural drivers that included high-level functional
requirements and a number of constraints. For example,
the system had to be Web-based, and it had to update the
user interface asynchronously whenever certain
measured values changed. However, we found that many
of these requirements were not understood in enough
detail to create a viable architecture. In addition, quality
attribute requirements had not been documented at all.
As a result, in the original architecture, the
responsibilities of components and their interfaces were
not defined in as much detail as the teams needed to
develop their assigned components.
Particularly the lack of documented quality attribute
requirements made it difficult to refine the component
design consistently across development teams. We had
planned to use the attribute-driven design method, but
this method requires this kind of information to be
documented in the architecture [3].
2.1.3. Work Assignments. Each student team was
assigned a number of components to develop. One
criterion for assignment was a preference given by the
teams; other criteria were not explained to the teams.
However, in the course of the project it became obvious
that the central team had not considered component
inter-dependencies to the degree necessary for success.
Incremental deliveries were organized by use cases
which led to situations where parts of a use case were to
be implemented in components developed by different
teams but with the same delivery date.
2.1.4. Distributed Implementation Issues. The lack of
detail in the original software architecture made it
necessary for the student teams to add missing interface
definitions to their assigned components. Adding or
modifying a component interface is a change in the
architecture that must be communicated to all
development teams that use this interface but there was
no process in place to manage this kind of change.
The original strategy called for the central team to
integrate components developed by the student teams. It
did not work well because there were dependencies
among components which were not immediately obvious
in the architecture, and the schedule did not take them
into account.
2.1.5. First Iteration Results. In May 2005 it became
clear that the original approach would not result in the
creation of a system that could demonstrate even simple
end-to-end functionality. The code produced by the
student teams constituted an incomplete set of
components that did not fit well together. The central
team realized that they had significantly underestimated
the effort to manage such a distributed development
project. This led to many of the problems because the
teams were assigned responsibilities that should have
been executed by the central team. The most prominent
mistake in this regard was that it was left to the student
teams to define component interfaces without exercising
control over the content of the interfaces and over
interface changes.
The next section describes our approach for designing
an architecture suitable for distributed development. We
then focus on criteria and artifacts that help in assigning
work to distributed teams.
3. Creating the New Architecture
When analyzing the problems that caused the first
iteration of the JOY project to fail, we identified several
tactics we used to increase the distributability of our
software architecture. Some of these tactics increase the
architecture's level of detail, while others are related to
the kind of artifacts included in the architecture
documentation.
1) Address communication with interfaces. Our revised
architecture contains detailed interface definitions to
limit the amount of communication necessary to
coordinate distributed development efforts. In
addition we provide sequence diagrams that show
how components and interfaces are used to achieve
the system's overall functions. We realize that
that communication among teams may still be
necessary to evolve interface specifications, but given
our architecture this will require significantly less
communication than to negotiate completely new
interfaces.
2) Make components independently testable. We
accomplished this designing the run-time architecture
as several communicating processes. Each process
should be assigned to one team for development such
that they all work on largely self-contained pieces.
This tactic may increase the complexity of the overall
architecture. Integration testing will be more complex
compared to a monolithic system, but only to a
limited degree because the JOY system is already
highly multithreaded.
3) Trade distributability for code sharing. Each time a
team uses modules that are developed by other teams
a strong dependency is introduced. The required
coordination among the teams may offset any savings
the shared modules can achieve. Our architecture
contains two very similar small modules that will be
developed by independent teams.
4) Create more modules than there are distributed
teams. More modules available for assignment to
teams make planning more flexible. Work
assignments can be adapted to the teams' technical
expertise and to schedule constraints. The trade-off is
that the architecture becomes more complex with
each added module because module responsibilities
and interfaces need to be specified.
4. Creating and Assigning Work Units
The main effort of the architecture redesign was
focused on dividing work among teams. At the time we
created the architecture, the central team only knew that
there would likely be six student teams to implement the
system. However, we had no information about the team
members' profiles, background, and availability. Hence,
we compiled information for use by the project
management to assign work units to the distributed
teams. This information will also inform the milestones
in the project schedule. To accomplish this we executed
the following activities:
1) Identify Criteria. Create a prioritized list of criteria to
guide in assigning work units to teams.
2) Identify and Create Artifacts. For each criterion from
the previous activity, create artifacts that specifically
address this criterion. An artifact is a representation
 representation tool that helps communicating and
analyzing a concept.
3) Propose Work Unit Assignment. Create a work unit
assignment that takes all criteria into account. As we
did not have enough information about the teams'
level of expertise, our work assignment will serve as
a starting point that the central team will adapt.
4.2 Artifacts
The artifacts presented in this section are those we
created to address the criteria of the previous section. All
the modules listed below are part of the detailed
architecture. High-level modules are composed from one
or more of the modules listed below.

4.1 Criteria 4.2.1. Dependency View. A Design Structure Matrix

(DSM) was used to create the dependency view based on
Table 1 shows the criteria decreasing priority order. the modules of the JOY system. The DSM is a tool that
These criteria are based on the customer’s preferences. displays the relationships between elements of a system
In addition, to balance the development teams' in a compact, visual, and analytically advantageous
workload and resources, the architecture team estimated format [4]. The DSM method is an information exchange
the development effort required for each module. In an model that allows the representation of complex module
ideal situation the architect would have information relationships in order to determine a sensible sequence
about the teams, such as size, expertise and availability for the modules being modeled.
to accurately estimate the effort. In the JOY project the
profiles of the development teams were unknown, so the The DSM in Table 2 is a module-based binary matrix
architecture team made the assumption that no team which rows and columns are headed with the complete
would have significant experience in any of the required list of modules of the system. This is the final DSM as
technologies. The result of these considerations is shown the result of using a manual DSM partition algorithm to
in the development effort view. determine the optimum module development sequence.
Marks in the matrix explain if there are dependencies
Table 1. Work Units Assignment Criteria
ID Criterion Description Artifacts
C1
Allow teams to Each team will be responsible The modules, as designed by the CMU team, are created with
focus on for a functionality to reduce high cohesion and low coupling in mind. Hence, the resulting
specific the need for communication modules are packages of functionalities. The module view of
functionalities with other teams. the architecture helps to reason about this criterion.

C2
Create JOY There should be a functional To have a functional system in each release, the development
using system by the end of each teams have to implement elements of the architecture that will
incremental release. fulfill functional requirements. Prioritized use cases are one
development artifact used to decide the order in which the modules have to
be implemented.
C3
Create JOY Before developing each An artifact that shows the module dependencies along with the
using bottom up module, other modules it possible timelines will be the best for this criterion. The CMU
development. depends on should already be team used a Design Structure Matrix (DSM) to create a
developed or under module dependency view of the JOY architecture. A timeline
development. view was derived from the optimized matrix.
C4
Allow teams to Save time by assigning work It is necessary to know technologies that are required to
focus on few units to teams according to implement each of the modules of the JOY system. Hence, the
technologies. their expertise. Assign architecture team created the technology view that maps each
modules to teams to minimize module to the technologies that are required in its
the number of teams that need implementation.
to learn a technology.
 Table 2. Design Structure Matrix
Number of modules
this depends on
Module ID 1 3 14 4 5 6 15 9 11 16 12 7 10 13 8 2
PS 1 0
CP 3 0
CFG 14 0
VC 4 1 1
DA 5 1 1
CD 6 1 1
COV 15 1 1
AM 9 1 1 1 1 1 5
PD 11 1 1 1 3
AP 16 1 1 1 3
ARE 12 1 1 1 1 4
HED 7 1 1 2
AD 10 1 1 2
LRE 13 1 1 1 1 4
RED 8 1 1 1 3
LO 2 1 1 1 1 4

Number of dependants 6 2 1 1 10 2 1 3 2 2 1 1 1 1 0 0

Legend

1 in bold = strong dependencies

1 regular = weak dependencies

there are dependencies among the modules and, if so,
which kind of dependency. A ”1“ in bold represents
strong dependency, and a “1” in regular font represents
a weak dependency. If module A has a strong
dependency on module B, A needs a correct
implementation of module B to run correctly.
Each row represents all the modules required for the
implementation of the module corresponding to that row.
Similarly, reading down a specific column shows which
modules depend on, or use, the module corresponding to
that column. For example, the PS module depends on no
other modules, but 6 modules depend on it.
The order of the modules in the DSM shows a
possible sequence of development. The first three
modules (PS, CP, CFG) can be developed in parallel as
they do not depend on each other and not on modules
outside this group. Following this group, there are 11
modules (VC through LRE) which depend on the
modules in the first group as well as on other modules
within this group. Some of these modules can be
developed in parallel; others have to be developed in
sequence. Finally, the last two modules (RED, LO) do
not have any dependants, and they can be developed in
parallel as they do not depend on each other.
For more information about DSM and partition
algorithms, refer to Yassine’s paper [5].
4.2.2. Timeline View. The timeline view (Table 3) is
derived from the dependency view. It is based solely on
the strong dependencies to determine in which period a
module can be developed. Weak dependencies were not
taken into consideration because development teams can
create stubs to simulate functions of the required module
if it is not ready. Stubs cannot be used to replace
modules in strong dependencies.
This view partitions the project into four time
periods. These do not necessarily have the same
duration. The earliest possible section indicates the
period in which a module can be developed right after all
its required modules are ready. The latest possible
section indicates the last period in which a module can
be developed without delaying the development of its
dependants, if any.
Some modules have to be developed in the same
period for both options. The names of these modules are
shown in bold. For example, the VC module has to be
developed in Period 1 regardless if the option is earliest
or latest possible.
 Table 3. Timeline View
Option Period 1 Period 2 Period 3 Period 4
Earliest PS VC DA CE HED AD
Possible CP COV AM PD RED ARE
CFG AP LO LRE
Latest VC DA AM AP LO
Possible CFG CE PD LRE
CP ARE COV
AD PS
HED RED

The timeline view does not take into consideration

system functionality and size of the modules. That is,
developing the modules in the suggested order does not
guarantee an incremental development. In addition, the
view does not show if development of a module can span
several periods.
4.2.3. Technology View. The Technology View shown
in Table 4 provides information about the technologies
that each module will require for its implementation. The
purpose of this view is to identify how many
technologies a development team will have to learn for
its work units.
For the JOY system we identified five technologies
the development teams will use in its implementation. As
we assume that the teams do not have experience in any
of these, the number of technologies a team uses should
be limited to no more than three.
4.2.4. Development Effort View. The Development
Effort View (Table 5) shows the relative effort required
to implement each module. The effort estimation must
take into account:
• Technologies involved in the implementation of the
module
• Complexity of the design of the module
• Amount of functionality contained in the module
• Expertise and experience of developers
The relative effort is measured as high, medium, and
low. That is, a module assigned high effort requires more
effort than a module assigned medium, but two modules
with high effort may or may not take the same amount of
time. We estimate that modules within a category will
require similar amounts of time for development. We
could not provide a more precise effort because we did

Table 4. Technology View

Technology
Module ASP.NET AJAX .NET Remoting C# Programming NHibernate
PD × × × ×
AD × × × ×
HED × × ×
RED × × ×
LO × × ×
PS × ×
CP × ×
VC ×
CP × ×
COV × ×
ARE × ×
LRE × ×
AP × ×
CFG × ×
DA × × ×
AM ×
effort because we did not have the necessary information timeline view, technology view, and the development
about the teams’ level of experience and expertise. effort view, a more informed way of assigning work in a
distributed environment can be done. The work
The purpose of this view is to help balance the assignment view shown in Table 6 merges information
workload of the work units. from all four views and provides a work assignment
distribution that factors in module dependencies,
Table 5. Development Effort View sequence of implementation of the modules,
Module Effort technological expertise required, and estimated
PS High development effort.
LO Low The work unit assignment view takes the form of a
grid. Information from the grid is read as follows:
CP Medium 1) Modules assigned to specific teams. This information
VC Low is contained in the white area of the grid. Teams are
DA High specified across the top of the grid in columns.
CE High Modules assigned to each team are then specified in a
HED Medium cell in a grid column below the team name.
RED Medium
2) Period of time in which a module must be
AM Medium implemented. Periods are expressed in multi-colored
AD Medium rows of the main grid. Modules are placed in cells
PD High that intersect the team name and the period in which
ARE Low the module must be implemented. Periods do not
necessarily have the same length. The duration
LRE Low
depends on the estimation of the development teams
CFG Medium based on their low-level design.
COV Low 3) Expected functionality at the end of a period based
AP Medium on modules implemented in that period. This
information is expressed to the right on the main grid
4.3. Results of Work Unit Assignments which expectations for each period included in the
same color and row as the targeted period. Reading
Based on information from the dependency view, this information vertically from top to bottom shows
how JOY's functionality will grow across periods.

Table 6. Work Unit Assignment View

FSS Adapter,

Presentation

Presentation

Presentation
Subscribe

Manager
Adapter

High-level
Publish

Rules,

Rules,

Module
Data

Team 1 Team 2 Team 3 Team 4 Team 5 Team 6 Expected Functionality (End of Period)
1. PS (H) 3. CP (M) 4. VC (L)
Basic communication from FSS to JOY and viceversa
Period 1 14. CFG (M)
without persistence
15. COV (L)
9. AM (M) 5. DA (H)
Full communication from FSS to JOY including
Period 2
persistence
16. AP (M) 6. CE (H) 11. PD (H)
Period 3 10. AD (M) 8. RED (M) 7. HED (M) User Interface
2. LO (L)
12. ARE (L) 13. LRE (L)
Period 4 Rule Engines

Technology required by each team

C# X X X X X X
.Net Remoting X X X X X X
ASP.Net X X X
AJAX X X
NHibernate X

Back-end Front-end
 across periods.
4) Technologies that each team has to know to
implement their modules. At the bottom of the main
grid, the technologies that each team needs to know
to implement their assigned modules are specified.
Teams need to know several technologies for their set
of assigned modules and each technology is specified
in a single row below the main grid. A marked cell
that intersects the team name with a technology
specifies which technology that team needs to know
to implement their set of modules.
5) System's high-level modules that each team will be
involved in implementing. This information is
expressed horizontally above the main grid. The
intersection of team name and high-level module
name shows which teams are involved in the
implementation of the details of a high-level
module(s).
6) Length of time in terms of periods that teams will
need to be involved in the project. This information
is expressed in the form of empty cells in the main
grid. An empty cell means that a team is not needed
during that period of development. Reading this
information vertically indicates how long a team is
needed for the duration of the project across the
periods. Reading this information horizontally gives
no information as the size of modules is not
specified.
7) Time available for teams to learn technologies they
need to know. This information is shown in the main
grid. The existence of empty cells read vertically in a
team name column indicates that a team has no
modules assigned to them in a period. Given that the
technologies a team needs is known, then a team can
use this time to learn a technology before they start
work on their modules.
Several important observations can be made from the
work assignment view and interpreting the information
embedded in this view. These observations are as
follows:
• During the first 2 periods, the system's implemented
functionality will include no development of the user
interface. Modules that constitute the back-end
functionality will all be implemented.
• The front-end will be developed in the last 2 periods
of development.
• All teams need to learn C# and .NET Remoting.
Based on these observations, we could make the
following suggestions:
• As soon as teams are identified for the project,
provide them with information about the technologies
they need to know. This will help in the productivity
and speed of development of the project as teams will
become familiar with their development tools before
the start of the project.
• Documentation of the back-end functionality can be
focused on intensively during periods 3-4 by teams 1-
3 as they will have “free time” based on the current
work distribution.
• Teams 4-6 will have to coordinate more because they
work on the Presentation module and Rules module.
Ideally, these two modules should be implemented by
two teams instead of three; hence, more coordination
is required and expected. The central team should
facilitate the communication channel among these
teams and provide the guidelines for user interface
design in order to achieve the same look and feel
throughout the system.
5. Conclusion
Software architecture by itself cannot assure the
success of a distributed development project. An
integrated project that incorporates a project plan, a
development process, a product integration process, a
configuration management environment, and a software
architecture that all support distributed development
must be in place for the success of a distributed
development effort.
A project plan for a distributed development project
needs to be structured based on the module
dependencies. This is a direct consequence of
dependencies present in the software architecture. A plan
that is based on the software architecture will be more
able to accommodate planning across teams and consider
integration and communication that needs to occur
between teams. The scheduling and organization of
teams and resources in the project plan can be deduced
from the time line and development effort views defined
earlier in this article.
A distributed development environment directly
affects the elements and relationships defined in a
software architecture. During the design of the JOY
architecture, the main elements affected by the
distributability requirement were the relationships
between elements of the architecture because they are
closely related to communication between the teams that
implement the elements.
In creating a software architecture, the architect must
consider work assignment as one of the important
allocation views of the software architecture. Work
assignment will be based on (1) skill set of development
teams, (2) development team availability, (3) feature list
requirements, (4) incremental delivery schedule, and (5)
module dependencies.
6. Acknowledgements
We would like to thank Prof. Jim Herbsleb, Tony
Lattanze, Cliff Huff, and Felix Bachmann for supporting
us in this project with their knowledge, experience, and
guidance.
7. References
[1] J. Herbsleb and R. Grinter, “Splitting The Organization
and Integrating the Code: Conway's Law Revisited”,
International Conference on Software Engineering, 1999.
[2] P. Clemens et al., Documenting Software Architecture,
Addison Wesley, United States, February 2004.
[3] L. Bass et al., Software Architecture in Practice, Addison
Wesley, United States, October 2004.
[4] T.R. Browning, “Applying the Design Structure Matrix to
System Decomposition and Integration Problems: A Review
and New Directions”, IEEE Transactions on Engineering
Management, Vol. 48, No. 3, August 2001, pp. 292-306.
[5] A. Yassine, “An Introduction to Modeling and Analyzing
Complex Product Development Processes Using the Design
Structure Matrix (DSM) Method”, Quaderni di Management
(Italian Management Review), www.quaderni-di-
management.it, No.9, 2004.