Keywords

1 Introduction

The discipline of Software Architecture emerged in the past two decades in academia [19] and more recently in software industry [4, 8, 21, 24]. A large number of patterns, frameworks, methods, tools and languages related to activities of software architecture have been proposed within this period. Even a well-known standard, the ISO/IEC/IEEE 42010 [13], was published. This International Standard specifies the manner in which architecture descriptions of systems are organized and expressed, which confirms the importance of software architecture as a discipline of software engineering.

The role of the software architect has become increasingly common in industry, but the activities, tasks, processes and daily chores related to the software architect became a point of discussion. For instance, do software architects develop source code? How do their work relates to the work of project managers? How long does it take to someone become a (real) software architect? These questions are still subject of debate in academia and industry [1, 8] in which patterns and “antipatterns” have been suggested [11, 17].

Given the improved importance of software architecture in academic research and industrial practice it is necessary to better understand this role. In this paper we describe a survey about the daily activities performed by professionals who work as software architects in Brazil. The goal is to better understand what software architects actually do in their daily activities in practice, and how this resembles or distances themselves from the skills, roles and knowledge cited in the literature as essential.

The research question in this paper is stated as follows:

RQ - To what extent Software Architect professionals in Brazil perform software architecture activities?

Within this RQ, the idea is to describe, given a number of activities that are known as responsibilities and skills of software architects, searched in the literature, which ones are most performed by software/systems architects working in Brazil.

2 Patterns and Antipatterns of the Software Architect Job

Despite past efforts, we still have little understanding and there is no clear consensus of what software architects do in real-world settings [7]. Several authors have defined software architect patterns and anti-patterns over the past years. Koenig introduced the concept of antipattern in [15], by defining an antipattern just like a pattern, except that instead of a solution it gives something that looks superficially like a solution but is not [15].

Krutchen, in [17], defined as the main antipatterns of software architects: (i) creating a perfect architecture for the wrong system, (ii) creating a perfect architecture, but too hard to implement, (iii) architects in their ivory tower, and (iv) the absent architects. These antipatterns means, respectively, (i) a software architect who is not communicating has a greater probability of not understanding or only gradually understanding the software concerns, (ii) a software architect who does not understand the capability of the implementation team(s) that will create enormous levels of stress and frustration, and will most likely not deliver a quality product in time, (iii) architects that are isolated, not getting enough input from the users and developers, and (iv) the software architect that comes with a complete architecture, out of the blue, which does not relate well to actual problems described in many organizations.

All these antipatterns will experience rejection, because developers must wait for architectural decisions, and no or little architecture design progress is made. Software architects are always away doing other things or fighting fires instead of taking care of architecture. The whole architecture will suffer from immaturity.

Regarding patterns, we have gathered information about definitions of duties, skills, and knowledge of the software architect. We have used definitions from the Software Engineering Institute [26] as a reference and performed a literature review with emphasis mainly on articles already recognized about the roles and responsibilities of the software architect, including [11, 14, 17, 20].

After we have evaluated the gathered information, we constructed the following set of activities of the software architect which are considered patterns that the software architect should follow to be considered successful:

  1. 1.

    Define the architecture.

  2. 2.

    Create documents that describe the architecture.

  3. 3.

    Act as a communicator of the software architecture.

  4. 4.

    Make sure everyone is using the proposed architecture.

  5. 5.

    Certify everyone is using the architecture correctly.

  6. 6.

    Make sure that architecture comes out in stages in a timely way so that the overall organization can make progress before it is complete.

  7. 7.

    Certify software and architecture are in synchronization.

  8. 8.

    Certify that management understands the necessary architectural details.

  9. 9.

    Make sure the right modeling is being done, knowing which qualities are going to be met.

  10. 10.

    Assist in tool and environment selection.

  11. 11.

    Identify and interact with stakeholders to make sure their needs are met.

  12. 12.

    Convince stakeholders about the value of the architectural solution.

  13. 13.

    Certify that architecture is not only right for operations, but also for deployment and maintenance.

  14. 14.

    Perform conflict resolution and analyze tradeoffs.

  15. 15.

    Solve technical problems.

  16. 16.

    Maintain and raise the morale of the architecture team.

  17. 17.

    Understand and plan the evolution of architecture.

  18. 18.

    Plan the insertion of new technologies.

  19. 19.

    Manage strategies for identifying and mitigating risks associated with the architecture.

  20. 20.

    Assist in understanding the problem domain.

  21. 21.

    Apply standards already used to solve past problems.

  22. 22.

    Keeping up-to-date with the latest trends.

  23. 23.

    Participate in the planning of projects.

  24. 24.

    Manage individuals and teams.

  25. 25.

    Establish architectural decisions.

  26. 26.

    Think about what impact the decisions have on the current architecture.

  27. 27.

    Act as a technology consultant.

  28. 28.

    Full software life cycle involvement.

  29. 29.

    Assisting product marketing and future product definitions.

3 The Survey

The following sections describe the methods used for conducting the survey.

The web questionnaire for this survey was designed and hosted by the online Google survey service, Google Forms. The questionnaire is composed of thirty-six questions, divided into two different parts. The first part is proposed in order to gather descriptive statistics to summarize the backgrounds of the respondents, and the second part of the survey focused on questions about the functions performed by the software architect in order to answer the research question presented in Sect. 1.

The first six questions are present in part I of the questionnaire, as follows:

  1. 1.

    What is your current job?

  2. 2.

    What is your level of formal education?

  3. 3.

    Number of years of experience in Information Technology related jobs.

  4. 4.

    Number of years in your current position.

  5. 5.

    How many projects are you involved simultaneously in your current job?

  6. 6.

    Do you work currently in which state in Brazil?

The other twenty-nine questions are relative to the twenty-nine patterns presented in Sect. 2. Each activity is measured using multiple response items scored on a 5-point Likert-type scale: 1- Never, 2- Rarely, 3- Sometimes, 4- Often, and 5- Always. The twenty-nine questions about the software architect functions were formulated as affirmative sentences, each sentence representing an item of the patterns found. All Thirty-five questions of parts I and II are mandatory, however we have created a thirty sixth optional and subjective question with the purpose of gathering comments on the routine as a software architect and suggestions for the research.

The first draft of the research instrument was tested and validated by four software architects, all with more than five years of experience in the area, in order to evaluate the understanding of the questions and suggest possible improvements.

After making adjustments from the pilot study and create the revised final version of the questionnaire, the survey was performed between August and September of 2018. Initially, a questionnaire was sent to 3187 professionals who declared their current position on the LinkedIn platform in Brazil as a software architect.

LinkedIn does not allow unlimited inbox messages to be sent to people who are not connected. Therefore, it was necessary to send invitations individually. Each invitation allowed to send a text with a maximum of 300 characters, thus it was necessary to summarize the purpose of the study and the request to participate in the research on the work of the software architect within this small amount of characters.

Then the authors opened each profile individually, clicked on “Connect” and then on “Add Note”, inserted the message requesting the answer to the questionnaire and finally clicked on “Send Invitation”.

The survey was anonymous, and participation in the survey was voluntary. All invited respondents were informed about the survey with an invitation text describing goals of the study. In addition to the 3187 invitations, the authors have had also the opportunity to submit the questionnaire to the architectural committee of one of the largest software companies in Brazil (a total of forty five members of the committee, about fifteen thousand employees working in Brazil and twenty five thousands all around the world).

Thus, we had a total of 3232 invitations and 536 responses, achieving a response rate of approximately 16.6%. Of the total of 536 responses, 72 respondents also answered the optional question.

4 Results

In this section, the results of our study are presented. We first presented the results of characterization questions. For each question, a graphic was created with the amount of answers referring to each alternative of the question.

Figure 1 depicts the level of education of the study participants. Most study participants have a MBA or other post-graduation course (42,4%). This is an important fact, as it is essential that they stay up to date with new trends and many should have sought better qualification through a professional MBA.

Fig. 1.
figure 1

Level of education

Full size image

A large part of the study participants (32,6%) have at least completed an Undergraduate course, mostly in Computer Science, Information Systems or Computer Engineering, and 11,9% completed an academic Master’s degree in Computer Science. What draws attention to these numbers is the amount of study participants who are still attending an Undergraduate course (13,4%) and the small number of people who have a PhD (0,4%), just 2.

Figure 2 depicts the number of years of IT experience before becoming a software architect. 85.3% of respondents have more than 9 years of experience and 11.8% have between 6 and 8 years, that is, 97% of respondents have more than 5 years of experience in IT. This high percentage shows that usually software architects have been working in industry for a long time and already have personal experience with IT. Of the remaining 3%, 2.6% have between 3 and 5 years and only 0.4% have less than 2 years of experience.

Fig. 2.
figure 2

Years of experience in IT jobs

Full size image
Fig. 3.
figure 3

Years of experience as software architect

Full size image

Figure 3 depicts the number of years of experience in the position as software architects. All alternatives obtained a significant amount of answers. Over a quarter of the participants (26.9 %) have less than 2 years of experience, that is, they are beginning their careers as software architects. In contrast, 15.1% of the study participants are experienced architects, with more than 9 years in the position. The most expressive response, with 37.1%, was from architects with 3 to 5 years of experience, and 20.9% are architects with 6 to 8 years of experience.

Figure 4 depicts the current position of the participants. As suggested in [9], there may be several nomenclatures for the position of architect. It is difficult to distinguish which competencies differentiate one job from the other.

Fig. 4.
figure 4

Current position of participants

Full size image

According to our filtering through LinkedIn, we know all participants work or have worked at some point of their career as software architects. This question aims to find out how many of them are still performing as software architects. This is a multiple choice question, allowing for more than one option, therefore the sum of percentages exceeds 100. The majority of respondents (74.1%) still works currently as software architects, 15.7% works as systems architects, 18.5% works as software developers, 22.6% works as a technical leader, and a minority works as other jobs titles.

Fig. 5.
figure 5

Amount of projects simultaneous

Full size image

Figure 5 depicts in how many projects the participants are involved simultaneously in their current job. For this question, all alternatives also obtained a significant amount of answers. There were three options, about a third (31,5%) of the respondents are involved with at most 2 simultaneously, it is inferred that a part of them may be working with only one project. 44.2% are involved simultaneously with 3 to 5 projects and 24.3% are involved with more than 5 projects simultaneously.

5 Discussion

The results of the research provide many possibilities of reflection. In this section, we present the answers to RQ presented in Sect. 1.

To answer the research question RQ, “To what extent Software Architect Professionals in Brazil perform software architecture activities?” we analyzed the answers and statements written by study participants.

To assist and complement the answer of research question, we present Table 1 that gathers the most performed activities by the professionals in their work. Table 1 is composed of the question number, the numbering described in Sect. 2, the percentage of participants who answered the respective question using alternative “Always”, “Often” and the sum of percentages of participants who responded to the relative sentence answering “Always” or “Often”, in descending order. In this study we considered the sum of alternatives “Always” and “Often” as the total of positive responses to the question.

As can be seen in Table 1, the five activities most executed by software architects in Brazil were: “Think about the impact that decisions have on the current architecture” (26), “Apply standards already used to solve past problems” (21), “Certify that architecture is not only right for operations, but also for deployment and maintenance” (13), “Assist in understanding the problem domain” (20) and “Solve technical problems” (15).

Table 1. Total positive responses
Full size table

Keeping in mind that the software architect is required to strike a balance between technical knowledge, domain knowledge and communication skills [3, 17], this set of activities corroborates strongly with what is expected from a software architect.

With the similar intention to Table 1, we created Table 2 that gathers the less performed activities by professionals in their work. We have selected only those questions that have more than 25% of negative response rate (“Rarely” + “Never” + “Sometimes”).

Table 2. Total negative responses
Full size table

The five less executed activities by software architects in Brazil were: “Assisting product marketing and future product definitions” (29), “Manage individuals and teams” (24), “Create documents that describe the architecture” (2), “Make sure that architecture comes out in stages in a timely way so that the overall organization can make progress before it is complete” (6) and “Certify that management understands the necessary architectural details” (8).

As depicted in Table 1, question 26 had the highest response rate for the “always” alternative (67.20%) and ranked first in the activity ranking, totaling 95.70% of positive responses. One of the key processes in software architecture is decision making [16, 30]. Therefore, that specific question having a high positive response rate means that software architects in Brazil are probably truly concerned about the future consequences that may arise in the development and use of the system from their architectural decisions.

Only 67,20% of the respondents have said they always or often worry about risks. According to [27], it has become the architect’s role to balance factors such as risk, quality, constraints, and costs when deciding whether to use, buy, or build a component is more advantageous, then this question could have had a more expressive percentage of positive responses.

On sentence 20, “Assist in understanding the problem domain”, the index of positive responses was high, 86,20%. It is important that the architect understands very well the domain of the problem so that he/she chooses the architectural details that represent the best solution for each case. Within the architectural decisions theme, 84.20% of respondents affirmed in sentence 25 they always or often “Establish architectural decisions”. This is a good result, since the software architecture of a system is the result of a set of architectural decisions [28], and the architect is becoming the manager of architectural knowledge, acting as a facilitator for decision-making and ensuring that decisions are appropriate and coherent to the context of action [30].

Another question with one of the highest rates of positive responses (86,70%) was sentence 13, “Certify that architecture is not only right for operations, but also for deployment and maintenance”. This is very important, since the software architecture is constantly evolving and adapting. According to Erder and Pureur [6], architects must have a long-term vision, because the products and software survive even after the end of a project. Even after the software is deployed and being used by the client, there may still be numerous maintenance or addition of new features.

Strengthening the hypothesis about keeping the architect’s eye on the future of software, about sentence 17, “Understand and plan the evolution of architecture”, 80,60% of the respondents have chosen alternatives always or often.

89,90% of the respondents also responded positively to sentence 21, “Apply standards already used to solve past problems”. This is a great result, that almost 90% of architects already have experience and have participated in other projects previously. This is a considerable result, because since most architectural decisions made by architects are made early in the project, they use their experience and abstraction skills to get them [10].

Although most of the respondents seem to be seasoned professionals, they did not stop looking for updates, 86,20% said always or often are keeping up-to-date with the latest trends (question 22), and 74,3% of the respondents always or often plan insertion of new technologies (question 18). Even with a nearly 12% difference between the two questions, this means that even the most experienced architects are still trying to keep up with new trends.

76,50% of the respondents answered positively to sentence 4, making sure everyone is using the proposed architecture, but 18,1% mentioned that they make sure only sometimes. Consequently, almost the same percentage of positive answers from the previous question (76,10%), is sentence 7, “Certify software and architecture are in synchronization”. This similarity makes a lot of sense, whereas for both to remain always synchronized, it is necessary for the architect to constantly check whether the architecture that was proposed is actually being used.

When it comes to certifying that the proposed architecture is being used correctly (sentence 5), the result was a bit different. 70,70% of the respondents answered to carry out this activity always or often. Since the number of positive responses was lower than previous sentence “Certify software and architecture are in synchronization”, the number of negative responses also increased. 22,60% of the respondents only certify sometimes, and 6,0% answered they rarely certify the architecture is used correctly.

Still following this line of reasoning involving the actual use of the architecture in practice, on question “Make sure the correct modeling is being done, knowing which qualities will be met” (sentence 9), the result is a bit more negative, 29,5% of the respondents choose negatives responses, and 70,50% choose between always or often. However, according to Tofan et al. [28], in their activities, architects need to consider the functional requirements and quality attributes (or non-functional requirements) of software systems. In addition, quality attributes play an important role in the decision-making process, since architects may compromise some quality attributes through tradeoffs (e.g. security versus usability) [28].

A similar example occurs when the subject is architecture definition and documentation. Considering the sentence “I define the software architecture” (sentence 1), 80,60% of respondents chose alternatives always or often, which is a great number of positive answers, but considering the content and importance of the question, since this activity is one of the main activities, and well recognized by several authors [6, 17, 25]. This percentage may be a little more expressive, and it is only enough to occupy the tenth position in the ranking of questions with the highest percentages of positive answers, as presented in Table 1.

In contrast to the number of professionals who responded positively to sentence 1, the same is not true for sentence 2, “I create documents that describe the architecture”. Although documented decisions facilitate the general understanding of a system, architectural knowledge sharing, and evaluation processes [18]. One troubling result is the percentage of negative responses, 45,2% of the respondents answered negatively for sentence 2 and 54,80% choose alternatives always or often. This percentage places sentence 2 within the ranking of questions with a greater amount of negative answers, as depicted in Table 2. There may be a rationale for increasing adoption of agile methodologies with greater focus on coding and less focus on documentation.

One of possible implications is that some architects seem to work isolated. More than a half (51,8%) of respondents answered negatively to manage individuals and teams, (question 24), making this question occupy the second position of the ranking of questions with higher rate of negative answers. As already described in Sect. 1, architects working in isolation is an antipattern, architects in the ivory tower.

Probably this lack of group work influenced the high rate of negative responses to sentences such as “Perform conflict resolution and analyze tradeoffs” (question 14), with 35,9%, and “Maintain and raise the morale of the architecture team” (question 16), with 32,5%. Considering this separation between the architect and the team that will develop the software, it is possible that the antipattern “creating a perfect architecture, but too hard to implement” anti-pattern is reached.

One fact that promotes reflections and draws attention is that among the questions with the highest rates of negative responses, as presented in Table 2, most are composed of tasks that require the architect to be involved with the organization or other stakeholders, although sentences such as 3, “Act as a communicator of the software architecture” and 4, “Identify and interact with stakeholders to make sure the needs are met”, have received considerable percentages of positive responses, 77,6% and 72,20% respectively.

On sentence 23, “Participate in the planning of projects”, 69.60% chose positive answers, which means that many architects (about 30%) in Brazil are not being involved in initial stages of defining the software project. In fact, software architects seem to be less involved even when it comes to business and marketing, apparently an overwhelming majority never even got involved in those steps, as shown in sentence 29, “Assisting product marketing and future product definitions”.

Sentence 28, “Full software life cycle involvement” received 38,7% of negative responses. Since software architecture is the central element throughout the software life cycle [29], it is imperative that the software architect has more active participation in all phases of the software life cycle.

It is worth mentioning two other sentences about the architect’s involvement with the organization. The first is that 40,6% of the respondents answered negatively to “Certify that management understands the necessary architectural details” (sentence 8), and the second is that 36,3% answered negatively to “Convince stakeholders about the value of the architectural solution” (sentence 12). This impaired communication with the stakeholders can lead to several problems of understanding and acceptance of the architecture. Perhaps this lack of communication has influenced the amount of negative responses (41,2%) received by the question “Make sure that architecture comes out in stages in a timely way so that the overall organization can make progress before it is complete” (sentence 6). Without transparency and good relationship, it is very difficult for the architecture to be defined in such an efficient way.

Software architects operate in a social and organizational setting with different stakeholders and forces that influence the tasks they perform [7]. As described before, a software architect who is not communicating has a greater probability of not understanding or only gradually understanding the software concerns. Architects should ensure a coherent and sustainable architecture, for which the communication and collaboration skills become very relevant [6].

Regarding the questions about knowledge and technical skills, 73,90% answered they always or often act as a technology consultant (sentence 27), 83,4% mentioned they always or often assist in issues such as selecting environments and tools (sentence 10). The issue on solving technical problems (sentence 15) was very similar (84,70%), being one of the sentences with the highest index of positive answers.

In relation to the subjective question, we separate some significant sentences written by study participants:

“In most companies, it is not always that the architect has an active voice and/or decision-making power. Unfortunately, decisions are made on a time/delivery basis, that is, no matter how much it costs or if it will work, what is important is to deploy on time and show to stakeholders that the software product is there. It is sad when you look back and see a trail of destruction that extends until the project is canceled. And when the project is not canceled, the company coexists with the problems for decades”.

“I once heard a phrase that made me think about the job. The most important role of the software architect is to transform business requirements into technical ideas. It is not necessary for the architect to develop, but mainly it is necessary that he/she is the bridge between the product management and the technical team”.

“In Brazil, in most software companies, the role of the architect is not well defined, so he/she needs to be involved in all development processes and even often develop everything, he/she has become a senior developer model that we call full stack. This practice compromises the deadlines and quality of software”.

6 Threats to Validity

In this study, we address internal, external, construct and conclusion threats to validity.

6.1 Conclusion Validity

By making explicit the thirty-six questions used in the questionnaire and the entire protocol followed to find the architects in LinkedIn and send the questionnaires to be answered, we believe that our results are valid and can be replicated in other countries.

6.2 Construct Validity

In our revision study about the roles, skills and responsibilities of the software architect, we make efforts to gather as much information as possible. Thus, we believe the found patterns represent vastly the patterns dictated by the literature in software architecture.

6.3 External Validity

External Validity refers to the strength of generalization of the study [5]. We cannot disregard the fact that the survey was answered only by professionals through LinkedIn who are working in Brazil, thus the results cannot be easily generalized. Although this is correct, it is important to notice that a large number of these professionals work in multinational companies, besides they have had international experience (MBAs, masters or PhD studied abroad), or even working experience in other countries. Besides, the number of respondents is considerable, when compared to other surveys in Software Engineering research, as for instance, 449 in [12], 258 in [2], 268 in [22] and 99 in [23].

6.4 Internal Validity

Internal Validity refers to how much the data supports the study results. A typical mistake is the misuse of statistical analysis [5]. In this study, we used basic statistics to analyze data, so threats of internal validity are minimal.

7 Conclusion

This study analyzed the understanding of software or systems architects workers about the tasks, activities and skills of the software architect at their daily work. The research consisted of the design, application, and analysis of a survey aiming at finding the understanding of how the profession of software architect is performed by professionals in Brazil.

The vast majority of questions received a high percentage of positive responses. Although some have had a significant amount of negative responses, in the big picture the architects have actually performed much of the activities that are explained in the literature, although the authors also have some differences between what they consider as the role of the software architect, there are some activities that are basically a consensus between them.

However, we could notice, mainly from the sentences of the subjective questions that there is still a lack of understanding about the role of the software architect by the companies, who end up treating the software architect as a senior developer. This study can help the IT recruiters to find professionals who actually have the skills expected from a software architect.

As for future work, the approach used within this research can be used in other countries, or even in a number of countries. Therefore, it will be possible to compare the results between countries, but also to have a higher degree of confidence with results presented in this paper.