software architectures and organizations in distributed development environments

8/7/2019 Software Architectures and Organizations in Distributed Development Environments

1/8

1

Software Architectures and Organizations in

Distributed Development Environments

Min Chen

Master of Software Engineering

Carnegie Mellon UniversityPittsburgh, PA

[email protected]

2005

Introduction

Software architecture, as defined by Clements et al, is 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

often separated by organizational, geographical, and eventemporal boundaries to work cooperatively and

productively together to solve a much larger problem than

any of them would be capable of individually. [Clements

2003]

Communication patterns are embedded in architectures.

Hence, architectures can be used to study distribution, in

the sense of suggesting which components will be given to

which organization units. The architecture can drive thestructure of the organization units that will implement the

system in the same way that the structure of an existing

organization unit influences in the architecture.

Software architectures, plans, and formal processes areimportant artifacts to achieve coordination with formal

communication. These are particularly useful in

organizations in distributed development environments

because the lack of communication across sites makes

coordination of the distributed teams difficult. A plan withwell-defined boundaries is critical in dividing work so that

it can be assigned to different teams. Also, an architecture

based on components with independent functionalities

helps divide the work across sites and reduces the

necessity of interaction among the teams [Herbsleb1999a].

There is an extensive literature about designing software

architecture to fulfill technical requirements. However,

literature about architectures suitable for organizations is

scarce. Furthermore, there are many methodologies to

reason about quality attributes such as performance and

modifiability, but little is said about the suitability of an

architecture to be assigned to organization units, namely

distributability.

This paper is the result of an independent study a

Carnegie Mellon University (CMU). The research topic is

about designing software architecture for distributed

development teams. The purpose of this independent studywas to incorporate useful ideas about architectures and

organizations from organizational behavior, socialpsychology, sociology, and engineering fields.

This independent study was done in parallel with a Studio

project. The goal of this project was to design an

architecture suitable for six distributed development teams

Some of the results of this independent study were applied

to the Studio project.

The ideas from the cited papers are categorized under one

of the following sections according to the contributions ofeach paper.

1.Architecture, Organization, and Coordination2.Distributability as a Quality Attribute3.Characteristics of a Distributable Architecture4.Designing and Reasoning about Distributability5.Documenting Distributable Architecture

The referenced papers are cited in the Annotated

Bibliographies section where the most relevant ideas abou

the topic of interest are presented. Interesting ideas that are

not relevant to the topic of this paper were not cited.

Annotated Bibliographies

1.Architecture, Organization andCoordination


2/8

2

a) Coordination in Task-Performing Groups

[Wittenbaum 1998]

The authors of this paper explain why teams need to

coordinate when performing together to achieve a common

goal. They also explain the coordination mechanisms and

when these mechanisms are more efficiently applied.

Coordination is an essential component of successful

group performance. Group coordination can vary on at

least two dimensions: time and explicitness. Coordination

may occur before group work begins or during the process

of working together. Coordination can also be tacit, basedon unspoken expectations and intentions, or it may be

explicit.

Collective tasks require varying degrees of dependence

among members in order to complete the task. Some tasksdemand that members work together to integrate their

efforts, whereas others allow members to perform wellwhile working independently. Tasks that create high

dependency among members add to the complexity of

synchronization and may render tacit coordination

strategies ineffective. Therefore, the more coordination

required of members, the more they should use explicit

strategies. When uncertainty is low, preplans made

significant contribution to organizational effectiveness,

whereas when uncertainty was high, coordination during

interaction contributed significantly to organizational

effectiveness.

A conclusion from the statements of the authors is that themore complex a system is, the more explicit the

coordination has to be. When a software architecture has

interdependent components that require teams to perform

together, it has to be well documented as a form of explicit

coordination.

Also, knowing in advance each teams profile skills,

size, and cultural background helps team to coordinate

by creating expectations about the performance of each

other. Teams profiles can also be used as an input when

designing an architecture of a system that will be

developed by these teams. In the same way, thearchitecture of the system can dictate the set of skills

required by each team in order to develop a certain

component. Cultural stereotypes are helpful to predict

how well a team will communicate.

b)How do Committees Invent? [Conway 1968]

The author states that there is a very close relationship

between the structure of a system and the structure of the

organization which designed it. This kind of a structure-

preserving relationship between two sets of things is called

a homomorphism. Organizations will stamp out an imageof themselves in every design they produce. The author

also used the Federal Government as an example of an

entity that is both a design organization designing laws

treaties, and policies and a designed system the

Constitution being the principal preliminary designdocument .

At the times when this cited paper was written, software

development was mainly done in-house. Architectures

reflected the structure of the design teams because theseteams were part of the end-users group. However, this

may not be true in the modern society where most of the

developments are done by independent software houses

and the design teams are not part of the end-user

organization. Custom-made software will more likereflect the structure of the organization for which it was

created. For example, ERP or other software fororganizational use will be structured to fit the end-users

group instead of the design team. The affirmation of the

author might still be true for general purposes software

such as office applications.

c) Architectural Innovation: the Reconfiguration o

Existing Product Technologies and The Failure o

Established Firms [Henderson 1990]

The authors of this cited paper state that architectural

innovations destroy the usefulness of the architectura

knowledge of established firms, and that sincearchitectural knowledge tends to become embedded in the

structure and information-processing procedures of

established organizations, this destruction is difficult for

firms to recognize and hard to correct. Architectura

innovation therefore presents established organizations

with subtle challenges that may have significant

competitive implications.

Architectural innovation has a more significant impact on

the relationships between components than on the

technologies of the components themselves.

The architectural knowledge is embedded in channels

filters, and strategies of an organization. Hence, the

discovery process and the process of creating new

information and rooting out the old usually takes time

The organization may be tempted to modify the channelsfilters, and strategies that already exist rather than to incur

the significant fixed costs and considerable organizational

friction required to build new sets from scratch.


3/8

3

The statements of the authors show why legacy

organizations are constraint by legacy the products they

designed. In the software industry, the legacy code hasshaped organizations in very significant ways.

Designing an innovative and successful architecture

requires having a new vision and be willing to throw away

the mindset with which an organization had designedarchitectures. Maybe creating distributable architectures

requires architects to use a complete new mindset and

design from a new perspective.

d) The Misalignment of Product Architecture and

Organizational Structure in Complex Product

Development [Sosa 2004]These authors also state that product architecture

knowledge is typically embedded in the communicationpatterns of established development organizations. Their

research integrates the product architecture andorganizational structure to study how design interfaces in

the product architecture map onto communication patterns

within the development organization.

There are known design interfaces not addressed by team

interactions, and observed team interactions not predicted

by design interfaces. Identifying when these two scenarios

can potentially happen helps managers to allocate

resources better. Managers must identify and manage

critical cross-boundary interfaces without relying on their

level of importance as a mechanism to improve their

alignment with interactions.

This paper points out the cases when these misalignments

can potentially happen. It is important to take these

scenarios in consideration when designing a system that

will be developed by distributed teams because they can

predict when unplanned coordination will be necessary for

the success of the project.

e) An Interdisciplinary Perspective on

Interdependencies [Cleidson 2005]

The authors present their survey about approaches forsupporting interdependencies from different disciplines,

including software engineering, organizational science

management, computer-supported cooperative work, and

human-computer interaction. They created a theoretical

framework that supports the comparison of approachesacross disciplines. This framework summarizes the

knowledge in the study of dependencies. It also provides a

common vocabulary for discussing interdependencies.

Among the most relevant ideas of this paper, there are

modularity, task model, product model, organizational

model, and Design Structure Matrices (DSM).

Modularity is one way to manage system complexityIt is achieved by decomposing the system. The

recomposition of the system suggests that produc

dependencies create task dependencies.

The product model describes dependencies betweenproduces or artifacts being developed by an

organization.

The task model describes how tasks or activitiesinteract to determine and outcome jointly. The focus is

not only on the study the tasks performed by particularorganizations, but also how the degree of

interdependencies between tasks influences the choice

of the associated coordination mechanisms to manage

these independences.

The organizational model focuses on how entireorganizations interacted in order to property

accomplish their goals. The product model and task model influence each

other. Different studies have shown that dependencies

in the product model create dependencies among

actors who, therefore, need to communicate and

coordinate to perform their task. Similarly

interdependencies in the task model influence how

organizations structure themselves. The interaction of

these two models show how software developmen

dependencies influence or are influenced by the

tasks that need to be performed in an organization.

Design Structure Matrix (DSM) is a tool that displays

the relationships between elements of a system in acompact, visual, and analytically advantageous format

Although most of the ideas represented in this cited paper

are taken from other sources, having this collection of

ideas in one place helped to find literature about

interdependencies of different domains and how to reason

about them.

Many of these ideas were used in the Studio project such

as the use of a DSM as an architecture dependency view

and the optimization of the DSM to obtain the ideal

sequence of development based on componentsinterdependency. Later on, this dependency view was used

to predict the interaction and interdependency of the

teams. It also helped in the grouping of components as

work units to be assigned to teams.

2.Distributability as a Quality Attributea) Achieving Qualities [Clements 2003]


4/8

4

The authors talk about tactics for achieving availability,

modifiability, performance, security, testability, andusability.

Although there is no mention about distributability, we

pay special attention to modifiability because it has similar

concerns.

There are three ways to achieve modifiability: localize

modifications, prevent ripple effects, and defer biding time.

Localize modifications includes maintaining semanticcoherence. Cohesion and coupling are two metrics for

module/component dependencies. Coupling and cohesion

metrics are an attempt to measure semantic coherence, but

they are missing the context of a change. Instead, semantic

coherence should be measured against a set of anticipatedchanges.

Modifiability is achieved by designing modules with high

cohesion and low coupling.

The challenge is to maintain the systems developed by

distributed teams. How to maintain and give support to a

system whose experts are scattered in different places?

Both maintainability and distributability are similar to

modifiability. There is no clear definition of when a

system is maintainable and distributable.

3.Characteristics of a DistributableArchitecture

a) Architecture for Software Construction by

Unrelated Developers [Gentleman]

The author explains the importance of a software

architecture at different phases: planning, operation,

maintenance, and evolution. An example of planning,

architectures can be used to study communication

requirements between components and, hence, to assess

the suitability for distribution in the sense of what should

run on which node or a network. If the software systemwas to be operated jointly by a collection of organizations,

the software architecture might be used to study

distribution, in the sense of suggesting which componentsand which responsibilities to be given to which

organization units.

Large and long-lived software systems can result from the

combined efforts of various unrelated developmentorganizations, organizations not even known to one

another. No single design authority, to which the others

report, has overall system responsibility. Such examples

also illustrate the importance of including in softwarearchitecture the relationship between entities that exist and

are used during the construction process, instead of

focusing only on relationships between entities that exist a

run time.

The author gives examples of complex projects that used

several COTS products to create one system. Wrappers

were used to integrate the COTS products because COTS

components produce their output in representation that are

not understandable to others.

The use of wrappers might not applicable when designing

architecture for distributed teams because the effort of

creating the wrappers might inhibit the reason for

distributing the development of the system.

4.Designing and Reasoning aboutDistributability

a) Applying Social Network Analysis to the

Information in CVS Repositories [Lopez 2004]

The authors used social networks to analyze the structure

evolution and internal processes of open source software

Social Network Analysis allows capturing importan

characteristics and relationships within a system. Theauthors also used a weighted graph to capture relationship

of developers and modules in which characteristics as

information flow or communities can be studied.

Knowing the structure and interaction among teams in

advance can help designing an architecture for distributed

teams. An architecture should not inhibit paths of

communication when they naturally exist, instead they

should allow for them in the design of the product.

The communication patterns revealed in the social network

analysis are particularly useful when designing a newsystem that is more suitable for the same organization

Social network analysis helps to understand legacy code

and the limitations imposed in legacy organization.

b) Using Dependence Analysis to Support Software

Architecture Understanding [Zhao 1997]

The author proposes the Architectural DependenceAnalysis technique to reason about the dependencies


5/8

5

among elements of the architecture of a software system.

The paper shows an example written in ACME and uses a

Software Architectural Dependence Graph (SADG) torepresent dependencies at the architecture level.

Although the SADG seems to be a useful representation, it

doesnt differ much from the graphical representation of a

design written in ACME.

The concept of architectural slicing is introduced in this

paper as a decomposition technique.

On of the benefits of this technique is that reusablearchitectural descriptions can be extracted by slicing the

architecture of a software system. Another possible benefit

of this approach is to find out how many elements are

affected with an architectural change.

There is no notion of architecture styles. Some of the

concepts are not be applicable to all architecture styles. Forexample, a meaningful slicing of a system that uses the

publish-subscribe style [Clements 2003] is not possible

because the results will show that all the components

connected to the event bus will be affected when one of

them is changed. This is not true because the publish-

subscribe mechanism is designed to loosen the

interdependencies among components, yet it keeps them

connected through the event bus.

c) Structural Analysis of the Software Architecture AMaintenance Assessment Case Study [Jaktman]

Architectural erosion is a sign of reduced architectural

quality. Quality characteristics of an architecture, such as

its ability to accommodate change, are critical for an

evolving product. The structure of an architecture is said to

be eroded when the software within the architecture

becomes resistant to change or changes become risky and

time consuming. The purpose of this paper was to

understand the signs of architectural erosion that

contribute to decreased maintainability.

The paper describes a maintenance assessment case study

in which the authors apply structural measurements to aproduct to determine signs of architectural erosion. It

provides an understanding of a products quality by

examining the structure of its architecture. The ability to

assess architectural erosion in an evolving software

produce allows the quality of the architecture to bemonitored to ensure its business and maintenance goals are

achieved.

It is not clear how this can be applied at design time when

there is no implementation of the software architecture. In

other words, it is not clear how to predict the quality of anarchitecture before actual development has started.

The authors also use the notion of call graphs a

architectural level, but it is not clear how this concept was

applied.

d) An Introduction to Modeling and Analyzing

Complex Product Development Processes Using the

Design Structure Matrix (DSM) Method [Yassine]This paper gives an introduction to the Design Structure

Matrix (DSM) and to the partition algorithm in order to

optimize the interaction among elements of the matrix

Parallel, sequential, and coupled tasks can be identified in

the partitioned matrix, as well as clusters of elementswhich means those elements are meant to be together.

The author presents different applications of DSM and

different analysis methods depending on the type of

application.

This paper was particularly useful for the Studio projec

because it not only explained how to create and interpret

the matrix but it also provided algorithms to optimize the

dependencies of the elements. The studio team created

module-based DSM and used the manual partition

algorithm to identify potential work units to be assigned to

distributed teams.

e) Developing Modular Product Architectures Using

Genetic Algorithms[Yu]

The authors point out the disadvantages of MDL and

Manual algorithms for partitioning DSM. They explain the

genetic algorithms and give examples of how they can be

applied.

Complex software systems can use this algorithm to

analyze the component interdependencies, but tool suppor

is required.

f) Exploring the Structure of Complex Software

Designs: An Empirical Study of Open Source and

Proprietary Code [MacCormack 2005]

The authors compared the structure of two complexsoftware applications using the DSM. The algorithms used

in the exercise were not explained in the paper. The

authors subtracted the dependencies of the systems from

the code instead of the architecture.


6/8

6

It is not clear how this can be applied at the architecture

level, or if it is even possible.

g) Architectural Optmimization Using Real Options

Theory and Dependency Structure Matrices [Sharman

2002]

This paper outlines a methodology for optimizing the

multi-domain architecture of a relatively integrated system

through an appropriate level of modularization. This

method is developed through the application of real

options theory and the dependency structure matrix.

The cost of a system is composed by the front-end costs of

adjusting the design rules and the back-end costs of testing

and integration. The costs of testing and integration of a

system are proportional to the numbers of modules andexperiments. Hence, a good architecture will have the

optimal mix of modularization and experimentation.

The authors mention three different domains that are

related and interact among each other: product,

organization and process domain. The elements might not

have a one-to-one mapping from one domain to another.

This trade-space is important because it creates tension

between domains and it can be the source of dynamism in

architectures, and an indication of the potential for

disconnects between domains.

Maybe this approach explained by the authors can help

predict the quality of the product architecture and howlikely it will erode.

5.Documenting Distributable Architecture

a) A Template for Documenting software and

Firmware Architectures [Ogush 2000]

The authors created a template for documenting

architectures. The most important section of this template

is the interface table that offers a clear description of what

it is and is suppose to provide. This allows distributed

teams to understand the expectations of their componentsfrom others.

A modified version of this template was used to documentthe architecture of the Studio project.

b) Organizational Information Requirements, Media

Richness and Structural Design [Daft 1986]

The authors state that companies process information to

prevent two problems: equivocality and uncertainty.

Uncertainty is absence of information. As information

increase, uncertainty decreases. When the uncertainty is

gone, additional data will not provide more information

Uncertainty is a measure of the organizations ignorance o

a value for a variable in the space. Usually, asking the yes-no questions help to reduce uncertainty.

Equivocality is ambiguity. It is the existence of multiple

and conflicting interpretations about a situation.

Rich media, such as face-to face meetings, are important to

avoid equivocality. Media with low richness is enough to

avoid uncertainty.

Uncertainty and equivocality affect the way thearchitecture design is document. To reduce uncertainty, the

right amount of information is needed. To reduceequivocality, meaningful and non-conflicting information

is necessary.

Uncertainty will help the Studio team to define the level of

details that has to be provided in the architecture design

document. Interdependence increases uncertainty because

action by one team can unexpectedly force adaptation by

other teams.

Equivocality will help identifying conflicting areas

Documenting the interfaces helps reducing both

uncertainty and equivocality.

Conclusion

Software architecture allows groups of people to work

cooperatively.

Although the issues of distributability as a quality attribute

are not addressed in the software engineering, there are

many techniques and methodologies used to address

similar issues in other disciplines. The Design Structure

Matrix (DSM), for example, has only been used in the

software field to represent dependencies at the code level

It is possible to use the DSM to represent the dependencies

of the elements of a system at the architectural level and

obtain the ideal system development sequence and module

grouping.

The DSM contributes as a dependency view that is

necessary when creating work units for distributed teams

Other information is also important when creating these


7/8

7

work units, such as decomposition of the system in

modules, technology required for each module, size and

complexity, and development teams profile and schedule.

All this information helped the Studio team to create a

work units assignment that is suitable for distributed

teams. Some trade-offs were necessary, specially between

reusability and distributability.

Acknowledgements

This independent study was possible thanks to Prof. James

Herbsleb who was my advisor for this research exercise.

Some of the ideas derived from the cited papers were inpractice thanks to the Sapphire studio team.

References

[Conway 1968] Conway, M., "How do Committees Invent?"Datamation, 1968

[Daft 1986] Daft, R. and Lengel, R., "OrganizationalInformation Requirements, Media Richness andStructural Design." Management Science,1986.

[Gentleman] Gentleman, W., "Architecture for SoftwareConstruction by Unrelated Developers."Institute for Information Technology, Ottawa,Ontario, Canada.

[Henderson 1990] Henderson, R., and Clark, K.,"ArchitecturalInnovation: the Reconfiguration of Existing

Product Technologies and The Failure ofEstablished Firms."Cornell University, 1990.

[Jaktman] Jaktman, C., Leaney, J., and Liu, M.,"Structural Analysis of the SoftwareArchitecture - A Maintenance AssessmentCase Study." University of Technology,Sydney, Australia.

[Lopez 2004] Lopez-Fernandez, L. et al, "Applying SocialNetwork Analysis to the Information in CVSRepositories."Univesidad Rey Juan Carlos,2004.

[MacCormack2005]

MacCormack, A., Rusnak, J., and Baldwin, C.,"Exploring the Structure of Complex SoftwareDesigns: An Empirical Study of Open Source

and Proprietary Code."Harvard BusinessSchool, 2005.

[Ogush 2000] Ogush, M., Coleman, D., and Beringer, D., "ATemplate for Documenting software andFirmware Architectures."Hewlett Packard,2000.

[Sharman 2002] Sharman, D.,Yassine, A., and Carlile, P.,"Architectural Optimization Using Real OptionsTheory and Dependency Structure Matrices."Massachusetts Institute of Technology, 2002.

[Sosa 2004] Sosa, M., Eppinger, D., and Rowles, C., "TheMisalignment of Product Architecture andOrganizational Structure in Complex ProductDevelopment."Management Science, 2004.

[Souza 2005] Souza, C., and Redmiles, D., "AnInterdisciplinary Perspective onInterdependencies." Institute for SoftwareResearch, University of California, 2005.

[Wittenbaum 1998] Wittenbaum, G., Vaughan, S., and Stasser, G.,"Coordination in Task-Performing Groups."Plenum Press, 1998.

[Yassine] Yassine, A., "An Introduction to Modeling andAnalyzing Complex Product DevelopmentProcesses Using the Design Structure Matrix(DSM) Method."University of Illinois at Urbana-Champaign.

[Yu] Yu, T., Yassine, A., and Goldberg, D.,"Developing Modular Product ArchitecturesUsing Genetic Algorithms."University of Illinoisat Urbana-Champaign.

[Zhao 1997] Zhao, J., "Using Dependence Analysis to

Support Software Architecture Understanding."Fukuoka Institute of Technology, 1997.

Other References

[Bass 2003] Bass, L., Clemens, P., and Kazman, R.,"Software Architecture in Practice", SEI Seriesin Software Engineering, 2003.

[Brook 003] Brook, G., "Working in a DistributedDevelopment Team.", SYS-CON Media, 2003.

[Cannon-Bowers1993]

Cannon-Bowers, J., Salas, E., and Converse,S., "Shared Mental Models in Expert TeamDecision Making." Lawrence Earlbaum andAssociates, Inc., 1993.

[Carmel 1999] Carmel, E., Global Software Teams. Prentice-Hall, 1999.

[Clements 2003] Clemens, P., Bachmann, F., Bass, L., GarlanD., Ivers, J., Little, R., Nord, R., and Stafford,J., "Documenting Software Architecture", SEISeries in Software Engineering, 2003.

[Cubranic] Cubranic, D., and Booth, K., "CoordinatingOpen-Source Software Development." Canada.

[Donohoe 1999] Donoheo, P., "Software Architecture."KluwerAcademic Publishers, 1999.

[Espinosa 2001] Espinosa, J., Kraut, R., Lerch, J., Slaughter, S.,Herbsleb, J., and Mockus, A., "Shared MentalModels and Coordination in Large-Scale,Distributed Software Development." Twenty-Second International Conference onInformation Systems, 2002


8/8

8

[Espinosa 2002] Espinosa, J., Kraut, R., Lerch, J., Slaughter, S.,Herbsleb, J., and Mockus, A., "Shared MentalModels, Familiarity, and Coordination: A Multi-method Study of Distributed Software Teams."Twenty-Third International Conference onInformation Systems

[FutureSoft] "Call Graphs - A move Towards BetterProductivity."FutureSoft.

[Herbsleb 1999a] Herbsleb, J. and Grinter R., "Splitting TheOrganization and Integrating the Code:Conway's Law Revisited." InternationalConference on Software Engineering, 1999

[Herbsleb 1999b] Herbsleb, J., and Grinter, R., "Architectures,Coordination, and Distance: Conway's Law andBeyond." IEEE, 1999

[Herbsleb 2001b] Herbsleb, J., and Moitra, D., "Global SoftwareDevelopment." IEEE Software, 2001

[Herbsleb 2003] Herbsleb, J., and Mockus, A., "An EmpiricalStudy of Speed and Communication inGlobally-Distributed Software Development."IEEE, 2003

[Kraut 1995] Kraut, R., and Streeter, L., "Coordination inSoftware Development."ACM, 1995.

[Mockus 2001] Mockus, A. and Herbsleb J., "Challenges ofGlobal Software Development." IEEE, 2001

[Paulk 2004] Paulk, M., Hyder, E., and Heston, K., "TheeSourcing Capability Model For ServiceProviders.", Carnegie Mellon University, 2004.

[Paulish 2001] Paulish, D., "Architecture-Centric SoftwareProject Management: A Practical Guide."SEISeries in Software Engineering, 2001.

software architectures and organizations in distributed development environments

Documents