Table 2 - uploaded by Kari Smolander
Content may be subject to copyright.
Source publication
Despite considerable attention paid on software architecture, the organizational aspects of architecture design remain largely unexplored. This study analyses the stakeholders participating in architecture design in three software companies, their problems in relation to architecture, and the rationale for architecture description they emphasize. T...
Context in source publication
Context 1
... first author conducted altogether 19 interviews of the key stakeholders named by the organiza- tions' intermediaries (Table 1) during August and September 2001. The semi- structured interviews covered the themes and sub-themes listed in Table 2. In addi- tion, the intermediaries and interviewees provided documents about the organizations' existing software process specifications and examples of actual architectural descrip- tions. ...
Citations
... In the field of SA Communication, a wide range of work has been done, e.g., regarding documentation [9], visualization [18], or stakeholder communication [15]. Smolander et al. argue the importance of organizational and inter-organizational communication between architects [19]. However, regarding the communication of SAMs between architects, we were not able to find related studies. ...
Context. Own experiences and faulty decisions can be an important source of information for software architects. The experiences and mistakes of other architects can also be valuable information sources. Goal. Under the assumption that the knowledge about faulty decisions, i.e., mistakes, regarding software architecture is not shared adequately in practice, this work qualitatively investigates the handling and particularly communication of those mistakes by software architects. Method. We conducted a grounded-theory study in which we interviewed ten German software architects from various domains. Results. We identified software architects' definitions of architectural mistakes, their handling of these mistakes, and their preferred communication strategies regarding these mistakes. We found that architects communicate mistakes mainly within their project teams and seldom within or across companies. Conclusions. We derived strategies to make learning and prevention of mistakes more effective. To share experiences and knowledge beyond architects' peer groups, companies should invest more effort in discussing mistakes more consciously and create an environment where mistakes can be discussed openly.
... Despite the significant influence that stakeholders have regarding the success in developing and implementing software, they reduce their participation as the software life cycle progresses. Most of the design and implementation decisions fall on experts' judgment (such as architects and technical leaders), which implies that stakeholders' viewpoints are barely considered [4]. The reasons why this scenario occurs can be varied; however, Schulenklopper et al. [5] describe that one of the main causes of the limited participation of stakeholders is related to the lack of adequate tools the architects have to communicate with them. ...
Microservice-based systems promote agility and rapid business development. Some features, such as fast time-to-market, scalability and optimal response times, have encouraged stakeholders to get more involved in the development and implementation of microservices architectures in order to translate their business vision into the implementation of the architecture. Although some techniques allow the inclusion of the stakeholders’ perspective in the design of microservice architectures, few proposals consider such perspectives in the selection and evaluation of technologies that implement microservice architectures. Indeed, the qualities that characterize microservice-based systems strongly depend on the suitable selection of technologies, such as application frameworks and platforms. This article proposes a collaborative technique that includes stakeholders and software architects in the selection and evaluation of application frameworks and platforms to implement microservice-based systems. We evaluated the technique in an industrial case of design and implementation of an Ambient-Assisted Living (AAL) system, which combines microservice architecture and Internet-of-Medical-Things (IoMT) sensors. The case results indicate that the proposed technique supported stakeholders in the pragmatic evaluation of alternative technological solutions. Additionally, it allowed the implementation of an AAL system that satisfies the quality specifications of stakeholders and end-users. This initial study suggests that actively including stakeholders in the implementation of microservice-based systems allows architects to make design decisions that better consider stakeholders viewpoints as well as managing their expectations.
... These skills help project stakeholders to strengthen connections to others and improve teamwork, decision making, problem solving, and even communicate negative or difficult messages without initiating conflict or destroying trust (Čulo & Skendrović, 2010) According to Cadle and Yeates (2008), the level of communication among stakeholders is absolutely critical to effective SEP. In most SEP, development cycle is a black hole where requirements are elicited without inputs from stakeholders (Smolander & Päivärinta, 2002). Some stakeholders might be unaware of the business case, project vision, and project objectives. ...
This research examined whether communication and feedback flow among stakeholders contribute significantly to project success. Communication and feedback flow is one of the most needed areas of project management of which attention of many researchers had been drawn to it. To ensure the project success, information such as requirements, expectations, resources, budgets, expenditures, and progress reports need to be communicated to all stakeholders on regular basis. Most software engineering projects in Nigeria have failed due to irregular communication among stakeholders in the project. To achieve the objective, questionnaire method was used to gather data from the respondents and analyzed using Pearson product moment correlation coefficient. It was concluded that communication and feedback among stakeholders contribute to effective software engineering projects in Nigeria. It is important that the project managers encourage useful contributions from the stakeholders without losing control of the project.
... Smolander and Päivärinta [3] analyzed stakeholders participating in SA design and reported their problems in relation to SA. The problems, or challenges, that were expressed by software architects included: a) the continuous lack of skilled architects, which resulted in a need for welldocumented SA specifications, and b) the communication mismatch, which results from architects' need to communicate with other stakeholders who often lack the necessary technical knowledge and insights. ...
Software architecture designs are useful artifacts; however, their development and maintenance are considered challenging. To better understand the possible causes for these challenges, this article presents a case-study intended to discover and understand software architects’ challenges and to propose domain-specific models to address these challenges. The main results of the case-study include a) the classification of challenges in software architecture design as well as an interpretation of the rationale behind these challenges, and b) two domain-specific models for addressing architects’ challenges through architectural design. The proposed models are expected to facilitate communication between development teams, and to improve the technical aspects of the information content of requirements.
... Grounded theory have been used in many areas of software engineering such as cognitive dimensions in learning software modeling [36][37], understanding of software process improvement [38][11], installation and use of an electronic process guide within a small-to-medium software development company [39], descriptive process modeling [40], understanding the social processes that influence software team performance and the influence software methods have on those processes [41], the impact of background and experience on software inspections [35], investigation of agile user-centered design in practice [42], management of software change tasks using a state-of-thepractice IDE to a medium-sized open source software system [43], self-organization of agile teams [44], the importance of adequate customer involvement on agile projects [45], the rationale for a software architecture description [46], bridging cultural differences in distributed software development [47], examining how a software process is tailored for a project [48], or analysis of pair programming [49]. ...
Software change request process is an essential sub-process in software maintenance that deals with modifications of software systems. This paper present an empirical study that uses qualitative research methods for investigating automation level of software change request process in local very small software companies. Findings of qualitative research provide a grounded understanding of the practice that is based on opinions of software experts. In research participated fifteen software experts from local very small software companies with various level of experience. Software experts were interviewed individually in their companies or participated in organized focus groups. Constructivist grounded theory methods were used as a suitable choice for discovering common practice and for creating explanations that are grounded in empirical data. Better understanding of the study is achieved through description of the research context and procedures. Research findings are presented with the focus on inductive analysis that led to identification of automation level as a property of software change request process. Analysis of empirical data reveals that very small software companies do not have automated software change request process, or have automated only parts of the process. In the paper are also considered validation and constraints of the study. Despite identified constraints, this study helps in building deeper understanding of current practice in very small software companies, helps in identifying problems in the practice as potential staring points for further improvements, and contribute to the body of empirical knowledge in software engineering.
... Internally, GEA stakeholders include government chief information officers (GCIO), government chief technology officers (GCTO), agency heads and heads of business units, business and information analysts, and project managers and IT officers [10]. Externally, GEA stakeholders include government customers (business and citizens) as well as civil society and private sector organizations [19]. ...
Recognized as a critical factor for the whole-of-government capability, many governments have initiated Enterprise Architectures (EA) programs. However, while there is no shortage of EA frameworks, the understanding of what makes EA practice effective in a government enterprise is limited. This paper presents the results of empirical research aimed at determining the key factors for raising the maturity of the Government Enterprise Architecture (GEA) practice, part of an effort to guide policy-makers of a particular government on how to develop GEA capabilities in its agencies. By analyzing data from a survey involving 33 agencies, the relative importance of factors like top management commitment, participation of business units and effectiveness of project governance structures on the maturity of the GEA practice was determined. The results confirm that management commitment and participation of business units are critical factors, which in turn are influenced by the perceived usefulness of the GEA efforts.
... Grounded theory have been used in many areas of software engineering such as cognitive dimensions in learning software modeling [19], understanding of software process improvement [20][21], installation and use of an electronic process guide within a small-tomedium software development company [22], descriptive process modeling [23], understanding the social processes that influence software team performance and the influence software methods have on those processes [24], the impact of background and experience on software inspections [25], investigation of agile user-centered design in practice [26], management of software change tasks using a state-of-the-practice IDE to a medium-sized open source software system [27], self-organization of agile teams [28], the importance of adequate customer involvement on agile projects [29], or the rationale for a software architecture description [30]. ...
Software systems change during all phases of their life cycles. After software delivery, users should have effective ways for specifying new requests and reporting problems. Handling of this new requests or problem reports must be supported with sound processes and appropriate tools. In this paper is presented a segment of qualitative research conducted with software experts from very small software companies related to change request process in maintenance phase of software life cycle. Software experts were interviewed in their companies or participated in focus groups. This research used constructivist grounded theory that is suitable methodology for creating explanations of common practice. Analysis of qualitative empirical data revealed properties regarding process implementation, the level of automation, feedback, iterativeness and process duration.
... The target blueprint thus decomposes the complexity of the organization into comprehensible and manageable business and IT components. This allows for better communication between the various stakeholders of the organizational problem at hand (Smolander and Päivärinta, 2002). In contrast, Software Architecture (SA) aims at creating one system or component within the information systems aspect area (Bass et al., 1998). ...
... However, regarding the attributes of the products and services of the EA function, each stakeholder expects these to help achieve their goals (Gutman, 1997). We used the key SA stakeholder roles described by Smolander and Päivärinta (2002) to create the 4 by 4 matrix of EA stakeholders shown inTable 1. The columns represent the four EA aspect areas (Lankhorst, 2009) and the rows represent the four organizational levels (van der Raadt and van ). ...
... Even though they describe elements of importance for the collaboration between architects and stakeholders, they focus primarily on the software architect's perspective. Smolander et al. describe stakeholder participation in software architecture design, including their problems in relation to architecture, and the rationale for architecture description they emphasize (Smolander and Päivärinta, 2002). However, they primarily focus on the role of stakeholders from the software architect's perspective. ...
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 a b s t r a c t Enterprise Architecture (EA) is increasingly being used by large organizations to get a grip on the com-plexity of their business processes, information systems and technical infrastructure. Although seen as an important instrument to help solve major organizational problems, effectively applying EA seems no easy task. Active participation of EA stakeholders is one of the main critical success factors for EA. This participation depends on the degree in which EA helps stakeholders achieve their individual goals. A highly related topic is effectiveness of EA, the degree in which EA helps to achieve the collective goals of the organization. In this article we present our work regarding EA stakeholder satisfaction and EA effec-tiveness, and compare these two topics. We found that, regarding EA, the individual goals of stakeholders map quite well onto the collective goals of the organization. In a case study we conducted, we found that the organization is primarily concerned with the final results of EA, while individual stakeholders also worry about the way the architects operate.
... Architecture researchers have found that the work of an architect and the usage of architecture are bound by more diverse organizational issues and limitations that the classical technical software architecture research ignores. These include for example the diverse role of an architect in an organization observed by Grinter (1999) and varying uses and meanings of architecture in practice (Smolander & Päivärinta, 2002a). The main message of these studies is that an architect has a social and even a political role in an organization and that different stakeholders relate different meanings to architecture to fulfill their informational requirements in the development process. ...
... • Peer debriefing and support: the research has included regular meetings and discussions with involved research participants from several research institutions. In addition, preliminary results of research phases have been presented and discussed in conferences and workshops (Smolander, 2003;Smolander, Hoikka, Isokallio, Kataikko, & Mäkelä, 2002;Smolander et al., 2001;Smolander & Päivärinta, 2002a, 2002bSmolander, Rossi, & Purao, 2002. ...
This paper describes the architecture development process in an international ICT company, which is building a comprehensive e-business system for its customers. The implementation includes the integration of data and legacy systems from independent business units and the construction of a uniform web-based customer interface. We followed the early process of architecture analysis and definition over a time period of a year. The research focuses on the creation of e-business architecture and observes that instead of guided by a prescribed method, the architecture emerges through somewhat non-deliberate actions obliged by the situation and its constraints, conflicts, compromises, and political decisions. The interview-based qualitative data is analyzed using grounded theory and a coherent story explaining the situation and its forces is extracted. Conclusions are drawn from the observations and possibilities and weaknesses of the support that UML and RUP provide for the process are pointed out.
... Architecture researchers have found that the work of an architect and the usage of architecture are bound by more diverse organizational issues and limitations that the classical technical software architecture research ignores. These include for example the diverse role of an architect in an organization observed by Grinter (1999) and varying uses and meanings of architecture in practice (Smolander & Päivärinta, 2002a). The main message of these studies is that an architect has a social, and even political, role in an organization and that different stakeholders relate different meanings to architecture to fulfill their informational requirements in the development process. ...
... • Peer debriefing and support: The research has included regular meetings and discussions with involved research participants from several research institutions. In addition, preliminary results of research phases have been presented and discussed in conferences and workshops (Smolander, 2003;Smolander, Hoikka, Isokallio et al., 2002;Smolander & Päivärinta, 2002a, 2002bSmolander, Rossi, & Purao, 2002. • Member checking: The interpretation of the data has been confirmed by presenting the results to company participants in the research project. ...
This article describes the architecture development process in an international ICT company, which is building a comprehensive e-business system for its customers. The implementation includes the integration of data and legacy systems from independent business units and the construction of a uniform Web-based customer interface. We followed the early process of architecture analysis and definition over a year. The research focuses on the creation of e-business architecture and observes that instead of guided by a prescribed method, the architecture emerges through somewhat non-deliberate actions obliged by the situation and its constraints, conflicts, compromises, and political decisions. The interview-based qualitative data is analyzed using grounded theory and a coherent story explaining the situation and its forces is extracted. Conclusions are drawn from the observations and possibilities and weaknesses of the support that UML and RUP provide for the process are pointed out.
