creating a software architecture for distributed development

8/7/2019 Creating a Software Architecture for Distributed Development

1/13

1

Creating a Software Architecture for Distributed Development

Min Chen, Bharat Gorantla, Okeno Palmer, Lutz WrageMaster of Software Engineering Program

Carnegie Mellon UniversityPittsburgh, PA 15213

{minc1, bgorantl,orp,lw}@andrew.cmu.edu

Abstract

Many companies have been using the distributed development model in their quest for

lower costs and availability of skilled resources to create software products. However,

distributed development projects face major problems due to inter-dependencies among work

items and challenges of coordination because effective communication is difficult to achieve

in distributed environments. Software architecture helps with the coordination of distributed

teams when designed appropriately taking in consideration the communication problems that

are exacerbated by the distributed environment. Software architecture by itself does not

assure the success of a distributed development project, but the architecture artifacts do

provide information about the expected communication patterns among the distributed teams

and, hence, a better insight on how to manage the project.

Keywords: Software Architectures,Programming teams

1. Introduction

Major sources of problems in distributed software development are inter-dependencies

among work items and challenges of coordination. Effective communication is difficult to

achieve for distributed teams because of distance, language, culture, time difference, and

work environment. Previous research suggests that the use of architecture, process, and tools

helps 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." "[Software

architecture] allows groups of people often separated by organizational, geographical, and

even temporal boundaries to work cooperatively and productively together to solve a much

larger problem than any of them would be capable of individually." [2].

Architectures have a strong influence on the communication patterns of development

teams. Therefore, they can be used to study distribution, in the sense of suggesting which

software components should be developed by which organizational units. Software

architecture and structure of the organizational units that will implement it must match to

successfully produce a system.

However, literature about architectures suitable for distributed teams is scarce. There are

many methodologies to reason about quality attributes also known as non-functional

requirements [3], such as performance and modifiability, but little is said about the suitability

of an architecture for distributed development.

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


2/13

2

architecture team responsible for re-designing a software architecture suitable for distributed

development.

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 workon a global development research project named "JOYA".

The goals of the JOYA project were to:

Learn from experimentation of processes in a globally distributed context. That is, toexperiment 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 welldocumented 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 JOYA project was planned for a duration of three years; the first iteration started inSeptember 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 ProblemsThe main problems we encountered while trying to implement the original JOYA

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 JOYA 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


3/13

3

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 butthere 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 that did not fit well together. The central team realized that they had

significantly underestimated the effort to manage such a distributed development project. Thisled 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 JOYA project to

fail, we identified several tactics we used to increase the distributability of our softwarearchitecture. By distributability we mean the suitability of the architecture for

development by distributed teams. 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 containsdetailed interface definitions to limit the amount of communication necessary to


4/13

4

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 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 therun-time architecture as several communicating processes. Each process shouldbe 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 JOYA system is already highly

multithreaded.

3)Trade distributability for code sharing. Each time a team uses modules that aredeveloped 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 modulesavailable 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. Dividing 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 teammembers' 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 unitsto teams.

2)Identify & Create Artifacts. For each criterion from the previous activity, createartifacts that specifically address this criterion.

3)Propose Work Unit Assignment. Create a work unit assignment that takes all criteriainto 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.


5/13

5

4.1.CriteriaID Criterion Description Artifacts

C1 Allow teams to

focus on specific

functionalities.

Each team will be responsible

for a set of functionality to

reduce the need for

communication with other

teams.

The modules, as designed by the

CMU team, are created with high

cohesion and low coupling in

mind. Hence, the resulting

modules are packages of

functionalities. The module view

of the architecture helps to

reason about this criterion.

C2 Create JOYA using

incremental

development.

There should be a functional

system by the end of each

incremental release.

To have a functional system in

each release, the development

teams have to implement

elements of the architecture that

will fulfill functional

requirements. Prioritized use

cases are one artifact used todecide in which order modules

have to be implemented.

C3 Create JOYA using

bottom up

development.

Before developing each

module, other modules it

depends on should already be

developed or under

development.

An artifact that shows the

module dependencies along with

the possible timelines will be the

best for this criterion. The CMU

team used a Design Structure

Matrix (DSM) to create a module

dependency view of the JOYA

architecture. A timeline view was

derived from the optimizedmatrix.

C4 Allow teams to

focus on few

technologies.

Save time by assigning work

units to teams according to

their expertise. Assign

modules to teams to minimize

the number of teams that need

to learn a technology.

It is necessary to know the

technologies that are required to

implement each of the modules

of the JOYA system. Hence, the

architecture team created a

technology view that maps each

module to the technologies that

are required in its

implementation.

Table 1. Work Units Assignment Criteria


6/13

6

4.1.1. Other Artifacts: To balance the teams' workload and resources, the architecture

team estimated the development effort required for each module. Information about the

teams, such as size, expertise and availability are also necessary, but they were not available

when assigning work units. This is shown in a development effort view.

4.1.2. Assumptions: Since the profile of the development teams was unknown, the

architecture team made the assumption that no team would have significant experience in any

of the required technologies.

4.2.ArtifactsThe artifacts presented in this section are those we created to address the criteria of the

previous section.

4.2.1. Dependency View

A Design Structure Matrix (DSM) was used to create the dependency view based on

the modules of the JOYA system. The DSM is a tool that displays the relationships

between elements of a system in a compact, visual, and analytically advantageous

format [4]. The DSM method is an information exchange model that allows therepresentation of complex module relationships in order to determine a sensible

sequence for the modules being modeled [5].

Table 2. Dependency View

The DSM in table 2 is a module-based binary matrix which rows and columns are headed

with the complete list of modules of the system. This is the final DSM as the result of using a


7/13

7

manual DSM partition algorithm. Marks in the matrix explain if there are dependencies

among the modules and, if so, which kind of dependency. A 1 in bold represents a uses

dependency, and a 1 in regular font represents a regular dependency. A uses dependency is

stronger than other dependencies: if module A uses 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 modulesdepend 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 the two modules do not depend on each other.

For more information about DSM and partition algorithms, refer to Yassines paper [5].

4.2.2. Timeline View

The timeline view is derived from the dependency view. It is based solely on the uses

dependencies to determine in which period a module can be developed. Regular 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

uses dependencies.

Table 3. Timeline View


8/13

8

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 Period1 regardless if the option is earliest or latest possible.

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 across several periods.

4.2.3. Technology View

The Technology View 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.

Table 4. Technology View

For the JOYA system we identified five technologies the development teams will use in its

implementation. As we assume that the teams do not have extensive experience in any ofthese, 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 shows the relative effort required to implement each

module in terms of:


9/13

9

Technologies involved in the implementation of the moduleComplexity of the design of the moduleAmount of functionality contained in the module

Table 5. Development Effort View

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 not have the necessary information about the teams level of experienceand expertise.

The purpose of this view is to help balance the workload of the work units.

4.3.Results of Work Unit AssignmentsBased on information from the dependency view, timeline view, technology view, and the

development effort view, a more informed way of assigning work in a distributed

environment can be done. The work assignment view below merges information from all four

views and provides a work assignment distribution that factors in module dependencies,

sequence of implementation of the modules, technological expertise required, and estimated

development effort.


10/13

10

Table 6: Work Unit Assignment View

The work unit assignment view takes the form of a grid with information embedded in

each axis of the grid. The primary information from this view is the assignment of modules to

teams. This is expressed in the main grid which is the white colored area of the grid. All

supplementary information is then embedded around this main grid. This information can

then be read both vertically and horizontally to the express information previously identified.

Information from the grid is read as follows:

1)Modules assigned to specific teams. This information is contained in the white area ofthe grid. Teams are specified across the top of the grid in columns. Modules assigned to

each team are then specified in a cell in a grid column below the team name.

2)Period of time in which a module must be implemented. Periods are expressed inmulti-colored rows of the main grid. Modules are placed in cells that intersect the team

name and the period in which the module must be implemented. Periods do not

necessarily have the same length. The duration depends on the estimation of the

development teams based on their low-level design.

3)Expected functionality at the end of a period based on modules implemented in thatperiod. This information is expressed to the right on the main grid which expectations for

each period included in the same color and row as the targeted period. Reading this

information vertically from top to bottom shows how JOYA's functionality will grow

across periods.


11/13

11

4)Technologies that each team has to know to implement their modules. At the bottomof 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. Thisinformation is expressed horizontally above the main grid. The intersection of team nameand 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 isshown in the main grid. The existence of empty cells read vertically in a team namecolumn 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 nodevelopment 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, the CMU team can make the following suggestions:

As soon as teams are identified for the project, provide them with information about thetechnologies 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 duringperiods 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 moduleand Rules module. Ideally, these two modules should be implemented by two teamsinstead 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.


12/13

12

5. Conclusion

Software architecture by itself can not 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

component 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 deducted 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 JOYA 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) element dependencies.

6. Author biographies

Min Chen is one of the founders and principal consultant at Alcenit Consulting Services.

Her research interests involve process improvement and distributed development. Previously,

she worked as a software consultant for the Latin America region. She was a Fulbright

scholar when she pursued the Master of Software Engineering degree at CMU. She can be

contacted at [email protected].

Bharat Gorantla is a Software Engineer at Bentley Systems. His research interests software

architecture, security for software systems, and global software development. Previously, he

developed financial software systems. He holds a Masters in Software Engineering from

CMU. He had co-authored an IT textbook for Secondary Schools published by Marshall

Cavendish International in 2004. He can be reached at [email protected].

Okeno Palmer is a Software Systems Architect at Verizon. He is a graduate the Master of

Software Engineering program at CMU. He is also a contributor to the codeproject.com

community. He can be contacted at [email protected].

Lutz Wrage is a senior member of the technical staff at the Software Engineering Institute

(SEI) of CMU. He is currently working in the areas of integration of software-intensive

systems and real-time architecture description languages. Previously, he worked as a

consultant for enterprise resource planning systems integration and customization. He has

over ten years of experience in software engineering.


13/13

13

7. Acknowledgements

We would like to thank Prof. Jim Herbsleb, Tony Lattanze, Cliff Huff, and Felix Bachmann

for their support in this project.

8. 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.

creating a software architecture for distributed development

Documents