Application 1 – Analysis and Synthesis of Prior Research

S

H I

a

A R R A A

K S L C S A Q

1

o t s u e m r d 2 p c o a k a a p e

0 d

The Journal of Systems and Software 83 (2010) 2211–2226

Contents lists available at ScienceDirect

The Journal of Systems and Software

j o u r n a l h o m e p a g e : w w w . e l s e v i e r . c o m / l o c a t e / j s s

oftware architecture awareness in long-term software product evolution

ataichanok Unphon ∗, Yvonne Dittrich T University of Copenhagen, Rued Langgards Vej 7, DK-2300, Copenhagen S, Denmark

r t i c l e i n f o

rticle history: eceived 15 October 2009 eceived in revised form 23 April 2010 ccepted 27 June 2010 vailable online 17 July 2010

eywords: oftware products ong-term evolution ooperative and human aspects

a b s t r a c t

Software architecture has been established in software engineering for almost 40 years. When devel- oping and evolving software products, architecture is expected to be even more relevant compared to contract development. However, the research results seem not to have influenced the development prac- tice around software products very much. The architecture often only exists implicitly in discussions that accompany the development. Nonetheless many of the software products have been used for over 10, or even 20 years. How do development teams manage to accommodate changing needs and at the same time maintain the quality of the product? In order to answer this question, grounded theory study based on 15 semi-structured interviews was conducted in order to find out about the wide spectrum of archi- tecture practices in software product developing organisations. Our results indicate that a chief architect

oftware architecture rchitecture knowledge management ualitative empirical studies

or central developer acts as a ‘walking architecture’ devising changes and discussing local designs while at the same time updating his own knowledge about problematic aspects that need to be addressed. Architecture documentation and representations might not be used, especially if they replace the feed- back from on-going developments into the ‘architecturing’ practices. Referring to results from Computer Supported Cooperative Work, we discuss how explicating the existing architecture needs to be com- plemented by social protocols to support the communication and knowledge sharing processes of the

‘walking architecture’.

. Introduction

Software products are programs that are used by more than one rganisation. They are often configured and customised to fit with he specific use context. They are long-living; often evolving over everal decades. Bug fixes and upgrades are delivered on a reg- lar basis. Though especially for software products that need to volve to keep up with technical and application domain develop- ents the architecture should be an important asset, our previous

esearch showed that the companies we have been in contact with id not have a formal architecture process (Unphon and Dittrich, 008). Nonetheless, the software has been successful over long eriods of use and evolution. So our questions are: how do these ompanies manage to maintain the evolvability of their products ver a long life-time? Are the development teams aware of the rchitecture of their product? If yes, how does the architecture nowledge become influential in the development, and how is the

rchitecture updated in the on-going evolution? The goal of the rticle is to better understand the architecturing practices software roduct developing teams employ when evolving their product. We specially are interested to understand whether the practices we

∗ Corresponding author. Tel.: +45 7218 5000; fax: +45 7218 5001. E-mail addresses: [email protected] (H. Unphon), [email protected] (Y. Dittrich).

164-1212/$ – see front matter © 2010 Elsevier Inc. All rights reserved. oi:10.1016/j.jss.2010.06.043

© 2010 Elsevier Inc. All rights reserved.

observed previously are unique or are an instance of a wider spread phenomenon.

The questions aim at understanding how developers relate to architecture as context of their activity and how architecture is used to support mutual awareness in order to coordinate paral- lel activities in the team. ‘Awareness’ has been discussed in the Computer Supported Cooperative Work (CSCW) discourse for over 2 decades. Referring to the notion of awareness developed by Heath and Luff (1992) based on the analysis of the cooperation of line con- trollers and Divisional Information Assistants in line control rooms of the London underground is cited as a seminal study. Through both monitoring common displays and each other’s activity, they managed the common tasks – advising train drivers and informing passengers about delays – with little explicit coordination. Even the reactions of each colleague was monitored so that the missing of a necessary reaction could be caught, which then caused either a more emphasised behaviour or if necessary explicit coordination. Since then, such heedful situated coordination has been reported from a range of activities and resulted in specific awareness support in groupware applications (Gutwin and Greenberg, 2002). Schmidt

(2002) remarks in an article for a special issue of CSCW journal: awareness is a substantiation of an attribute of an activity. Some- one is acting in awareness of the activity of others and of changes in the context. The issue then is to understand what the coordi- nation or awareness mechanisms are in play, and how they can be

2 System

s i s

w a t t f r t o

o a b s a t p l w a s C h d o i m T s

i t o c c o w d c a b t t t d

t w s c i i s

a a t e s t d w c

architect has been discussed in many sites and portals on soft- ware architecture; well-known examples include Bredemeyer’s site (Bredemeyer, 2010), the Software Engineering Institute (SEI) architecture website (SEI, 2010), and Wikipedia’s software archi-

212 H. Unphon, Y. Dittrich / The Journal of

upported. In other words, what are the clues a co-operator is read- ng, how does he or she make their own actions accountable to the urroundings, and what are the means and protocols in play?

Applying the concept of awareness as a lens to understand soft- are architecture practices implies a focus on the situated use of

rchitectural knowledge when (a) making changes to a module hat might have implications on another’s code – that is changes he interface – visible, (b) monitoring changes that are relevant or the task at hand, and (c) monitoring changes to the code, the equirements, and the context that makes it necessary to change he architecture and thus change the design and implementation f the different modules.

The article reports results of an interview study. In previ- us research we observed informal sharing and maintenance of rchitectural knowledge and started to understand the rationality ehind this practice (Unphon, 2009). The design of the interview tudy is based on these observations. Awareness mechanisms in ction need to be observed in situ. Interviews, however, provide he possibility to compare the reported practices of different com- anies, and thus give an indication of whether or not we are

ooking at a wider spread phenomenon. The interview guideline as based on our previous studies and based on the concept of

wareness as a theoretical lens. We interviewed members of eight oftware developing organisations in five countries (i.e., Belgium, hina, Denmark, Germany, and Switzerland). Each organisation as on-going software product development. The interviews were one and analysed in a grounded theory manner. The motivations f applying a grounded theory approach was to not only collect nformation of what is going on in the companies, but also what

otivates different practices, and how they depend on each other. he interviews both confirmed and deepened our previous under- tanding.

Our results indicate that the industrial practice in most cases s not what is recommended by applicable textbooks. Nonetheless, he structure of software products is regarded as an important asset f development. Rather than documenting it in a formal way, most ompanies rely on a practice for which we have coined the con- ept of a ‘walking architecture.’ This is a key person, or a number f key persons, who maintain and update the structure of the soft- are, and are involved in discussions of changes motivated in the evelopment, or by new requirements, and who introduce new- omers to the structure of the software. Representations of the rchitecture thus are temporary and partial, e.g., sketches on white- oard and scrap paper used in a specific situation. The result of his practice is not only the distribution of architectural knowledge o the development team, but also an update of the chief archi- ect’s knowledge on the issues the developers meet when they evelop.

We argue in our discussion that software architecture litera- ure, so far, has underestimated this feedback, and that here maybe e can find reasons for the lack of appreciation of recommended

oftware architecture methods in industry. By using the awareness oncept from CSCW when discussing our findings, we highlight the mportance to focus not only on documentation and tools when mproving architectural practices, but also on the development of ocial protocols around such methods and tools.

In the next section, we discuss related literature on software rchitecture and software evolution, but also on knowledge man- gement in software engineering and the concept of awareness hat originated in the discourse of Computer Supported Coop- rative Work that has been adopted in research on distributed

oftware engineering. Section 3 shows research methodology. Sec- ion 4 elaborates on interviewees and their companies, then briefly escribes interview guideline. Section 5 shows an analysis of soft- are architecture awareness. Section 6 is discussion. Section 7 is

onclusions.

s and Software 83 (2010) 2211–2226

2. Architecture, knowledge, and awareness

This section introduces the research we build upon and con- tribute to. The section starts with discussing the notion of software product architecture and evolution, then discusses knowledge management in software engineering and the notion of awareness which stems from the discourse on Computer Supported Coopera- tive Work.

2.1. Software architecture

In programming, the term architecture has been used since the late 1960s (Brooks and Iverson, 1969). In the early 1970s, Par- nas contributed many of the fundamental tenets and principles behind software architecture (Parnas, 1971, 1972, 1974, 1976). The report and book by Garlan and Shaw (Garlan and Shaw, 1994; Shaw and Garlan, 1996) not only redefined software architecture overall, but also introduced a number of architectural styles and reference architectures. They introduced the notions of components, connec- tors and constraints. More and more researchers, e.g., Jansen and Bosch (2005), Tyree and Akerman (2005), Kruchten et al. (2006), van der Ven et al. (2006), emphasised the notion of the design ratio- nal, and illustrated how architectural representations can improve the understanding to complex software systems.

Software architecture is meant to serve a number of purposes: as it decomposes the software into components, it helps to handle complexity in a divide and conquer manner; the decomposition serves also as a base to structure the implementation work into manageable chunks assigned to individuals or small teams; it pro- vides a base to analyse and assess non-functional requirements of the software to be built, or of the changes introduced (Bass et al., 2003; Kruchten, 1995; IEEE 1471-2000 standard1).

The practices of creating an architecture proposed heavily rely on written representations, and when necessary, (semi-) formal notations (e.g. Allen and Garlan, 1997, 1992; Booch et al., 1998; Dunsire et al., 2005; Feiler et al., 2006; Garlan et al., 1997; Gasparis et al., 2008; Luckham, 1996; Luckham and Vera, 1995; Medvidovic et al., 1999; Shaw et al., 1995; The Open Group, 2009; Weilkiens, 2008). The notations provide an explicit way of specifying the ele- ments and their connections used in the architecture.2 Over time, as the software evolves, the code structures become less tightly cou- pled with the design architecture, aka the code view vs. the module view (Hofmeister et al., 2000). The design architecture has layers, modules and dependencies, but the source code architecture con- tains folders and files, as well as, static and dynamic relationships between different classes. Keeping the correspondence between design architecture and code architecture alive requires a rigorous engineering discipline (Bischofberger et al., 2004).

2.2. The role of the software architect

It would be somewhat misleading to place the main responsibil- ity for the maintenance of the architectural structure of a software product with the software architect. The role of the software

1 IEEE 1471-2000 standard is now ISO/IEC 42010 standard. 2 Tools developed on top of those notations generate part of the implementa-

tion based on the architecture. In this way, the organisation of source code—when developed that way from scratch—conforms to major design elements and the rela- tionships among them. Model Driven Development (MDD) aims at supporting the evolution through these tools (Czarnecki et al., 2000; Greenfield et al., 2004).

System

t r a c a A d i b s m A g t p T d c a t i t o

t s t s p d p o a t c i a t t a t n a i s i a e s

t y 5 a t r t o u c s b o a r o

Knowledge management has been a major topic in software engineering, even before the concept had been coined by Nonaka at the beginning of the nineties (Nonaka, 1994, 1998). In their sem-

H. Unphon, Y. Dittrich / The Journal of

ect website (Wikipedia, 2010). A recent survey on ‘what architects eally do’ (Farenhorst and de Boer, 2009) confirmed that architects re mostly busy with taking architectural decisions. Fowler (2003) ategorised architect’s roles into two types: Architectus Reloadus nd Architectus Oryzus based on decision making approaches. rchitectus Reloadus is an architect who makes all the important ecisions. The architect in this type does this because a single mind

s needed to ensure a system’s conceptual integrity, and perhaps ecause the architect does not think that the team members are ufficiently skilled to make those decisions. Often, such decisions ust be made early on so that everyone else has a plan to follow.

rchitectus Oryzus is an architect that must be very aware of what is oing on in a project, looking out for important issues and tackling hem before they become a serious problem. The most noticeable art of the work for Architectus Oryzus is the intense collaboration. he most important activity of Architectus Oryzus is mentoring the evelopment team to raise their level so that they can take on more omplex issues. Improving the development team’s ability allows n architect much greater leverage utilizing the entire team rather han being the sole decision maker and running the risk of becom- ng an architectural bottleneck. This leads to the rule of thumb hat an architect’s value is inversely proportional to the number f decisions he or she makes.

Kruchten (1999) listed the roles and responsibilities of an archi- ect or an architecture team: (i) defining the architecture of the ystem; (ii) maintaining the architectural integrity of the sys- em; (iii) assessing technical risks; (iv) working out risk migration trategies/approaches; (v) participating in project planning; (vi) roposing order and content of iterations; (vii) consulting with esign, implementation, and integration teams; and (viii) assisting roduct marketing and future product definitions. The definition f software architecture includes all the usual technical activities ssociated with design: understanding requirements and quali- ies; extracting architecturally significant requirements; making hoices; synthesizing a solution; exploring alternatives and val- dating them; etc. For certain challenging prototyping activities, rchitects may have to use services of software developers and esters. The maintenance of the architectural integrity takes place hrough regular reviews; writing guidelines, etc. and presenting the rchitecture to various parties as different levels of abstraction and echnical depth. For many effort estimation aspects, or for the plan- ing of distributed development, managers need the assistance of rchitects. Because of their technical expertise, architects are drawn nto problem-solving and fire-fighting activities that are beyond olving strictly architectural issues. The architects have insights nto what is feasible, doable, or ‘science fiction’ and their presence in product definition or marketing team may be very effective. How- ver, good architects should bring a good mix of domain knowledge, oftware development enterprise, and communication skills.

Later on, Kruchten (2008) recommended a simple ime–management practice for architects based on more than 10 ears of his experience. The recommended time ratio allocates 0% internal, 25% inward, and 25% outward activities. The internal ctivities focus on architecting per se (architectural design, pro- otyping, evaluating, documenting, etc.). The inward and outward efer to cooperation and communication with other stakeholders hat the architects interact with. The inward is to get input from the utside world. For example, listening to customers, users, prod- ct manager, and other stakeholders (developers, distributors, ustomer support, etc.), and learning about technologies, other ystem’s architecture, and architectural practices. The outward can

e seen as providing information or helping other stakeholders r organisations (e.g., communicating architecture, project man- gement, or product definition). The 50:25:25 time–management atio helps the architects to be aware of the risks of falling into one f the following situations: creating a perfect architecture for the

s and Software 83 (2010) 2211–2226 2213

wrong system, creating a perfect architecture that’s too hard to implement, architects in their ivory tower, or absent architects.

Grinter (1999) presented a study of the roles of architects, in particular, the work that they do to coordinate design cross- organisational and institutional boundaries. Bass and Klein (2008) reckoned the relationship between architects and organisations towards consistency producing high-quality architectures. They proposed models for evaluating and improving architecture com- petence of software architects, software architect teams, and software architecture producing organisations. The models are based on (1) the duties, skills, and knowledge required of a software architect or architecture organisation, (2) human performance technology, an engineering approach applied to improving the competence of individuals, (3) organisational coordination, the study of how people and units in an organisation share information, and (4) organisational learning, an approach to how organisations acquire, internalise, and utilise knowledge to improve their perfor- mance.

2.3. Software product evolution and architecture

The intrinsic evolutionary nature of real-world computer usage and of software embedded in its use context was originally recog- nised in Belady and Lehman (1976), and Lehman (1980). The dynamism of the real world induces software to be continu- ally changed, updated, and evolved over its life-time. As the software evolves, its architectural integrity tends to dilute. For example, source code architecture drifts from its design archi- tecture (Murphy et al., 1995). The gap between the source code and the design architecture hinders program understanding which leads to development and maintenance activities that are increas- ingly difficult and highly error prone (Tran et al., 2000; Unphon, 2009). However, the effort emphasised on updating the software in order to improve upon the future maintainability without chang- ing its current functionality, the so-called ‘preventive maintenance’ (Lientz and Swanson, 1980), aka anti-regressive activity (Lehman, 1996) or refactoring (Fowler, 1999), is not highly prioritized (Lientz and Swanson, 1981; Schach et al., 2003). Even though preventive maintenance offers significant improvements in the simplicity of conducting maintenance interventions in the long-term, it brings little to no immediate benefits (Madhavji et al., 2006). As a result the software becomes more difficult to maintain.

Decisions made during initial software development affect the ability of organisations to successfully perform software change. In particular, the selection of architecture could either aid or hin- der changes made through evolution (Madhavji et al., 2006). Once the first version of the architecture has been implemented, the evolution will become the primary activity. In socially embedded software,3 end-users are able to tailor their software products, e.g., through configuration, composition, expansion, or extension (Eriksson, 2008). However, the end-users are able to tailor their software with a minimum risk if their requirements were antic- ipated in the design of architecture. To react on un-anticipated, evolving needs, the software itself evolves over time.

2.4. Knowledge management

3 Socially embedded software refers to software that can be modelled intensively according to the environment and practices of its end-users (Unphon et al., 2009b). The socially-embedded software, can be seen as E-type programs (Lehman, 1996). We also refer it as social software.

2 System

i P b n m t c u b a s r t b c t s d h n

i t t a e i i e

t t ( ( a m s p k d o u A s k b s i

2

h e ‘ p t n d n S d

214 H. Unphon, Y. Dittrich / The Journal of

nal article ‘The rational design process: Why and how to fake it’, arnas and Clements (1986) argue that though to design software y deriving the design and source code from the requirements is ot possible, the software team should aim at producing the docu- entation that mirrors such a rational design process. The reason is

o document the reasoning and rationale behind design decisions in ase revisions become necessary, and in order to have suitable doc- mentation for the maintenance team. Today this argument could e related to what Dingsøyr and Conradi (2002) call codification pproaches to knowledge management: such approaches empha- is the codification, digital storage, and retrieval of information epresenting relevant knowledge. Complementary personalisa- ion oriented approaches emphasize face-to-face communication etween people in-the-know and who need to know. In his arti- le ‘Programming and Theory Building’, Naur (1985) emphasises he importance of participation in the development team to under- tand the rationale behind a design. Only through participation in esign and development can help software engineers to understand ow the software models its problem domain and supports the eeds of its users.

Though software engineering from the beginning overstated the mportance of documentation for the development process, and herefore exhibited an affinity to codification oriented approaches o software architecture, empirical research (Section 5; Farenhorst nd de Boer, 2009) indicates that personalisation strategy (Hansen t al., 1999) is at least as important in architectural knowledge shar- ng. In a dialogue situation, knowledge can be tailored to the context n which it is needed. Through this communication, the software ngineer who shares his knowledge also updates his knowledge.

The discussion on software architecture knowledge emphasises he codification, storing and retrieval of information on architec- ure. However, this codification strategy does not work in practice Lago et al., 2008). The people involved in the architecting process who own the knowledge) often do not document it (Harrison et l., 2007). The reasons are a lack the motivation to document and aintain architecture knowledge, as the benefits do not seem sub-

tantial enough to justify the effort; the short-term interest in the roject becomes more important than the long-term architectural nowledge reuse; developers are absorbed in the creative flow of esign and thus don’t reflect on long-term impact of decisions; lack f training. Even worse, when the architecture knowledge is doc- mented, it’s often not sufficiently shared within the organisation. s examples Lago et al. (2008) gives (i) the knowledge is not dis- eminated to the appropriate stakeholders; (ii) the recipients of nowledge don’t use it in their own tasks, either intentionally, or ecause there is no provision in the processes; (iii) it’s cumber- ome to search and locate the appropriate knowledge and adapt it n one’s needs.

.5. Awareness in software engineering

The concept of awareness as defined in the introduction ighlights what can be called a situated socialisation-based knowl- dge sharing mechanism. Dourish and Bellotti (1992) define:

[A]wareness is an understanding of the activity of others which rovide a context for your own activities.’4 In software engineering, he notion of awareness is so far mostly used to address coordi- ation of distributed development, for example, Grinter’s study of

istributed development and integration emphasises the coordi- ation role of architecture when evolving software (Grinter, 2003). torey et al. (2005) give an overview of different tools that are esigned to help programmers monitor changes to the common

4 Highlighting as in the original.

s and Software 83 (2010) 2211–2226

software under development that might become relevant for their own programming. Particularly, in spatially distributed develop- ment, parallel on-going work cannot be monitored by means of ‘overhearing’ design discussions taking place in the vicinities. Also, meetings, such as daily stand-up meetings, that are designed to provide a project team with a development overview, with respect to the common product, cannot help this need. Tools visualising social-technical dependencies, and thus helping to contact the cor- rect person, e.g., de Souza et al. (2005), are designed to address this lack. Such tools can be understood as support for fine-grain knowledge sharing. Recent research, however, indicates that tech- nical support addresses only one side of the problem: awareness problems can also occur in cases of mismatched social protocols (Damian et al., 2007).

The importance of such protocols has already been indicated in the early studies on the London underground control room. ‘However, it is clear that while certain activities are primarily accomplished by specific categories of individuals, the in situ accomplishment of these tasks is sensitive to, and coordinated with, the actions and responsibilities of colleagues within the immediate environment. The competent production of a range of specialised individual tasks within the Control room is thoroughly embedded in, and inseparable from, a range of socio-interactional demands’ (Heath and Luff, 1992, p. 82, highlighting by the authors). This interlacing of their own and their co-workers activities is not only guided by a codex of explicit rules, but depends on competence with respect to understanding established practices (Heath and Luff, 1992, p. 78).

The usefulness of the technology that is the base of this inter- action ‘relies upon a collection of tacit practices and procedures through which Controller and Divisional Information Assistant (DIA) coordinate information flow and monitor each other’s con- duct (Heath and Luff, 1992, p. 87, see also Schmidt, 2002).

With the term ‘practice,’ we describe a common way of acting acknowledged by the community that shares the practice (Hansson et al., 2006, p. 1296). A group of co-operators maintains the com- mon practice through reproducing it in their every day actions. Practice thus is distinguished from ad-hoc behaviour, which as such is only perceivable by its deviation from both the formalized rules and the established practice. Such practices as well as explicitly agreed on procedures have been also called social protocols (Gerson and Star, 1986; Schmidt and Simone, 1996). They are developed and maintained through on-going ‘articulation work’ or ‘meta-work’ of the members and can only to some extent be designed from the outside.

So far, only one project addresses awareness issues with respect to software architecture: application programmer interfaces (APIs), the interfaces that make the functionality of one module avail- able, are discussed in a way that can be regarded as implementing the material side of an awareness mechanism (de Souza et al., 2004). Often when APIs are used to indicate boundaries between development groups, corresponding social protocols are estab- lished indicating that software teams who implement functionality using the module are informed if the API needs to change. The arti- cle, however, does not refer to the role of the architecture, nor the everyday work of the software architect.

3. Research methodology

The study has been designed as triangulation complementing

in depth ethnographically informed studies in two organisations (Unphon et al., 2009b; Unphon and Dittrich, 2008). Being aware of those architectural practices in situ would be best observed by participatory observation, we nonetheless decided for an interview study. Interviews provide the possibility to compare the reported

System

p w c v w s o w a t a

a c p e s f i o e m s o 3

3

i a t I o I t c c p

u I r e c a

o i e t

p r e a d c p a

3

d D

H. Unphon, Y. Dittrich / The Journal of

ractices of different companies, and thus give an indication of hether or not we are looking at a wider spread phenomenon. We

arefully designed the interview guideline both based on our pre- ious observation and using the concept of awareness as a lens: e asked not only into document based architectural knowledge

haring, but addressed especially face-to-face communication and ther informal practices. Most work on architecture focuses on hat from a research perspective is understood as shortcomings

nd aim at deriving various remedies. Our research and thus also he interviews aim at understanding how software engineers man- ge.

The interviews aimed at mapping out the architectural practices s well as documents and artefacts and their usage. The questions over business contexts of the software products, development rocess, architecture, dimension and use of the architecture, coop- ration of development, and awareness of change in the software, oftware product line, and software evolution. Our interviews ocused on understanding concrete practices rather than a pol- shed record, as we focused on both the tools used and concrete ccasions. The interview guideline and analysis was done in coop- ration. However, it was first author who did the interviews and the ain work preparing the transcripts and the initial analysis. This

ection is outlined as follows: Section 3.1 presents grounded the- ry; Section 3.2 presents interviews as data collection; and Section .3 shows analytic process.

.1. Grounded theory

Among flexible research strategies, grounded theory claims that t is useful in new, applied areas where there is a lack of theory nd concepts to describe and explain what is going on. Grounded heory approach was derived from a combination of Chicago style nteractionism and Pragmatism (Glaser and Strauss, 1967), in terms f data collection and analysis. Data analysis focuses upon concepts. t is achieved by carrying out three kinds of coding: open coding o find concepts; axial coding to interconnect them; and selective oding to establish core concept(s). The result of this process of data ollection and analysis is a substantive theory relevant to a specific roblem, issue, or group (Robson, 2002, see also Fowler, 2003).

Data collection and analysis is an iterative process; it contin- es until no new concepts and relations are found in the new data.

n this interview study, we compared different interviewed data, edefined analysis, and out to conduct more interviews. Although, ach interview shows evidence from diverse perspectives, the pro- ess still involves converging on construct concepts, sub-concepts, nd relations for structuring the finding.

According to Robson (2002), typical features of grounded the- ry are (i) applicable to wide variety of phenomena; (ii) commonly nterview-based; and (iii) a systematic, but flexible research strat- gy which provides detailed prescriptions for data analysis and heory generation.

The problems in using grounded theory are (i) that it is not ossible to start a research study without some pre-existing theo- etical ideas and assumptions; (ii) there are tensions between the volving and inductive style of a flexible study and the systematic pproach of grounded theory; (iii) it may be difficult in practice to ecide when categories are ‘saturated,’ or when the theory is suffi- iently developed; and (iv) grounded theory has particular types of rescribed categories as components of the theory which may not ppear appropriate for a particular study.

.2. Interviews

For the interviews, we contacted eight software product evelopment organisations in five countries, i.e. Belgium, China, enmark, Germany and Switzerland. All organisations developed

s and Software 83 (2010) 2211–2226 2215

and evolved software products. To open up for possible differen- tiations regarding kind of software and size of the development project, we tried to interview as diverse companies and projects as possible. The software products comprised hydraulic simula- tion software, scientific control systems, virus scanners, social software, identity management systems, search engine, and gov- ernmental contents management systems. Sizes of the interviewed organisations ranged from a three-person organisation, to an inter- national organisation with more than 20,000 employees. The sample included normal industrial product development as well as an open source project lead by a governmental agency, a research institution, and a semi-private research and consultancy company. Interviewees included a managing director, a chief technical officer, a chief architect, a senior consultant, a group leader, and a number of software developers. Most of the interviewees did not want to disclose their name and organisation name, thus, we present them under assumed names. The interviews were partly carried out at the workplace, partly via SkypeTM and partly in neutral spaces. We had to accommodate the interviewees’ constraints. Where possi- ble, we interviewed more than one member of the development team. In one case we interviewed members from several product teams in the same company (see company No. 2).

We prepared an interview guideline with two parts, i.e. a num- ber of open questions, and a series of multiple-choice questions. The free response questions addressed the six categories listed in the introduction of this section. The fixed questions were asked after the open question. The answers thus quantified what had been discussed during the interview.

The interviews were conducted from late 2007 until early 2008. The duration of each interview varied between 30 min and 3 h, depending on the interviewee. The interviews were audio-taped and transcribed. The transcription and analysis of the interviews were checked by the interviewees. Apart from that, we also provided confidentiality agreements for the interviewed organi- sations.

3.3. Analytic process

The analysis process started with reading each transcription in order to get a feeling of what the interviewees were telling. We came back and listened to the voice recordings of the interviews while reading the transcriptions. The first tentative concepts were presented as memos and a springboard of our analysis. These codes were then highlighted in the transcription together with words or terms that supported properties and dimensions of the con- cept. During this work, higher-level categorisations, or lower-level explanatory concepts became visible. With this list of concepts and codes, we proceeded to the next transcription. New concepts appearing in later interviews were added to the coding scheme which required returning to previous interviews. This part of the analysis process continued until we were satisfied that we had accounted for the contents of the interview.

Relations between different concepts became visible. In order to fully understand concepts, we explored the semantic and process context of the concepts in the interviews. For the semantic context, we explored conditions and relationships between the concepts the interviewees expressed in the interviews. For the process con- text, we explored how interviewees responded to concepts through action, interaction, and emotions. That way, we further explored the meaning of the concepts and linked the concepts to one another.

We represented the relationship between major categories and

subcategories as the foundation for the theoretical structure that we iteratively refined by going back to transcripts and memos. Fig. 1 shows such a representation of how the categories referred to each other. Section 5 presents the central concepts, and also indicates how they relate to each other. Section 4 provides the background

2216 H. Unphon, Y. Dittrich / The Journal of Systems and Software 83 (2010) 2211–2226

oncep

o a

3

i f

T S

Fig. 1. Early diagram over analysis c

f the organisations and the results of the closed questions asked t the end of the interview.

.4. Confidence

The strategies we applied to minimise possible threats to valid- ty (Robson, 2002) and to enhance trustworthiness shows as ollows:

Triangulation. The term triangulation, borrowed from navigational science and land surveying, referred to using two or more sources to achieve a comprehensive picture of a fixed point of reference (Padgett, 2008, p. 186). We applied data triangulation in out study. The data was gathered from 13 interviews (given by 15 intervie- wees from eight different product developing organisations). The correspondence with previous and parallel case studies further supports that the account given is corresponding to what actually takes place in practice. Member checking. All interviewees were required to check the tran- scription of their interview before the data was analysed. This article was reviewed by the interviewees before submission. Audit trail. All interviews were audio-taped and transcribed. During data collection and data analysis, drawing artefacts and diagrams on the whiteboard were photographed. Detailed analytic

and self-reflective memos were documented. Saturation of categories. For grounded theory the convergence of the observation and the saturation of categories is important. We continued with the interviews until the concepts, categories and theoretical structure were saturated. For each of the categorisa-

able 1 ummary of sampled companies.

No. Company name Software product industry

1. EW E-government applications 2. ABC Hydraulic simulation

3. OMD Business identity management

4. ARG CRM and telecommunication 5. GDT Computer security 6. CO Visual office solutions 7. XYZ Internet searching and organising universal informati 8. DZ Controlling cryogenic processes for colliders

ts illustrating the analysis process.

tions we found, we have evidence from several interviews. Many of the concepts are based on all interviews. Though looking for companies and development organisation with a more structured architecture practice, our interviewees again and again reported and emphasised the informal architectural practices we develop in our analysis.

Based on these measures we are confident that the analysis cap- tures the software architecture practices as reported and provides a picture of architectural practices in software product evolution.

4. The companies and their architectural practice

Before presenting the results of the grounded theory analysis this section presents the companies and provides an overview over their architectural practices. Section 4.1 presents interviewees and organisation profiles. Section 4.2 outlines dimensions, sophistica- tions, and states of architecture.

4.1. Interviewees and organisation profiles

There are 15 interviewees from eight organisations develop- ing and maintaining their own software products. Table 1 gives an overview over interviewees and companies. Note that the order

of interviewees follows the chronological order of the interviews.

The first company is EW, a Belgian government agency in the Walloon region. The main task of EW is to simplify the lives of citi- zens and enterprises that need to communicate with public entities. EW develops and acquires 20 software products and projects for

Total employees Interviewees

20–22 One senior software engineer 800 Five senior software engineers, and two

offshore junior software engineers 72 One junior software engineer and one senior

consultant 3 One managing director 51–200 One senior software engineer/chief architect 10 One chief technology officer

on 20,000 One software engineer 1001–5000 One group leader and one software engineer

System

e o t u p d E a D T m fi

c c t A p h b i o h r i e I o e a a

p a t i t c r d o t c c i

i c p i o p t s k

q 2 s s y a

f t a

H. Unphon, Y. Dittrich / The Journal of

-government, and on-line public administration. EW has a total f 22 employees, ten of whom are in IT department. EW employs he core contributors for an open source project following a prod- ct line approach that is developed together with a number of IT eople in different municipalities. We interviewed Gaëtan, a senior eveloper educated in computer science who has been working at W for 2 years. He is the main developer of the open source project nd cooperates with a Belgian university to explore Model Driven evelopment (MDD), along with feature modelling techniques. he project started with evolving a product family for advanced eeting management functionality, like meeting workflow speci-

cations and document generation. The second organisation is ABC, an independent research and

onsultancy in the field of water, environment, and health. The ompany has approximately 800 employees, and is based in more han 25 countries worldwide with their headquarters in Denmark. BC develops more than 15 commercial software products sup- orting water resources management, with the main expertise in ydrodynamic simulation. Some of the software products have een evolved for more than 20 years. Of the 35 developers, we

nterviewed five senior developers at their headquarters, and two ffshore developers in China. One of the senior developers is the ead of development and responsible for all products. The rest are esponsible for different products, shown as ABC product #1–5 n Table 2. The five senior developers are educated in hydraulic ngineering, while the two offshore developers are educated in T. One of the interviewed developers is working closely with us n a project that re-engineers a core computational part of three xisting products using a software product line approach. However, rchitectural tools and practices were introduced to the project fter this interview study.

The third organisation is OMD, a Danish founded company that rovides advanced role based access control (RBAC) and tools for ssuring and reporting compliance between legal requirement and he identity management. Established in 1999, OMD has operations n Europe, Africa, Australia and North America, delivering its solu- ion via a network of skilled partners and system integrators. The ompany has 72 employees: two in USA, three in Germany and the est in Denmark. The IT team consists of 18 people, 12 of whom are evelopers. The company offers three standard software products f which only two are maintained. We interviewed two employees, o be hereafter named as Santiago and Neeraj. Santiago is a senior onsultant, specialised in Business Process Management and edu- ated in Economics. Neeraj is a junior software developer educated n IT.

The forth organisation is ARG, a private consultancy company n the field of customer relations management and telecommuni- ations. For the past 2 years, ARG has been developing software roducts on top of call recording systems and CRM systems. We

nterviewed Ole, a managing director and a founder of ARG. ARG’s ffice and development centre is based in Germany. The com- any has three employees educated in computer science: Ole, and wo developers. Ole invented and designed the prototype of the ystems. He’s the only person in the company that has domain nowledge in the field of telecommunication.

The fifth organisation is GDT, a security software company head- uartered in Germany. The company size ranges between 51 and 00 employees, while 10–11 of them are developers. GDT offers ten ecurity software products for home users and businesses. Those oftware products have been in development for more than 18 ears. We interviewed Hans, a senior software engineer and chief

rchitect at GDT. Hans has been working at GDT more than 8 years.

The sixth organisation is CO, a European software publisher ounded in 1999 by Belgian Internet pioneers who specialize in vir- ual office solutions. The organisation is a small company having n approximately ten employees, three of whom are developers.

s and Software 83 (2010) 2211–2226 2217

We interviewed Guillaume, a back-end developer and a chief tech- nology officer (CTO) who has been working with the company for more than 9 years.

The seventh organisation is XYZ, one of the world’s leading inter- net companies that provides searching, organises information, and makes it accessible. XYZ has provided dozens of products since the late nineties. The company has approximate 20,000 employees. Although, XYZ is a large company, the size of the development team is kept between 4 and 6 people. The interaction between teams is the responsibility of architects and product managers. Team mem- bers are changed regularly depending on the need of products and projects. The headquarters is located in the USA, but the company has a software development centre in Switzerland where we inter- viewed Marie, a software engineer educated in computer science. At the time of the interview, she was working on a 2-year-old prod- uct. Because development processes and practices at XYZ are varied from team to team, the XYZ product shown in Table 2 refers only to the product that Marie is working with.

The eighth and last organisation is DZ, based in Germany. It is one of the world’s leading centres for the investigation of the structure of matter. DZ develops, runs, and uses accelerators and detectors for photon science and particle physics. The company ranges between 1001 and 5000 employees who are allocated to various groups. Each group is responsible for its own projects and products. The products are all open source and are often developed together with other companies and institutes worldwide. We inter- viewed two employees, i.e. Jan and Matthias. Matthias is a group leader who had proposed his idea to develop the system which was established as a project before Jan, a software engineer, joined the group. The project was to evolve two products that needed to be used together for the system to control cryogenic processes for the colliders. One of the products had been in use for 20 years, and another had been in development for 1 year. Currently, both prod- ucts are developed by 2–2.5 developers and are assembled in 15–20 applications.

4.2. The presence of software architecture

This study is based on interviewees’ perception on software architecture. We wanted to know about their architectural under- standing and how the software architecture is present in the development practice: “What is your understanding of software architecture?” The answers were given differently. The term soft- ware architecture had been explained using a variety of buzzwords, e.g. a blue-print/skeleton of software, components, design of source code, high-level patterns/abstraction, 4 + 1 views, struc- turing, assembling building blocks, stack of technology, layering, dependencies, plug-ins, design patterns, UML diagrams, overall description of the communication of the software, and overview for the development team. The implications of what interviewees understood about software architecture ranged from source code to human activities.

Table 2 summarises the results with respect to software prod- ucts that interviewees were working with. Product pseudonyms are used to represent the software products as company-based products because of confidential information. The presence of architecture is categorised into Different dimensions of architecture representation and usage; To what detail is the architecture repre- sented?; and How is the architecture expressed?. The cross sign (X) denotes existence of the item with respect to software product names. This is rather coarse information and has to be interpreted

together with the qualitative analysis of Section 5.

The first category, different dimensions of architecture represen- tation and usage, are further categorised into In which form is the architecture presented in the process?; How is the architecture repre- sented?; How the architecture representation is used?; and How can

2 2

1 8

H .U

n p

h o n

,Y .D

ittrich /

Th e

Jo u

rn a l o f

Sy stem

s a n

d So

ftw a re

8 3

(2 0

1 0

) 2 2

1 1

– 2

2 2

6

Table 2 The presence of architecture with respect to software products.

Software products

EW products

ABC product #1

ABC product #2

ABC product #3

ABC product #4

ABC product #5

OMD products

ARG products

GDT products

CO products

XYZ product

DZ products

Different dimensions of architecture representation and usage

In which form is the architecture presented in the process?

In somebody’s head X X X X X X X X Documented in folder, binder, or internet

X X X X X X X

Readily available in workspace

X X X X X

How is the architecture represented?

Text X X X X X X X Source code X X X X X X X X X X X X Boxes and arrows X X X X X X Class, packages, and diagrams

X X X X X X X

Architecture Description Language (ADL)

X

Different views X X X How the architecture representation is used?

Design X X X X X X X X X X Communication between developers

X X X X X X X X X X X

Communication about changes

X X X X X X X X X

Communication when designing new features

X X X X X X X X X X

Communication for bug fixing

X X X X X

As feedback for on-going implementation

X X X X X

Distribution of work and responsibility

X X X X X X X X X X

Generation of diagrams X X X X How is the architecture representation updated?

Never X X X X X X Regularly controlled X X X X X X X X Continuously X X X X Related to an overall plan and release plan

X X

Only when problem occurs X X X X

To what detail is the architecture represented?

Overall X X X X X X X X X X X Classes X X X X X X X X X Styles X X X Patterns X X X X X X X Design patterns X X X X X X Various views X X X

How is the architecture expressed?

Implicitly Source code X X X X X X X X X Explicitly Diagram X X X X X X X X

Textual description X X Requiring substantial knowledge of implementation base/pattern architecture

X X X X X X X X

System

t t h i i p p p c n g g p a i b

s p p A p t c o

t k p u t

p t t t u t a r r a t a e a t e

5

y g t 5 p t u S a a

t p r

H. Unphon, Y. Dittrich / The Journal of

he architecture representation be updated?. For example, the archi- ecture for EW products is presented in the form of in somebody’s ead, and documented in folder, binder, or internet, but is not read-

ly available in the workspace. The architecture for EW products s represented in text, source code, boxes and arrows, class and ackage diagrams, Architecture Description Language (ADL), and rovides different views. The architecture representation for EW roducts is used in design, communication between developers, ommunication about changes, communication when designing ew features, communication for bug fixing, as feedback for on- oing implementation, distribution of work and responsibility, and eneration of diagrams. The architecture representation for EW roducts is updated, regularly controlled, related to an overall plan nd release plan, or only when problem occurs. The many marks n EW’s column indicates an elaborated practice which might have een due to the cooperation with the local university.

The next category is To what detail is the architecture repre- ented? containing five levels: overall, classes, styles, patterns, design atterns, and various views. For example, the architectures of ABC roduct #1–5 are all detailed at overall level. The architecture of BC product #1 is detailed at the levels of overall, classes, styles, atterns, and various views, but not design patterns. The architec- ures of ABC Product #3–4 are detailed at the levels of overall and lasses. The architecture of ABC Product #5 is detailed at the levels f overall, classes, and patterns.

The last category is How is the architecture expressed? that is fur- her categorised into implicitly, explicitly, and requiring substantial nowledge of implementation base/pattern architecture. For exam- le, the architectures for OMD products are explicitly expressed sing diagram and requiring substantial knowledge of implementa- ion base/pattern architecture.

Based on Table 2, the architecture is mostly presented in the rocess as a form in somebody’s head. All our interviewees report hat the architecture is represented in the source code, but architec- ure description languages (ADLs) are hardly ever used to represent he architecture. The architecture representation is commonly sed for design, communication between developers, communica- ion about changes, communication when designing new features, nd distribution of work and responsibility. Updates of architecture epresentation are almost equally distributed between never and egularly controlled. However, the updates rarely relates to over- ll plan and release plan. Most of the interviewees confirmed that he architectures are represented at the overall detail; only a few ddressed styles and various views. The architectures are almost qually expressed implicitly in source code, explicitly in diagram nd almost always requiring substantial knowledge of implementa- ion base/pattern architecture. However, the architectures are rarely xpressed explicitly in textual description.

. Analysis of interviews

This section presents the results of the grounded theory anal- sis of the interviews: Section 5.1 begins the analysis with target roups of architecture and their understanding levels in the archi- ecture; Section 5.2 is documentation for the architecture; Section .3 explains how newcomers learn the architecture of software roducts; Section 5.4 points out the role of architect(s); Sec- ion 5.5 shows communication channels that developers use for pdating information about changes in their software products; ection 5.6 addresses the architecture with respect to evolvability nd changes; and Section 5.7 presents architectural problems as

ddressed by our interviewees.

In the presentation, we use citations from the interviews to illus- rate and support our analysis. These citations keep as much as ossible to the original wording. We minimally edited them to for eadability and Grammar.

s and Software 83 (2010) 2211–2226 2219

5.1. Architecture: who needs it and at what level?

Throughout the software life cycle, development team mem- bers carry on their tasks depending upon their roles. Different team members use architecture in different ways in order to collabo- rate with others. The interviewees distinguished three groups, i.e. newcomers, developers, and chief architects. The newcomers need architecture as a springboard to understand the software that they are going to develop. The developers share and accumulate archi- tectural knowledge, in particular, the part of architecture that they are responsible on a daily basis. The chief architect orchestrates all architectural activities based on their architectural knowledge.

The different roles refer to the architecture on different levels of abstraction. These levels define a protocol on how to discuss and understand the architecture. Marie from XYZ company said: “Usu- ally, we talk to each other verbally [face-to-face], and we can imagine [understand] because we know the code basis. When we do it on the team, we never go to class level. Otherwise, nothing will be done. We define the interface level, i.e. how do we talk to each other.” But not everyone will be able to look from a high-level abstraction point- of-view. Guillaume, the CTO from CO company, told us when he reviewed his colleague’s work, the code worked fine, but it was not easy to understand. The main challenge was that it required a lot of abstraction to interpret. “You don’t have to tell how the code works in the [function name], but what it does. For example, yesterday, he [Guillaume’s colleague] wrote a function ‘setStyle’. What the function does is to change the style. But that is very low-level interpretation. In fact, at the high-level it is to add background to the menu and the exact name would be ‘setBackground’, not ‘setStyle’ . . .” The differ- ence between levels of abstraction became visible again when we asked Jan and Matthias from DZ to draw and explain their archi- tecture. They worked on the same product, but Matthias explained the architecture as the overall picture, while Jan explained what he was responsible for on the daily basis.

5.2. Documentation

Forms of documentation and how it was used was subject to each of the interviews. The code base presented throughout the interviews is regarded as the best and only up-to-date representa- tion of de facto architecture, whereas independent documentation is regarded as problematic because it is outdated quickly.

5.2.1. Code base as actual documentation Source code is seen as ‘the’ actual documentation while the

other kinds of documentation are informally produced to sup- port situated discussion. However, UML diagrams are produced in small scale mostly by need, for example, to get feedback from other developers before implementation of a large component. Direct discussion with developers is more efficient. Many inte- grated development environments (IDEs) support synchronisation between UML and source code, however, the developers feel com- fortable to start with programming. The developers have the impression that understanding and becoming familiar with UML diagrams takes longer than looking into source code.

A common problem is a lack of documentation on the overview of a system, in particular a design rationale, and the description of the main interfaces or functions. A few documents are provided for newcomers to become familiar with architecture. Newcomers feel that comprehending systems from documents only, is hopeless, so they as well prefer to start with programming.

When the source code becomes the actual documentation, the naming of classes, methods, or interfaces is extremely crucial for on-going development. If the name is on the correct level of abstrac- tion, it facilitates the other developers to understand the concept behind the name. The citation above by Guillaume shows that archi-

2 System

t f o

5

d 2 p t d m e

k D b w c w s d t u i

u s a g b w s t c n a u c f

5 t

a e r s a i

5

w r t t a t c o s a r o

220 H. Unphon, Y. Dittrich / The Journal of

ects are well aware of this need and take care to implement it. Apart rom the on-going development, shared distributed development r end-users development also gain this benefit.

.2.2. The absence of a document Our interviewees give several reasons for the absence of explicit

ocumentation. Some software products have been used more than 0 years. When the products were first developed, the main pur- ose of development was to solve domain problems for a short time, hus, there was no effort on architectural documentation. When evelopers started with a small feature, they neglected to docu- ent, so when that feature grew bigger, documentation hardly ever

xisted. Though a document might have been created, the effort of

eeping the document up-to-date leads to maintenance neglect. evelopers have the responsibility to document what they have een programming, but they are aware that their documentation ill soon be out of date. Marie said: “Documentation is like [. . .]

leaning. You have to clean regularly, but it will get dirty again. When e document, we know that the documentation will be out of date

oon.” Maintenance and updating documents is a boring task for evelopers. The architecture document often has a simple nota- ion or diagram using boxes and arrows, so it’s not convenient to pdate the diagram. Therefore, documentation diverges from what

s actually present in the source code. In a complex and specialised domain area, e.g. hydraulic sim-

lation, domain expertise is strongly required for developing a oftware product. Often, a developer is a domain expert rather than software expert because it is a big task for the software expert to et familiar with the domain, so documentation is often neglected y domain experts. This in turn becomes a problem. Our intervie- ees reported that even a developer with domain expertise could

pend up to a year to fully understand and implement a new func- ionality in a software product. The main reasons are not only the omplexity of software products building on top of a stack of tech- ology, but also the unavailability of architecture documents. The rchitecture exists in somebody’s head rather than a written doc- ment. When a developer or an architect doesn’t document the urrent architecture before leaving a company, it causes problems or other developers who follow that architecture.

.3. Architecture knowledge acquisition: how newcomers learn he architecture

A well-attuned team might not have any problems with informal rchitectural practices, so we asked specifically how new develop- rs are introduced to software architecture. All our interviewees eported on their informal knowledge sharing practices. In this ub-section, we show how architectural knowledge is acquired nd developed by team members, discussed with a chief architect, ntermixed with programming, and learning by experience.

.3.1. Discussion with a chief architect Throughout a software’s life cycle, a chief architect discusses

ith developers in order to update the progress of the tasks, and ealise the changes in the architecture. Since tasks are clearly dis- ributed based on architecture, each developer is responsible for his ask, for example, making new features or adding some function- lity. The chief architect’s discussions with developers ensure that hey understand the tasks before they begin implementation. The hief architect often draws boxes and arrows or UML-like diagrams

n a piece of paper, or whiteboard, or makes a Power Point pre- entation of a software prototype and its architecture. If the chief rchitect’s explanation is not precise, bad design decisions could esult. In order to avoid that situation, one of ABC senior devel- pers explained how he transfers architectural knowledge to the

s and Software 83 (2010) 2211–2226

ABC offshore developers: “We go to China and explain this [diagram] to them. Then we show them how things [architecture] are now and explain [. . .] what we want to add to this, [the] new feature to put in. . ..”

The chief architect synchronises architectural knowledge with other developers by discussion, in particular, team members sit- uated at the same physical location. The discussion happens in weekly meetings or daily conversations that take place spon- taneously in communal areas, like kitchens, canteens, or coffee corners. The chief architect has the most up-to-date architectural knowledge, but that knowledge is hardly ever documented. In order to get that knowledge, one has to update from the chief architect. When we asked Neeraj, a junior developer at OMD, about a certain architectural style and patterns currently used for OMD software products, he said: “You have to ask our system architects. I’m not able to answer that.”

5.3.2. Intermixed with programming Training with a chief architect or a senior developer is a

springboard for newcomers to understand architecture. Based on our interviewee’s experience, a common training technique is pair-programming, where two developers program together at a workstation. In the vast majority of cases, the newcomer is assigned to implement a simple task. The chief architect, or the senior developers, sit down with the newcomers and allow them to ask questions. The newcomers get an overview and design rationale of the software product. They develop a ‘feeling’ – as one of out inter- viewees expressed it – of how the software product works, how to implement using provided tools, and how the repository is organ- ised. The newcomers look into packages, files, and source code, and at the same time, begin programming, so they gradually learn how the software is architected. Later on, the newcomers become developers who are responsible for the architecture of his or her sub-systems. This intermix process of architecting and program- ming facilitates both architecture acquisition and work progress. However, the chief architect or the senior developers need to con- tribute his or her time to educate each newcomer.

5.3.3. Learning by doing A software product can be developed on top of a third party

software product. Often, the third party architecture is not fully transparent, nor does it provide sufficient architectural documen- tation to explain how the system is implemented or how it can attach a new functionality. Every time the developers and the chief architect begin developing on top of a new third-party software product, they feel like they are ‘opening Pandora’s box.’ Moreover, changes are hardly controlled. When the third party releases a new version, the only way to understand that new architecture is to look directly in the source code. It is always a time-consuming and painful process.

5.4. The role of a chief architect

The analysis so far points to and underlines the importance of the software architect acting on what we have begun to call a ‘walking architecture.’ Not all companies have a ‘chief architect’. However, all products have a person or group of people acting in that role, even though their title might be different, like chief tech- nology officer (CTO), senior developer, product manager, project leader, or system architect. Chief architects have – explicitly, or due to the recognition of their expertise – the responsibility for

designing and updating the architecture throughout the software life cycle. The chief architect informs and updates the developers regarding architectural changes on a daily or weekly basis. In their formal and informal meetings, the developers also update the chief architects about architectural issues in the parts of the program for

System

w d s t o t ‘ s i k c

e c a i

5 d

t w t p a c i u s m n b n s

r r t m m

t a t a

5

n p t l t d p

c i s w l b h t m

H. Unphon, Y. Dittrich / The Journal of

hich they are responsible. The chief architect sometimes creates ocuments containing a few diagrams to give a good view of the oftware, however, most developers still prefer talking directly to he chief architect. The developers usually ask about relevant parts f the software that are changing, and even publicly-kept architec- ural documents. Still, the most updated version of architecture is stored’ in the head of the chief architect. This is also the under- tanding of the chief architects themselves, as it becomes apparent n a question put to Hans, the chief architect from GDT, on how he nows about the current or de facto architecture. “I’ve worked in the ompany for eight years. Most of architectures are my architectures.”

As our interviewees emphasize, a good chief architect has both xpertise in software engineering, and the domain. This sub-section ategorises three main roles of the chief architect, i.e. controlling nd communicating architecture within a development team, and nterfacing to outward.

.4.1. Controlling and communicating architecture within a evelopment team

A chief architect is responsible for most design decisions. In ini- ial design discussions, the chief architect sometimes brainstorms ith domain and software experts before designing the architec-

ure. This discussion covers data type, quality attributes, design atterns, and platforms for the architecture. Most of the design rchitectures have clear interfaces and low dependency between omponents. The design architecture is often used for distribut- ng development tasks and defining social protocols that aim at sing the architecture as a coordination mechanism. Examples for uch protocols are: when changing an interface the programmer ust contact the relevant developer; the chief architect synchro-

ises the tasks by collecting, reviewing and accepting everything efore checking changes and documenting requirements for the ext release; and the chief architect schedules meetings or work- hops with developers when the architecture needs to be updated.

During the implementation, some types of problems cannot be esolved by tools automatically, e.g. naming of a function at the ight level of abstraction. Thus, code review is often part of the asks of chief architects. When they find a problem in the imple-

entation, the chief architects will talk directly to developers and otivate them to resolve the problem. Chief architects often train newcomers by assigning simple

asks, e.g. implementing a new component. They know where to dd these new components or functionalities without endangering he architecture. When they have sufficient knowledge, the chief rchitect will assign developers to work on critical parts.

.4.2. Updating the ‘walking architecture’ Maybe because we did not ask explicitly, the interviewees did

ot always emphasise the above understanding of the mentioned ractices, in that they may also serve the purpose of updating he chief architect’s knowledge of architectural issues that might ead to reconsidering the architecture itself. This became visible in wo ways within our interview material; the communication with evelopers was talked about as a two-way communication, and the roblems that arose when the feedback channel did not exist.

Marie from XYZ answered the question of how their team dis- ussed architectural issues: “When it becomes larger, especially [if] t affects a whole sub-team, or the other part/team, or [we need a] anity check, we set up [a] meeting or talk informally with the people ho care about the affect and need to know.” Or as one of the project

eaders at ABC said: “Generally, it’s [a] very informal way, [talking] etween colleagues that know about this thing.” On the question of ow developers get to know about relevant changes in the archi- ecture, another of the ABC architects answered: “Hopefully the one aking the changes tell other people.”

s and Software 83 (2010) 2211–2226 2221

These informal update becomes problematic when the develop- ment becomes distributed. One of ABC senior developers reported: “Sometimes they do not. [. . .] Normally, when developers were in Prague, most things [were] developed there, [so] they knew what [was] going on and we [had] weekly meeting with them, talking about dif- ferent things, and what different people [had] been doing. [. . .] Now, it’s not the same [as] what we do in China. So, it’s more difficult, now. Developers do not know anymore what changes in the application. [. . .] It’s difficult.” One of our interviewees reported: “Sometimes we have people implementing core components that destroy other compo- nent. Not so much within the engine group, because we have only two people. But the other, especially Singapore or Shanghai groups that did some core components change, because there [was] no documentation up there. They didn’t know that the components [failed] because they [relied] on special functionality.”

Some of our interviewees reported about explicit measures to stay up-to-date with the architecturally relevant changes to the software product. A protocol might have been established that developers must inform the chief architect before changing central parts, core components, or data structures.

The integrated development environment can indicate archi- tecture violations if set up in the right way. Also, nightly builds can indicate when new code breaks an interface. In some companies, the chief architect reviews changes to the code and based on the reviews, discusses changes with the developers.

Guillaume from CO, keeps up-to-date with changes in the com- mon parts of the software through regularly reading the source code and common Wiki. “In the Wiki, every change in the software is documented, not with a lot of detail. . . . In the trunk [of the CVS], we document every commit. . . . I take care of [reading] source code, Wiki and the commit.”

5.4.3. Interfacing to outward Chief architects reported that they need to interface with peo-

ple working outside of the development team, e.g. people gathering requirements and working with other related products, clients, or end-users. In order to utilise the design architecture, chief archi- tects have to ensure that agreement with people working outside the development team have been made. In a conflict situation, chief architects need to negotiate and compromise with those outside sources.

Chief architects are aware that feedback from outside profes- sionalises the development. They often discuss expectations of implementation with their clients before conversations with devel- opers. They go back and collect feedback from the clients or the end-users before the next release. If chief architects have no direct contact with clients or end-users, they have discussions with sales and marketing people. The feedback from the clients or marketing people will help the chief architects get a correct understanding of the requirements. Based on this understanding, they prioritise and delegate the requirements for the next release.

Due to business or organisational reasons, related software products might be developed in different units. In some cases, more than one team together develops a software product. In such situations, chief architects needs to coordinate with other devel- opment teams in the same company or from contract companies. In software product lines, changes in one product may cause mal- functions in other products. Thus, chief architects must take heed of the changes. If problems occur, it is their task to find solutions. The solutions vary from collaboration to architecting. Examples are as follows: the chief architect communicates with another devel-

opment team on the changes overall effect; the chief architect develops interfaces (e.g., API) to express a common concept of another product; or the chief architect designs the architecture in a way that accommodates the interest of both teams. Guillaume, a chief technology officer at CO, told us how he handled recent

2 System

c a m m I o

5

s d p c o

f m b J a g fi m c

5

g a i a m d

5

i o d

b o t f

5 r

r t s i t

5

i t a k t a f

w

222 H. Unphon, Y. Dittrich / The Journal of

hanges: “Last week, XYZ company published an API to access the ddress book [of XYZ product]. There [was] a request to implement a echanism to import the address book from XYZ to CO. XYZ imple- ented most of APIs under a common umbrella [XYZ product]. I think have to take care; I develop[ed an] interface in [a] generic way in rder to express the concept of [XYZ product].”

.5. Communication about changes

Team members need to be updated about changes. In this sub- ection, we categorise communication from the current software evelopment practice that covers both human interaction and sup- ort tools. Each practice presented below is ranked from the most ommonly used to rarely used. Note that each interviewee reports n more than one practice.

Verbal communication or face-to-face communication (i.e., free- orm dialogue, explanation, and discussion) with colleagues is the

ost common practice. It is used by all interviewees and seems to e the simplest way to update them about architectural changes. ust another quote from our interviews complementing the many bove: “We don’t have state diagrams and seldom use sequence dia- rams. But we need knowledge about what [method is] to be called rst or second. That’s not explicitly stated. It is just something that we ake use of by asking people that know about this typical sequence of

alling.”

.5.1. Meeting A development team must meet regularly where each developer

oes through all the tasks and updates what the other colleagues re doing, so the team members can synchronise their understand- ng of the architecture. In some distributed development projects,

whole development team assembles for a longer ‘coding camp’ eeting at the same location in order to brainstorm about new

esigns, or to finalise a new release.

.5.2. Nightly builds and testing Nightly build mechanisms notify developers the next morning

f the changes checked in the day before had affected other parts f the software, for instance, breaking interfaces or violating the esign rules.

Email, mailing list, and instant messaging are used spontaneously y team members to send messages (e.g., “By the way, you broke ur code!”), or inform the other members within a team, or between eams, about changes. Sometimes, messages are automatically sent rom an IDE or a support tool.

.5.3. Concurrent versions system (CVS) and subversion epository

In some cases, everyone in a team has their own branch on epository to work on as a sand-box. Later, they carefully merge all he changes in a common branch or a trunk in order to rebuild the oftware. When a developer commits changes in the source code nto the trunk, the CVS repository automatically sends an email to he other developers.

.5.4. Rich IDE Some IDE provides multi-disciplined team members with an

ntegrated set of tools for architecture, design, development and esting of applications. The IDE can report problems in architecture nd do quality assurance. Ole from ARG told us how his developers new the relevant parts of the software were changing: “[IDE name]

ell us which part of the architecture has problems. . . . [IDE name] is golden gun. It is a very complicated environment . . . It can do much

or software engineering.” The main advantage of the integration is to handle the changes

ithin a monolithic tool. Guillaume from CO supported this with:

s and Software 83 (2010) 2211–2226

“I can modify code and the code is still consistent for all applications . . . It is quite easy to handle.”

5.5.5. Code review Changes in the source code are sometimes reviewed by chief

architects before one can commit to repository. They correct mis- takes in the source code and improve the quality of software while doing code review, then often discuss the changes and rationale with developers.

5.5.6. Wiki Every change in the software can be documented in a Wiki.

Though the documentation is not fully detailed, everybody is aware of the changes and can use the Wiki to inform about the ones he introduced (see also Section 5.4.2). Only few interviewees report the use Wikis to update or inform team members about changes to the source code or the architecture. However Wikis are some- times used for collecting ideas and requirements from users and developers.

5.6. Evolution and changes

When the original architecture had first been established, peo- ple had no intention of ever changing it. However, changes initiated by use and business contexts of software products resulted in new requirements which in turn affected the architecture. Typical examples include: a user request for some functionality that could benefit other users; an intuition from a developer who might even use the software himself triggers changes; and marketing strategy or competition. From all organisations, our interviewees confirmed that chief architects have to be involved in or responsible for all changes, in particular, architectural changes. Chief architects need to satisfy the change requests and existing architecture in order to reduce the effect on the architecture. They might decide to add new components or functionalities. If re-design of the whole architec- ture is the only solution, they could suggest creating a new software product.

Regarding changes implied in the development, protocols might be put in place to support information and knowledge sharing. For instance, developers are not allowed to change a common part, core component, or data structure without informing the chief archi- tect; the developers should synchronise their changes with their colleague; or developments have to be done based on the latest version.

Although chief architects are initially responsible for establish- ing architecture and taking care of changes, it is difficult to keep track when architecture evolves over long periods of time. Changes in source code affect the other parts of a software product, for exam- ple, changing a common part causes a software malfunction. One of ABC senior developers complained: “On the entire ABC product line, if you change something on the core components, you may destroy 95% of the component here. . .. It’s difficult to know exactly what com- ponent you are touching by changing the code.” Furthermore, the changes sometimes have effect beyond a company’s boundary. Ole, a managing director at ARG, told us about customising a third party product: “When they [the third party product developing companies] make changes on the architecture, we know it by the malfunction on our software, not by documentation.”

5.7. The problems of the practitioners

Our interviewees also talked about problems in their archi- tectural practice. We add them here for two reasons: (a) they triangulate and confirm the analysis so far and thus provide additional support for our analysis; and (b) the section gives an

System

i o a p t u c

d d l t p

t fi s o n c [ o w [ o t B t c

i o L c t b “ i c l

g w h w

s e o o

w a d p d n a k

e t t a c p

H. Unphon, Y. Dittrich / The Journal of

ndication of what are the problems from the practitioners’ point- f-view. The problems address technical infrastructure as well s co-operational aspects of software development. The common roblems in the technical context are changes in technical infras- ructure, framework, or standard that a software product builds pon, e.g. changing virus scanners to support Unicode base, or hanging global unify identification mechanisms for CRM systems.

With respect to co-operational aspects, some software esign/developmental approaches are likely to obstruct day-to-day evelopment practices and hinder collaboration. Furthermore, a

ack of awareness, a lack of domain or software engineering exper- ise, or the loss of architecture knowledge often causes architectural roblems.

Gaëtan, a senior developer at EW, reported from his daily prac- ice: “we have a problem with the model; it is a binary file, not text le. So it means that if I want to change a part of the model, and, at the ame time, the other developer wants to modify another part. It is just ne file. So one of the two guys can make modification, the other can- ot touch anything. Once one finishe[s] and commit[s] the file, another an check-in. It is not easy to modify the design with more than one person] at a time. For source code is different; the code is in plenty f files. People can work on separate sets of the files. When people ork on the same file, we can ‘make diff’ between elements and see

the code] that a guy works on this part [. . .] and merge [the] changes, r the changes can be merged automatically because it doesn’t touch he same part. It is easier to work [in a] collaborative way with code. ut with this [the model] is not possible.” It is reasonable to claim hat, apart from being ‘the’ actual document, code basis supports ollaborative development better than the model.

Although many existing tools and practices are used for inform- ng changes and controlling evolution (e.g., nightly builds, unit test, r regression test), these tools do not resolve all the problems. acking information about changes as reported in Section 5.4.2 is ommon, especially in distributed software. Although documenta- ion problems are addressed here, creating a document might not e the best, or the only solution. Hans, a chief architect at GDT, said: If it [the document] would be a good view on the software, I will do t. . . .We don’t need overview for every class.” Therefore, giving and ontrolling information about changes should be done at the right evel.

One of ABC senior developers stated: “This kind of dependency raph would tell them we have to tell someone about something, that e [need to] make changes. It helps people be aware that if they change ere [a component it] may affect [something] elsewhere. Otherwise, it ill be difficult to see by [yourself].”

Finding the right people and keeping them is a challenge in many oftware developing companies. “One year ago, unfortunately, our xcellent developer left our company. It is very hard to find [new] devel- pers. We are looking everywhere,” Guillaume, a chief technology fficer at CO complained.

Developing software products need both domain and soft- are engineering expertise, but they rarely come together. Ole, managing director of ARG, addressed his biggest concern: “our

evelopers do not know anything about telecommunication via tele- hone, although they use it. . . . On the other hand, [third party product] evelopers understand very well about telecommunication and tech- iques of voice over IP, or something like that, but they don’t know nything about software factories, processes or design patterns. They now nothing about the architecture and development cycle.”

If newcomers or developers have only software engineering xpertise, they will need time to acquire sufficient domain exper-

ise. If the developers have only domain expertise, they will need ime to get software engineering expertise. When developers cquired both, their expertise becomes an important asset for ompanies. However, companies cannot always hold onto their ersonnel. Losing a central developer or chief architect can result

s and Software 83 (2010) 2211–2226 2223

in the failure of a software product. One of ABC senior developers said: “the software products are going to the dying phase or dead-code when the key programmer left. . . . We don’t know how to write them.”

6. Discussion

This empirical study focuses on the development of software products. Software products constantly evolve. Changes in the soft- ware product must be handled consciously in order to prevent dead-end development. Through our interviews it became clear that the main issue when developing software products is not to implement the design architecture in order to assure certain given qualities, but to maintain the architecture in a viable state when evolving the software. The software needs to support future requirements and innovations. The architecture – both the source code architecture and, if it exists, the current design architecture – are means towards that end. In the discussion now, we high- light the aspects that we consider relevant for developing support for architectural practices for software product development. The importance of the ‘walking architecture’, ‘good reasons for bad doc- umentation’ indicate the need to develop social protocols fitting with local practices when introducing architecture representations and documentation, and we finally propose a means to promote architecture awareness.

6.1. Architecture awareness is achieved through ‘walking architecture’ practices

The analysis indicates that product development teams depend on chief architects or group of architects who act as what we started to refer to as the ‘walking architecture’ for communicating the architecture to the developers, and in turn communicate problems which might become architectural issues to the software architect. The walking architecture takes most, if not all, design decisions and solves architectural problems throughout on-going develop- ment. Architectural issues arise from inside as well as outside the development team, cover technical and social aspects of software development, and require domain, as well as software engineer- ing expertise. In order to solve these issues, the chief architect interacts with technical and business people, establishes tools and practices, and recruits or trains team members for that expertise, etc. Because architecturing is not just only a matter of technical design, but also of juggling the social contexts of software devel- opment that make it almost unable to automate (Unphon et al., 2009a).

Our analysis both confirms the importance of inward and out- ward interaction as part of the role of the software architect (Kruchten, 1999), and deepens the understanding of the impor- tance of this interaction. In the interviews, the rational behind these practices becomes visible. On the one hand, developers need up-to- date knowledge about the architecture, here and now. The architect can explain the structure of the software in relationship to the problem at hand. On the other hand, the chief architect may stay in contact with the development of the source code and become aware of potential issues. The emphasis on face-to-face commu- nications provides a strong indication that whatever methods and tools software engineering research proposes needs to be aligned with the practices of knowledge sharing by, and with, the walking architecture.

6.2. Good reasons for bad documentation

A lack of up-to-date architecture documentation is problem- atic according to our interviewees, and software architecture researchers often refer to the threat of loosing architectural

2 System

k n ‘

w a w a t a l r s t w y p w c t t fi t t i w s m

d a t a d a a

c a a p t t

r m P d m i

6

w i i c t o i o c i

s

224 H. Unphon, Y. Dittrich / The Journal of

nowledge by using the architect. If the lack of documentation phe- omenon is so widespread, one might suspect ‘good reasons’ for

bad documentation’ (see also Heath and Luff (1996).) As presented in Section 2, architecture research emphasises

ritten representation (e.g., formal notations or documentation) nd codified knowledge. Written representation describing soft- are architecture might suit a researcher’s practice rather than chief architect’s practice. Based on our empirical evidence,

he architecture almost always exists as knowledge of people pplied and communicated answering situated questions and prob- ems. Documentation – if it exists – tend to play a secondary ole. Architecture knowledge management can be described as ocialisation-heavy. Face-to-face communication is the-state-of- he-practice of architectural knowledge management. For example, e often overhear a team member say to his/her colleague: “I know

ou worked on this component, please tell me about it,” or “The best erson to ask is the architect.” Team members are used to conversing ith a chief architect about their work. Through these discussions,

hief architects not only educate and inform developers, but also ake heed of changes that may cause problems to the architec- ure later on. They converse with the team members in order to nd a solution for architectural problem. Given these practices, he absence of documents is not a risk for software companies. On he contrary, if documentation was successfully established even n parts instead of the aforementioned practice, the chief architect

ould lose track of what is going on in the architecture. As a con- equence, nobody could maintain the architecture anymore, which ay in turn result in serious problems. This confirms Naur’s observation that the communication of

esign knowledge needs to take place in a situated manner. Our nalysis also implies that research needs to look for other ways o address the threat of loosing the ‘walking architecture’. Maybe conscious sharing of the architect role among a group of senior evelopers might both improve the quality of the architecture and llow for the survival of the product when the original ‘walking rchitecture’ is no longer available.

If a shared form of documentation is established, social proto- ols need to be established, as well, to make sure that the walking rchitecture learns about developments in the code and potential rchitectural issues. One example of such a social protocol is the ractice of regularly reading the common wiki-based documenta- ion, the checked in source code, and the CVS information in order o keep up-to-date with the changes to the code.

Our observations and the challenges they imply for architecture esearch and method, however, refer to software product develop- ent and evolution. Software products are evolved continuously.

ractices for contract development (Mitchell et al., 2002) or the evelopment of high-integrity systems (Hinchey and Bowen, 1999) ight differ and the conclusions might need to be adjusted accord-

ngly.

.3. How to promote architecture awareness

Practitioners and researchers agree on the importance of soft- are architecture being part of everyday software development

n order to enhance quality attributes (Naik and Tripathy, 2008), n particular evolvability (Unphon et al., 2009b). Many software ompanies have successfully evolved their products even though hey hardly ever emphasise explicit architectural documentation, r keep architecture documents up-to-date. However, source code s a reification of design. Developers and architects are well aware

f the architectural structures: software developers know when to hange the source code, where to change it, who to ask, who to nform, etc. Architecture is alive with a walking architecture.

Tools and methods for promoting architecture awareness hould support this practice, rather than establishing a diverg-

s and Software 83 (2010) 2211–2226

ing approach. Two promising examples of how to do this are as follow:

One of our interviewees reports on his projects sharing and cooperatively maintaining the architecture knowledge in the form of a common wiki (see section 5.4.2). Documentation in a Wiki, albeit not very detailed, can communicate changes to team mem- bers, and as well to the chief architect. The documentation in Wiki becomes one way of communicating about changes continuously that does not hinder, but supports the chief architect. The chief architect can then read through the changes and be aware of any- thing that might affect the architecture.

A similar tool is proposed by Solís and Ali (2008). Personal communication (Muhammad Ali Babar) on the usage of this tool indicates that a social protocol similar to the one reported above, evolved around its usage.

As part of the research with a product developing company, Unphon (2009) presented the introduction of a ‘build hierarchy’ matching the static architecture as a technique to give develop- ers continuous feedback about whether their code complied with the design architecture. This architecture-based built hierarchy can be implemented as part of the integrated development envi- ronment (IDE), or the nightly build infrastructure. That way, the build hierarchy supports on-going architecting through architec- tural compliance checking between design architecture and code architecture. If implemented as part of the IDE, developers can be informed with every compile command whether their changes affect the other parts of the software or break the architecture. If changes in the source code break the design architecture, the developers need to revise the changes or discuss it with the chief architects and their colleagues. Through the discussion, the chief architects are updated about development problems that might become architectural issues.

7. Conclusions

This article began with postulating the question, what architec- ture practices do software product developing companies apply to keep their products alive, sometimes over several decades. Besides providing a rich picture of industrial architecturing practices, we would like to highlight three major results:

The first is the concept of the ‘walking architecture’ and his or her practices of knowledge sharing and architecturing. Our study shows that architecture practices emphasise face-to-face commu- nication rather than the codification in documents. The analysis emphasises the importance of a chief architect acting as a walk- ing architecture who is responsible for maintaining and evolving the software products’ architecture. Through face-to-face commu- nication with developers, as part of the everyday development, the chief architect communicates the software architecture in a form most suited to help the developers with problems at hand, and at the same time, becomes aware of potential architectural problems.

The second result is a more differentiated perspective of the effect of documentation. Other research has promoted documen- tation as a recommended practice for development teams. Based on our analysis, we hesitate to join this chorus. Our interviewees emphasise that documents quickly become outdated if not con- tinuously maintained. Moreover, the documentation could disrupt the practice of the walking architecture: if reading the document replaced discussions, the chief architect would not be informed about potential problems in a timely manner. As there thus might exist ‘good reasons’ for ‘bad documentation’ it does not help to

re-iterate the praise of extended documentation. Rather, the intro- duction of externalisations needs to be carefully devised not to disturb the knowledge exchange in a way that does not jeopar- dise the ability of the ‘walking architecture to guide the evolution of the software product.

System

t a a a d d p o a r t f

h t e t o u

A

W f r

R

A

A

B

B

B

B

B

B

B

C

D

d

d

D

D

D

H. Unphon, Y. Dittrich / The Journal of

The third result we want to highlight complements the reflec- ions on the role of documentation: applying the notions of wareness and social protocols as a base for sharing information bout a cooperatively achieved task allowed us to take another pproach to tools and methods supporting software architecture. If ocument and tools are devised, they need to be fitted into every- ay developmental practices, and require a change in the social rotocol around architecting. As examples, we discussed the usage f a common Wiki from our field material, and using the build hier- rchy as a reification of the design architecture based on related esearch. With this result, the article confirms the importance of aking cooperative aspects into account when devising solutions or seemingly technical problems.

Given the research above, the reader might become curious on ow exactly does the in situ communication take place, and how are he social protocols without or around architecture documentation nacted and maintained. The answer to these questions we need o leave to future research, e.g. an observational study focussing n the day-to-day architecturing in the context of software prod- cts.

cknowledgements

We kindly thank all interviewees for participating in this study. e should like to extend our gratitude to Dr. Wolf-Gideon Bleek

or his inspiration and help in setting up this study. The journal eviewers contributed to substantial improvements!

eferences

llen, R., Garlan, D., 1997. A formal basis for architectural connection. ACM Trans. Softw. Eng. Methodol. 6 (3), 213–249.

llen, R.B., Garlan, D., 1992. A formal approach to software architecture. In: Pro- ceedings of the IFIP 12th World Computer Congress on Algorithms, Software, Architecture – Information Processing’92, vol. 1. North-Holland Publishing Co., Amsterdam, The Netherlands, pp. 134–141.

ass, L.C.P.K.R., Klein, M., 2008. Models for evaluating and improving architecture competence. Technical report CMU/SEI-2008-TR-006. Software Engineering Institute.

ass, L., Clements, P., Kazman, R., 2003. Software Architecture in Practice, 2nd ed. Addison-Wesley.

elady, L., Lehman, M., 1976. A model of large program development. IBM Systems Journal 15 (1), 225–252.

ischofberger, W., Kühl, J., Löffler, S., 2004. Sotograph – a pragmatic approach to source code architecture conformance checking. In: Software Architec- ture. Vol. LNCS 3047/2004. 1st European Workshop on Software Architecture (EWSA2004), Springer, Berlin/Heidelberg, pp. 1–9.

ooch, G., Rumbaugh, J., Jacobson, I., 1998. The Unified Modeling Language User Guide. Addison-Wesley Professional.

redemeyer, D., 2010. The Role of the Architect in Software and Systems Development, Last visited 15 April, 2010 http://www.bredemeyer.com/ Architect/RoleOfTheArchitect.htm.

rooks, F., Iverson, K., 1969. Automatic Data Processing (System 360 Edition). John Wiley.

zarnecki, K., Eisenecker, U., Czarnecki, K., 2000. Generative Programming: Methods, Tools, and Applications. Addison-Wesley Professional.

amian, D., Izquierdo, L., Singer, J., Kwan, I., 2007. Awareness in the wild: why com- munication breakdowns occur. In: Proceedings of the international Conference on Global Software Engineering, ICGSE, IEEE Computer Society, Washington, DC, August 27–30, pp. 81–90.

e Souza, C., Froehlich, J., Dourish, P., 2005. Seeking the source: software source code as a social and technical artifact. In: GROUP’05: Proceedings of the 2005 International ACM SIGGROUP Conference on Supporting Group Work. ACM, New York, NY, USA, pp. 197–206.

e Souza, C.R.B., Redmiles, D., Cheng, L.-T., Millen, D., Patterson, J., 2004. Some- times you need to see through walls: a field study of application programming interfaces. In: CSCW’04: Proceedings of the 2004 ACM Conference on Computer Supported Cooperative Work. ACM, New York, NY, USA, pp. 63–71.

ingsøyr, T., Conradi, R., 2002. A survey of case studies of the use of knowledge man- agement in software engineering. International Journal of Software Engineering and Knowledge Engineering 2 (1), 391–414.

ourish, P., Bellotti, V., 1992. Awareness and coordination in shared workspaces. In: CSCW’92: Proceedings of the 1992 ACM Conference on Computer-Supported Cooperative Work. ACM, New York, NY, USA, pp. 107–114.

unsire, K., O’Neill, T., Denford, M., Leaney, J., 2005. The ABACUS architectural approach to computer-based system and enterprise evolution. In: ECBS’05: Proceedings of the 12th IEEE International Conference and Workshops on Engi-

s and Software 83 (2010) 2211–2226 2225

neering of Computer-Based Systems, IEEE Computer Society, Washington, DC, USA, pp. 62–69.

Eriksson, J., 2008. Supporting the cooperative design process of end-user tailoring. Ph.D. thesis. Department of Interaction and System Design, School of Engineer- ing, Blekinge Institute of Technology, Sweden.

Farenhorst, R., de Boer, R.C., 2009. Architectural knowledge management: Sup- porting architects and auditors. Ph.D. thesis. VU University Amsterdam, ISBN: 978-90-8659r-r346-0.

Feiler, P.H., Lewis, B.A., Vestal, S., 2006. The SAE Architecture Analysis & Design Language (AADL) a standard for engineering performance critical systems. In: Proceedings of the IEEE Computer Aided Control System Design IEEE Interna- tional Conference on Control Applications IEEE International Symposium on Intelligent Control, 4–6 October, pp. 1206–1211.

Fowler, M., 1999. Refactoring: Improving the Design of Existing Code. Addison- Wesley.

Fowler, M., 2003. Who needs an architect? IEEE Software 20 (5), 11–13. Garlan, D., Monroe, R., Wile, D., 1997. Acme: an architecture description interchange

language. In: CASCON’97: Proceedings of the 1997 Conference of the Centre for Advanced Studies on Collaborative Research. IBM Press, p. 7.

Garlan, D., Shaw, M., 1994. An introduction to software architecture. Technical report, Pittsburgh, PA, USA, http://portal.acm.org/citation.cfm?id=865128.

Gasparis, E., Nicholson, J., Eden, A.H., 2008. LePUS3: an object-oriented design description language. In: Diagrams’08: Proceedings of the 5th International Con- ference on Diagrammatic Representation and Inference. Springer-Verlag, Berlin, Heidelberg, pp. 364–367.

Gerson, E.M., Star, S.L., 1986. Analyzing due process in the workplace. ACM Trans. Inf. Syst. 4 (3), 257–270.

Glaser, B.G., Strauss, A., 1967. The Discovery of Grounded Theory: Strategies for Qualitative Research. Aldine, Chicago.

Greenfield, J., Short, K., Cook, S., Kent, S., August 2004. Software Factories: Assem- bling Applications with Patterns, Models, Frameworks, and Tools. Wiley.

Grinter, R.E., 1999. Systems architecture: product designing and social engineering. SIGSOFT Softw. Eng. Notes 24 (2), 11–18.

Grinter, R.E., 2003. Recomposition: coordinating a web of software dependencies. Comput. Supported Coop. Work 12 (3), 297–327.

Gutwin, C., Greenberg, S., 2002. A descriptive framework of workspace awareness for real-time groupware. Comput. Supported Coop. Work 11 (November (3)), 411–446.

Hansen, M.T., Nohria, N., Tierney, T., 1999. What’s your strategy for managing knowl- edge? Harv. Bus. Rev. 77 (2), pp. 106–16, 187.

Hansson, C., Dittrich, Y., Gustafsson, B., Zarnak, S., 2006. How agile are industrial software development practices? J. Syst. Softw. 79 (9), 1295–1311.

Harrison, N.B., Avgeriou, P., Zdun, U., 2007. Using patterns to capture architectural decisions. IEEE Softw. 24 (4), 38–45.

Heath, C., Luff, P., 1992. Collaboration and control: crisis management and multime- dia technology in London underground line control rooms. Computer Supported Cooperative Work (CSCW) 1 (March (1–2)), 69–94.

Heath, C., Luff, P., 1996. Documents and professional practice: “bad” organisational reasons for “good” clinical records. In: CSCW’96: Proceedings of the 1996 ACM Conference on Computer Supported Cooperative Work. ACM, New York, NY, USA, pp. 354–363.

Hinchey, M.G., Bowen, J.P., 1999. High-Integrity System Specification and Design. Springer-Verlag, New York, Inc., Secaucus, NJ, USA.

Hofmeister, C., Nord, R., Soni, D., 2000. Applied software Architecture. Addison- Wesley Longman Publishing Co., Inc., Boston, MA, USA.

IEEE 1471-2000, September, 2000. IEEE Recommended Practice for Architectural Description of Software-Intensive Systems.

Jansen, A., Bosch, J., 2005. Software architecture as a set of architectural design decisions. In: WICSA’05: Proceedings of the 5th Working IEEE/IFIP Conference on Software Architecture. IEEE Computer Society, Washington, DC, USA, pp. 109–120.

Kruchten, P., 1995. The 4 + 1 View Model of Architecture. IEEE Softw. 12 (6), 42–50.

Kruchten, P., February 1999. The architects—the software architecture team. In: Donohoe, P. (Ed.), Software Architecture: TC2 First Working IFIP Conference on Software Architecture (WICSA1). Kluwer Academic, San Antonio, TX, USA, pp. 565–583.

Kruchten, P., 2008. Controversy corner: what do software architects really do? J. Syst. Softw. 81 (12), 2413–2416.

Kruchten, P., Lago, P., van Vliet, H., 2006. Building up and Reasoning about Architec- tural Knowledge, pp. 43–58 http://dx.doi.org/10.1007/11921998 8.

Lago, P., Avgeriou, P., Capilla, R., Kruchten, P., 2008. Wishes and boundaries for a soft- ware architecture knowledge community. In: Software Architecture, Working IEEE/IFIP Conference, pp. 271–274.

Lehman, M., 1980. On understanding law, evolution, and conservation in the large- program life cycle. J. Syst. Softw. 1 (3), 213–231.

Lehman, M.M., 1996. Laws of software evolution revisited. In: EWSPT’96: Proceed- ings of the 5th European Workshop on Software Process Technology, Springer- Verlag, London, UK, pp. 108–124, http://www.doc.ic.ac.uk/∼mml/feast2/ papers/pdf/556.pdf.

Lientz, B.P., Swanson, E.B., 1980. Software Maintenance Management. Addison- Wesley Longman Publishing Co., Inc., Boston, MA, USA.

Lientz, B.P., Swanson, E.B., 1981. Problems in application software maintenance. Commun. ACM 24 (11), 763–769.

Luckham, D.C., 1996. Rapide: a language and toolset for simulation of distributed systems by partial orderings of events. Technical report, Stanford, CA, USA.

2 System

L

M

M

M

M

N

N

N

N

P

P

P

P

P

P

R

S

S

S

S

S

S

226 H. Unphon, Y. Dittrich / The Journal of

uckham, D.C., Vera, J., 1995. An event-based architecture definition language. IEEE Trans. Softw. Eng. 21 (9), 717–734.

adhavji, N.H., Fernandez-Ramil, J., Perry, D., 2006. Software Evolution and Feed- back: Theory and Practice. John Wiley & Sons.

edvidovic, N., Rosenblum, D.S., Taylor, R.N., 1999. A language and environment for architecture-based software development and evolution. In: ICSE’99: Proceed- ings of the 21st International Conference on Software Engineering. ACM, New York, NY, USA, pp. 44–53.

itchell, R., McKim, J., Meyer, B., 2002. Design By Contract, By Example. Addison Wesley Longman Publishing Co., Inc., Redwood City, CA, USA.

urphy, G.C., Notkin, D., Sullivan, K., 1995. Software reflexion models: bridging the gap between source and high-level models. In: SIGSOFT’95: Proceedings of the 3rd ACM SIGSOFT Symposium on Foundations of Software Engineering. ACM, New York, NY, USA, pp. 18–28.

aik, K., Tripathy, P., 2008. Software Testing and Quality Assurance: Theory and Practice. John Wiley & Sons, Inc.

aur, P., 1985. Programming as Theory Building. Microprocess. Microprog. 15, 253–261.

onaka, I., 1994. A dynamic theory of organizational knowledge creation. Org. Sci. 5 (February (1)), 14–37.

onaka, I., 1998. The knowledge-creating company. In: Harvard Business Review on Knowledge Management. Harvard Business School Publishing, Boston.

adgett, D.K., 2008. Qualitative Methods in Social Work Research, 2nd ed. SAGE Publications.

arnas, D., 1971. Information distribution aspects of design methodology. In: Pro- ceedings of the 1971 IFIP Congress, North Holland.

arnas, D., 1972. On the criteria to be used in decomposing systems into modules. Commun. ACM 15 (12), 1053–1058.

arnas, D., 1974. On a ‘Buzzword’: hierarchical structure. In: Proceedings of the 1974 IFIP Congress. Kluwer.

arnas, D., 1976. On the design and development of program families. IEEE Trans. Softw. Eng. 2 (1).

arnas, D.L., Clements, P.C., 1986. A rational design process: how and why to fake it. IEEE Trans. Softw. Eng. 12 (February (2)), 251–257.

obson, C., 2002. Real World Research: A Resource for Social Scientists and Practitioner–Researchers, 2nd ed. Blackwell Publishing, UK.

chach, S.R., Jin, B., Yu, L., Heller, G.Z., Offutt, J., 2003. Determining the distribution of maintenance categories: survey versus measurement. Empirical Softw. Eng. 8 (4), 351–365.

chmidt, K., 2002. The problem with ‘awareness’: introductory remarks on ‘aware- ness in CSCW’. Comput. Supported Coop. Work 11 (3), 285–298.

chmidt, K., Simone, C., 1996. Coordination mechanisms: towards a conceptual foundation of CSCW systems design. Comput. Supported Coop. Work 5 (2–3), 155–200.

EI, 2010. Duties, Skills, & Knowledge of a Software Architect, Last visited 15 April,

2010. http://www.sei.cmu.edu/architecture/research/competence/duties.cfm.

haw, M., DeLine, R., Klein, D.V., Ross, T.L., Young, D.M., Zelesnik, G., 1995. Abstrac- tions for software architecture and tools to support them. IEEE Trans. Softw. Eng. 21 (4), 314–335.

haw, M., Garlan, D., 1996. Software Architecture: Perspectives on an Emerging Discipline. Prentice Hall.

s and Software 83 (2010) 2211–2226

Solís, C., Ali, N., 2008. ShyWiki-a spatial hypertext Wiki. In: Proceedings of the 2008 International Symposium on Wikis. WikiSym’08. ACM.

Storey, M.-A.D., Cubranic, D., German, D.M., 2005. On the use of visualization to sup- port awareness of human activities in software development: a survey and a framework. In: SoftVis’05: Proceedings of the 2005 ACM Symposium on Soft- ware Visualization. ACM, New York, NY, USA, pp. 193–202.

The Open Group, 2009. ArchiMate 1.0 Specification. Van Haren Publishing. Tran, J.B., Godfrey, M.W., Lee, E.H., Holt, R.C., 2000. Architectural repair of open source

software. In: International Conference on Program Comprehension, p. 48. Tyree, J., Akerman, A., 2005. Architecture decisions: demystifying architecture. IEEE

Softw. 22 (2), 19–27. Unphon, H., 2009. Making use of architecture throughout the software life cycle –

how the build hierarchy can facilitate product line development. In: SHARK’09: Proceedings of the 2009 ICSE Workshop on Sharing and Reusing Architectural Knowledge. IEEE Computer Society, Washington, DC, USA, pp. 41–48.

Unphon, H., Babar, M.A., Dittrich, Y., 2009. Identifying and understanding software architecture evaluation practices. ITU technical report (almost finished).

Unphon, H., Dittrich, Y., 2008. Organisation matters: how the organisation of soft- ware development influences the development of product line architecture. In: IASTED International Conference on Software Engineering, Innsbruck, Austria, pp. 178–183.

Unphon, H., Dittrich, Y., Hubaux, A., 2009b. Taking care of cooperation when evolving socially embedded systems: the PloneMeeting case. In: CHASE’09: Proceedings of the 2009 ICSE Workshop on Cooperative Human Aspects on Software Engineering. IEEE Computer Society, Washington, DC, USA, pp. 96–103.

van der Ven, J., Jansen, A., Nijhuis, J., Bosch, J., 2006. Design decisions: the bridge between rationale and architecture. In: Dutoit, A.H., McCall, R., Mistrk, I., Paech, B. (Eds.), Rationale Management in Software Engineering. Springer, Berlin, Heidelberg, pp. 329–348 (chapter 16) http://dx.doi.org/10.1007/978-3-540- 30998-7 16.

Weilkiens, T., 2008. Systems engineering with SysML/UML: modeling, analysis, design. Morgan Kaufmann.

Wikipedia, 2010. Software Architect, Last visited 15 April, 2010 http://en. wikipedia.org/wiki/Software architect.

Hataichanok Unphon is a PhD candidate and a research fellow of evolvable soft- ware product (ESP) project at IT University of Copenhagen. Her research topic is re-engineering for evolvability that considers social, as well as technical require- ments for software products. Her research interests to date have focused on software product lines, software architecture, organisation in software development, and qualitative empirical study.

Dr. Yvonne Dittrich is associate professor the IT-University of Copenhagen. Her research interests are use-oriented design and development of software, and soft-

ware development as cooperative work. She developed the empirical research approach, Cooperative Method Development which is based on problem-oriented software process improvement organised as a learning cycle, both for the indus- trial partner, as well as for the researchers involved. In a recent project, she applied this approach to investigating the development, customization, and appropriation of software products.