Architectural patterns are frequently found in various software artifacts. The wide variety of patterns and their implementations makes detection challenging with current tools, especially since they often only support detecting patterns in artifacts written in a single language. Large Language Models (LLMs), trained on a diverse range of software artifacts and knowledge, might overcome the limitations of existing approaches. However, their true effectiveness and the factors influencing their performance have not yet been thoroughly examined. To better understand this, we developed MicroPAD. This tool utilizes GPT 5 nano to identify architectural patterns in software artifacts written in any language, based on natural-language pattern descriptions. We used MicroPAD to evaluate an LLM's ability to detect instances of architectural patterns, particularly infrastructure-related microservice patterns. To accomplish this, we selected a set of GitHub repositories and contacted their top contributors to create a new, human-annotated dataset of 190 repositories containing microservice architectural patterns. The results show that MicroPAD was capable of detecting pattern instances across multiple languages and artifact types. The detection performance varied across patterns (F1 scores ranging from 0.09 to 0.70), specifically in relation to their prevalence and the distinctiveness of the artifacts through which they manifest. We also found that patterns associated with recognizable, dominant artifacts were detected more reliably. Whether these findings generalize to other LLMs and tools is a promising direction for future research.

Natural questions are crucial to shaping key architectural decisions and preserving architectural knowledge. They arise organically during the architectural design process, often resulting from the existing architectural experience of the designer and the distinctive characteristics of the system being designed. However, natural questions are often mismanaged or ignored, which can lead to architectural drift, knowledge loss, inefficient resource use, or poor understandability of the system's architecture. We aim to better understand the lifecycle of natural questions, its key requirements, challenges and difficulties, and then to envision an assisted environment to properly support it. The environment should be adaptable and responsive to real-world constraints and uncertainties by seamlessly integrating knowledge management tools and artificial intelligence techniques into software development workflows. Based on existing literature, a requirements workshop, and three design iterations, we proposed a lifecycle for natural questions and elicited essential functional and non-functional requirements for such an environment. At last, the results of a survey conducted with experts helped to analyze and validate the elicited requirements and proposed features for the environment to enhance collaboration, decision-making, and the preservation of architectural knowledge more effectively than conventional methods.

Recent advances in artificial intelligence technology are creating new opportunities for computing solutions. AI has become very popular, and is widely used for many different applications. However, it is not a silver bullet, and could produce inferior results, wasting time and money if not used appropriately. But there is as yet little guidance about when and where AI should be used, and where traditional deterministic solutions should be used. We describe characteristics of problems that indicate appropriateness for AI solutions. These characteristics are based on the inherent uncertainty of the problem’s inputs, outputs, and transformation between them. Analysis of the uncertainty forms the basis of guidelines one can use when considering whether to employ AI-based solutions for a given problem.

Since patterns of the dynamics of organizations were introduced, they have had an enduring impact on the practices of software development. They have influenced the notable software practices such as Scrum and Extreme Programming, and Agile software development in general. The main work, Organizational Patterns of Software Development has been widely cited. It continues to be cited in academic works even to this day. The patterns appear to have had the greatest impact on agile development processes and the dynamics of communication and collaboration. However, they also appear to have had some influence in a broad range of other areas.

This tutorial delves into the transformative power of asking effective questions in engineering information systems. We explore how crafting well-defined questions in both the problem space (what issue are we addressing?) and the solution space (how will we approach it?) is paramount for success. The session will unveil the intricate relationship between these questions - how the "what" shapes the "how" and vice versa. We move beyond the fear of asking "naive" questions, demonstrating how these can spark innovation and reveal hidden assumptions. By the end, attendees will have a powerful and easy-to-use technique that removes the fear from questions.

During the process of software architectural design, numerous questions arise which must be answered. These questions may be about requirements on the proposed system (the problem space) or about how the system should be designed and developed (the solution space). As questions arise they may be answered immediately, deferred until later, or provisionally answered with an assumption about the answer. The objective of this work was to explore the nature of questions that arise during architecture. We explored the types of questions, how they are organized, how they are tracked, and how and when they are answered. We started by surveying highly experienced architects about their practices with respect to architectural questions. We also performed a controlled experiment with master students about organizing architectural questions that clarified and substantiated the survey data. We learned that architectural questions include slightly more questions about the problem space than the solution space, as well as a minority of questions related to the managing of the project. We found that architects often use ad hoc methods to organize and track them, although they typically organize them along more than one dimension. We learned also that, about a third of the time, architects make assumptions about the answers to architectural questions in order to make progress on the architecture. This suggests that some projects may have risks of incorrect design or later costly rework due to inadequate tracking or incorrectly answered architectural questions.

The inherent complexity of a software system of any size requires intentional design of the architecture. Numerous tools have been developed so support recording architecture decisions, but generally architecture decisions remain inadequately documented. Architecture decisions are generally recorded as text, but the ideas do not lend themselves to textual representation. One obstacle to documenting architecture decisions is the inherent difficulty of capturing the decisions themselves. It can be difficult to remember to document a decision when it is made. We propose focusing on recording "Notable Decisions", those that require explicit documentation. We identified characteristics of such decisions. We conducted a limited controlled experiment to investigate the nature of notable decisions. Preliminary results indicate that most of the decisions made were obvious, but some were notable and needed explicit documentation, suggesting that focusing on documenting notable decisions may be useful.

Software architecture plays a critical role in ensuring the quality attributes of a software system (i.e. security, performance, availability, usability, and maintainability). With the advent of cloud computing, popular software architectures are changing. An important change is that some aspects of some quality attributes are now implemented in the cloud software. Architecture elements called tactics (i.e. design decisions that affect the achievement of quality attributes) are built to address the quality attributes of a software architecture. The implementation of a software application using components from a commercial cloud computing platform inherits the quality aspects of the tactics used as part of the implementation of the cloud components, freeing application developers from worrying as much about the quality attributes. We investigated components of the cloud service Amazon Web Services (AWS) and found implementations of key elements of several quality attributes. Furthermore, we identified existing and new tactics used in AWS components to address these quality attributes. In particular, we identified five common quality attributes implemented in AWS components, along with associated tactics: Reliability, Scalability, Performance, Availability, and Security. Most of the tactics are modifications of existing tactics; but several tactics in Security are new. This illustrates the rapid change in the area of security. opportunities for additional research include expanded studies of tactics in cloud services, and organizing and cataloguing of new tactics.

ABSTRACTWith the advent of web services platforms, the architectures of applications deployed on these platforms have evolved from architectures found in early software systems. A study of reference architectures provided by Amazon Web Services showed eight architecture patterns. These patterns are similar to the original software architecture patterns, but they may be sufficiently different to be considered separate patterns in their own right. If they are not new patterns, it is still worthwhile to document them as modern uses of legacy architecture patterns. This paper briefly describes the patterns found and gives their frequency. It also describes three of the web services architecture patterns in detail.

Scrum is an agile project management methodology, founded on principles of a learning organization. The principles of a learning organization are systems thinking, personal mastery, mental models, shared vision, and team learning. However, if organizations follow the Scrum practices without understanding the underlying principles, Scrum does not work as well as intended. Ideally, the foundational principles should be learned together with the Scrum practices, but often teams learn the practices without the principles. We have successfully taught Scrum practices and principles together in a graduate course in software engineering, and found students were able to execute Scrum effectively. We propose how the principles can also be taught in an industrial setting where practitioners know Scrum practices but not the foundation.

Mappings in software architecture from components to requirements have the potential to reveal valuable information to both architects and stakeholders. This research creates a desktop application to explore the patterns and meanings of these mappings through visualization. Observations from the visualization tool provide a foundation to potentially improve the architecture process. This could enable architects to make better decisions in order to resiliently handle feature enhancements to the architecture, in addition to scalability and maintenance.

Architecture patterns are commonly used to specify, understand, and document software architectures. As a system evolves, its architecture patterns are affected. In some cases, the patterns themselves may change. We studied the architectural documentation of a large number of open-source systems to learn how the architecture patterns change as the systems evolve. In some cases, the existing patterns accommodate the system evolution without changing, such as adding layers to a layered architecture. In other cases, new patterns are added where no patterns existed. In some cases, new patterns were added to existing architecture patterns. And in a few cases, a pattern changed to a different architecture pattern. We observed instances of each type of change. In most cases, there was a logical structural evolutionary path to the new pattern. Typically, the architecture documentation also explained the important quality attributes that motivated the changes. We propose this work as a foundation for the study of how architecture patterns change as system architectures evolve.

Participants in open-source software projects are often geographically dispersed, and may work in different companies, and have different visions of the software. These present special challenges to creating unified architectural decisions. Yet open-source projects are often successful. We studied architectural documentation of forty-four open-source (OSS) projects, and found some evidence of how architectural decisions were made. It appears that the decision making process is not significantly different from that in traditional software projects. In particular, it was characterized by careful, intentional software design, with attention to quality attributes. In general, the architectural decisions tended to be controlled by a very small team or a single individual.

Architectural software patterns capture successful designs for recurring problems in software architecture. For the first time, a workshop in the tradition of the software-pattern conference series (e.g. PLoP, EuroPLoP) was held jointly with the European Conference on Software Architecture (ECSA 2014) in Vienna, Austria. The main objective of this workshop called MiniPLoP was to bring software architecture researchers closer to the pattern community and to introduce the writers' workshop format to them. Writers' workshop at PLoP conferences provide authors of pattern papers with high-density feedback given by peers within a limited timeframe. In addition, our workshop provided a forum to reect on the state of software architecture patterns and to discuss advances pattern research. This report contains an extended keynote abstract and summaries of the papers discussed during the workshop.

Software architecture is an important foundation of every software project. Therefore, it is advisable to evaluate it in early stages of the software design. Architecture evaluation helps to uncover risks and suboptimal decisions before they cause tremendous cost and re-engineering efforts. Unfortunately, many software companies still do not integrate architecture evaluations into their software projects as a standard activity. This is partially because architecture evaluation is perceived as complicated and time-consuming by some people. Modern agile development methodologies are perceived as avoiding up-front architectural design, which amplifies this problem. In this chapter, we present an extended description of the decision-centric architecture review (DCAR) method. DCAR is lightweight and easy to integrate into different types of software projects (traditional and agile projects). We present the method in detail and show how it can be used in an incremental development process. Additionally, we explain different approaches for integrating DCAR with Scrum to support continuous and iterative architecture evaluation. Finally, we present industrial experiences from the evaluations we carried out using DCAR, both as external reviewers in industrial projects and when applying DCAR in our own industrial software projects.

Architecture evaluation is an important activity in the software engineering life cycle that ensures that the architecture satisfies stakeholders' expectations. Additionally, risks and issues can be uncovered before they cause tremendous costs later in the life cycle. Unfortunately, architecture evaluation isn't regularly practiced in industry. This article presents DCAR (decision-centric architecture review), an architecture evaluation method that uses architecture decisions as first-class entities. DCAR uncovers and evaluates the rationale behind the most important architecture decisions, considering the entire context in which the decisions were made. Furthermore, it's lightweight and can be performed during or after the design is finalized. Experiences in large industrial projects have shown that full-scale DCAR evaluations, including reporting, can be conducted in fewer than five person-days, while producing satisfying results for the stakeholders.

Recent surveys show that 42% of Agile projects are successful. While this is three times better than traditional projects, 49% of Agile projects are late or over budget and 9% are total failures [1]. There is a better way to help Agile teams to implement Scrum. At the 2013 Scrum PLoP Conference held in Tisvildeleje, Denmark thought leaders in the Agile community reviewed a set of Scrum Patterns that together generate a high performing Scrum team. During this editorial process it became apparent that a combination of nine Patterns in conjunction with the Scrum framework could help teams achieve Hyper-Productivity, more than a 400% increase in velocity over a team's initial velocity.

Design and coding processes are an important part of an overall project methodology. However, perceptions of these processes influence how developers use them. A process perceived as desirable is more likely to be sustainable than one that is not. Test Driven Development has gained popularity in recent decades and we compared its perceived desirability with that of Clean room. Developers were given projects to complete using the processes and reported on their experience via a survey. Survey results were analyzed statistically to see if perceptions varied. No significant difference was discovered between the two processes in any of 5 subjective categories rated and developer comments indicated they would prefer a hybrid process. We recommend developers integrate ideas from both TDD and Clean room into their development processes.