As a software system grows in complexity, technology evolves, and organizations seek new opportunities, software architecture can become unsuitable for the problems it should help solve. This scenario calls for a software architecture revolution---an extensive and profound transformation of a system's core structures to align it with current and future requirements. This process is challenging and demands significant organizational resources, commitment, and effective guidance. While there is extensive research on the technical aspects of architectural changes, leadership dynamics in such initiatives are only sparsely discussed. Leaders play a pivotal role in this journey, advocating for the revolution, deciding priorities, negotiating resource allocation, assessing progress, implementing corrective actions, and showcasing achievements. Our previous work introduced a pattern language for leading software architecture revolutions. This paper expands that language, presenting a set of tactical prioritization patterns drawn from real-world experiences to enhance the effectiveness of architecture revolution initiatives.

Context: In an increasingly digitalized world with more complex supply chains, there is concern about the security of sharing information. To highlight the associated risk, companies carry out Information Security Risk Assessments (ISRAs), to measure the risk associated with sharing information with a third party. There are dozens of risk frameworks that are used as a basis for creating Information Security Risk Assessment forms. These forms, in most cases, are adapted to the reality of each company, generating a large number of questions that can be asked or topics that are priorities. This wide range of possibilities generates inefficiencies in the information security supplier management process. In addition, this makes it difficult to prioritize efforts on topics, that most contribute to increasing a company's information security maturity or the suitability of these companies to what the market demands. Problem: Companies do not have unlimited resources for investments in information security. Due to the increase in cybercrimes and consequently market demands, it is important that human and financial resources are directed to the themes and adjustments most required by the market. Current research on this topic is focused on comparing risky frameworks or trying to improve their efficiency, however, there is very little research about what the market is demanding. Method: In this work, a qualitative analysis was carried out on 5 information security risk assessment forms sent by multinational companies to a Brazilian healthcare operator. Atlas TI tool was used to identify the most recurrent themes. Results: The most relevant topics for the 5 companies evaluated are the existence of information security policies, incident prevention and response plans, adaptation to legislation and compliance, and ensuring the protection and privacy of data. The ISRA of the company in the financial sector was the one with the highest number of questions, which indicates greater maturity of this sector in terms of supplier management in information security topics.

Context: In an increasingly digitalized world with more complex supply chains, there is concern about the security of sharing information. To highlight the associated risk, companies carry out Information Security Risk Assessments (ISRAs), to measure the risk associated with sharing information with a third party. There are dozens of risk frameworks that are used as a basis for creating Information Security Risk Assessment forms. These forms, in most cases, are adapted to the reality of each company, generating a large number of questions that can be asked or topics that are priorities. This wide range of possibilities generates inefficiencies in the information security supplier management process. In addition, this makes it difficult to prioritize efforts on topics, that most contribute to increasing a company’s information security maturity or the suitability of these companies to what the market demands. Problem: Companies do not have unlimited resources for investments in information security. Due to the increase in cybercrimes and consequently market demands, it is important that human and financial resources are directed to the themes and adjustments most required by the market. Current research on this topic is focused on comparing risky frameworks or trying to improve their efficiency, however, there is very little research about what the market is demanding. Method: In this work, a qualitative analysis was carried out on 5 information security risk assessment forms sent by multinational companies to a Brazilian healthcare operator. Atlas TI tool was used to identify the most recurrent themes. Results: The most relevant topics for the 5 companies evaluated are the existence of information security policies, incident prevention and response plans, adaptation to legislation and compliance, and ensuring the protection and privacy of data. The ISRA of the company in the financial sector was the one with the highest number of questions, which indicates greater maturity of this sector in terms of supplier management in information security topics.

Software architecture revolution is the extensive and profound transformation of a software system's fundamental structures. It aims to enhance attributes such as scalability, availability, and maintainability or to enable the implementation of new requirements incompatible with the system's current capabilities. Undertaking an architectural revolution requires significant organizational effort and commitment, and effective leadership is crucial for its success. Despite the extensive research available on the technical aspects of architectural transformations, few studies focus on the leadership perspective. Leaders play a crucial role in championing the revolution initiative, prioritizing activities, negotiating resource allocation, evaluating outcomes, implementing corrective measures, and reporting accomplishments. This article builds up on our previous work and presents practical insights to describe effective strategic prioritization patterns for enhancing the effectiveness of architectural revolution initiatives.

Software architecture revolution can be defined as the process of making profound, large-scale changes to the fundamental structures of a software system to improve its attributes, such as availability, scalability, and maintainability, or to enable new requirements that are incompatible with the current capabilities. Architectural revolution usually demands substantial effort from the organization and thus depends on effective leadership to be successful. However, while there is plenty of research on the technical aspects of any architectural transformation, not much is available on the leadership perspective. The role of managers and other leaders include championing the revolution initiative, prioritizing activities, negotiating the allocation of people and resources, evaluating results, taking corrective actions, and reporting achievements. This paper draws from practical experiences to describe patterns to improve the effectiveness of architectural revolution initiatives.

ABSTRACTThis paper summarizes methods to group the large collection of Fearless Change patterns in a way that helps readers learn, understand, and use them. These include categories, illustrations, experiences, sequences, and scenarios. We present each of these with examples and explanations of how all five are valuable for learning the patterns and the relationships between them. Additionally, we conclude that sequences and scenarios hold the most promise for helping readers understand when and how to use the patterns together, especially when working with a large collection of patterns in a pattern language. The goal is to help authors of other pattern languages to consider how they may use these methods to add clarity for using their patterns.

During the initial stages of software development, the primary goal is to define precise and detailed requirements without concern for software realizations. Security constraints should be introduced then and must be based on the semantic aspects of applications, not on their software architectures, as it is the case in most secure development methodologies. In these stages, we need to identify threats as attacker goals and indicate what conceptual security defenses are needed to thwart these goals, without consideration of implementation details. We can consider the effects of threats on the application assets and try to find ways to stop them. These threats should be controlled with abstract security mechanisms that can be realized by abstract security patterns (ASPs) , that include only the core functions of these mechanisms, which must be present in every implementation of them. An abstract security pattern describes a conceptual security mechanism that includes functions able to stop or mitigate a threat or comply with a regulation or institutional policy. We describe here the properties of ASPs and present a detailed example. We relate ASPs to each other and to Security Solution Frames, which describe families of related patterns. We show how to include ASPs to secure an application, as well as how to derive concrete patterns from them. Finally, we discuss their practical value, including their use in “security by design” and IoT systems design.

Martin Fowler coined the term "Strangler Application" as a metaphor to describe a way of doing an evolutionary rewrite of a system, keeping it working while you evolve it. The main idea is to gradually create a new system around the edges of the old, letting it grow slowly over several years until the old system is strangled. The microservices architecture style has become very popular, and has been used to apply the strangler application to monolithic service-based systems. This paper describes different strategies (patterns) for applying the strangler application while evolving a monolith to use the microservices architecture style. The main ideas are: Wrap the monolith and protect services and system from change, Start Small and gradually evolve the system (baby steps), Pave the Road making microservices easier to create; Macroservice first then split to Microservice, Add new functionality as microservices, Extract Module / Component to Microservice, and Replace functionality with Microservice. As the system evolve it is common to Proxy Monolith Components and Add Façade to the microservices

Many have suggested using Domain-Driven Design (DDD) to help define the functional scope of microservices. But how to apply this idea in practice is not clear to everyone. DDD is a domain modeling technique created in the early 2000s. Microservices is an architecture style that became popular in 2015 as means to break software solutions into a set of independently deployed services. In this full-day tutorial we'll cover basic DDD concepts and discuss why and how DDD can help to create microservices with better availability, scalability, reliability, and modifiability. Using examples, we'll navigate from a domain model created using DDD to the design of both synchronous (REST-based) and asynchronous (reactive) microservices. We'll explore five different microservice design scenarios around DDD aggregates, bounded contexts (BC), domain events and other strategies for inter-BC interaction.

According to the extensive 50-year-old body of knowledge in object-oriented programming and design, good software designs are, among other characteristics, lowly coupled, highly cohesive, extensible, comprehensible, and not fragile. However, with the increased complexity and heterogeneity of contemporary software, this might not be enough. This paper discusses the practical challenges of object-oriented design in modern software development. We focus on three main challenges: (1) how technologies, frameworks, and architectures pressure developers to make design decisions that they would not take in an ideal scenario, (2) the complexity of current real-world problems require developers to devise not only a single, but several models for the same problem that live and interact together, and (3) how existing quality assessment techniques for object-oriented design should go beyond high-level metrics. Finally, we propose an agenda for future research that should be tackled by both scientists and practitioners soon. This paper is a call for arms for more reality-oriented research on the object-oriented software design field.

Here, we present a systematic literature review of mob programming. Mob programming is a new software development approach, a whole team (more than two people) works together on a code at the same time, in the same space, and on the same computer. The objective is to determine the current reported knowledge of mob programming. We searched two digital libraries, but only ten papers were found. These papers were analyzed and the benefits and risks of mob programming as well as the future research directions are discussed.

Modern software has become intricate and versatile due to the worldwide growth of new software technologies. In this regard, the evolution of software quality metrics to support software maintainability is studied. The impact of the Shuffler design pattern on software quality metrics is evaluated in this paper. The Shuffler design pattern provides an efficient design approach for shuffling. The pattern helps to choose generic shuffling alternatives that make the client program loosely coupled, and thus attaining high reusability. A few software quality metrics, which has a higher influence on software reusability and maintainability, are experimented on three gaming applications like Jigsaw, Poker, and Scramble. These gaming applications are redesigned using Shuffler design pattern and a combination of other patterns. The three software quality metrics, which show improvement on the redesigned applications, are McCabe Cyclomatic Complexity, Lack of Cohesion of Methods and Specialization Index. The authors also have tested the pattern with a reusability metrics suite, which measures the reusability of the black-box components of the aforementioned applications without any source code. The results with high cohesive and low coupling values would help software designers in the industry to be more confident in using the Shuffler pattern along with other design patterns. The interdependence of the three software metrics on the software quality attributes is finally tabulated to show their impact on software quality.

Handover of knowledge and responsibilities can cause problems when people transfer to other parts of a company or retire. Handover issues became apparent in Japan when many people from the Baby Boomer Generation retired simultaneously in 2007. In particular, this was a resounding issue in the software industry. Most business people are familiar with the concept of a handover. Although effective handovers are crucial for seamless business operations during personnel changes, the preferable elements for a handover are ambiguous. In this paper, we outline a “Pattern Language for Knowledge Handover when People Transition”. The pattern language consists of handover patterns. Actual handover patterns were pattern mined from our experience as well as from industrial interviews. We originally started with handover anti-patterns which identify actual problems for a handover. This led us to pattern mine the handover patterns that provide strategies to mitigate these problems. The examples are from software industry, but these patterns are applicable to other domains.

Mob programming is a whole team technique that includes programmers and others such as product owners or testers working together in the same space and time, discussing solutions and writing code in a fast succession on a shared screen and keyboard. This paper includes a literature review and case studies of Mob Programming in software development of three open source software in an academic setting. Aspects and practices involved in the Mob Programming are analyzed. The identification of common practices can serve as standards in the Mob Programming sessions. We carried out experiments with teams practicing this technique. The bond formed among the members were the strengths of the three teams experience. The noise from work in an open room irritated two members, but two members of the same team did not get bothered and was not a problem for the remaining ten other participants. The approval of Mob Programming was unanimous in each retrospective. Providing the infrastructure to use more computers could be useful for parallel searches when a task on the Mob Programming computer takes too long, or when the team needs learn new technologies. We conclude that improved the team learning.

The lifecycle of large software systems inevitably includes personnel changes. Most business people are familiar with the concept of a handover, but issues with handovers became apparent in Japan when many people from the Baby Boomer Generation retired simultaneously in 2007. Although effective handovers are crucial for seamless business operations during personnel changes, the preferable elements for a handover are ambiguous and not well researched, motivating our research. By analyzing anti-patterns, we note handover solution patterns to mitigate problems. However, our solution patterns may not be complete. Since our pattern language is familiar to many business people, we held workshops to find potential pattern seeds. The workshop participants suggested 22 new handover solution patterns. Three of which were suggested by multiple groups: Ability check, Pair working, and Matching the knowledge. Ability check evaluates the successor’s ability to prevent a handover failure due to lack of ability of the successor. Pair working is used to avoid handover altogether by assigning more than two people to the same job. Matching the knowledge avoids misunderstanding knowledge by successor by filling up the gaps between predecessor's explanation and successor's understanding

To achieve quality systems and products, it is vital to enable and infuse quality work throughout the entire process, rather than piling it on at the end. Thus paying attention to when to this, how to do this, and who is involved can increase quality. This paper presents three patterns from the collection of patterns on being agile at quality: System Quality Specialist, Spread the Quality Workload, and Automate As You Go. System Quality Specialists can define, test, and implement system-quality characteristics that are complex or require specialized skills and expertise to get right. Spreading the Quality Workload throughout the development process keeps the team from being overly burdened with quality-related work at any point in time. Automating First enables teams to streamline their build and testing processes, eliminate tedious or mundane tasks, and allow more time for team members to focus on implementing and testing important system qualities.

In 2007 issues with handovers became apparent in Japan, when many people from the Baby Boomer Generation retired simultaneously. Most business people are familiar with the concept of a handover. Although effective handovers are crucial for seamless business operations during personnel changes, the preferable elements for a handover are ambiguous and not well researched. This motivated us to examine this topic. We held a workshop on handovers to assess actual problems due to undesirable handovers. The results were used to elucidate three handover anti-patterns, which identify concrete problems of handovers. To mitigate the problems, we found handover solution patterns by analyzing three anti-patterns. In this paper, we introduce three solution patterns: Spread of knowledge, Handover in a different room and Firewall for the handover. The predecessor prepares to handover by Spreading the knowledge about the system to the third parties in the preparation phase. This lets the predecessor ensure the important knowledge to be remained in their organization. The predecessor and the successor move to a different room during their handover. This helps to the predecessor and the successor concentrating on the handover. Firewall for handover is used by the third party to protect the predecessor from the job responsibilities which still need to be performed during the handover. The third party stands in for the predecessor to support the handover. Herein, we outline the handover solution patterns more detail.

A Pattern Writer's Workshop (WW) is a peer-review method to improve pattern or pattern language papers. However, several problems may arise, leading to "ad hoc" review meetings where patterns are not systematically reviewed and authors do not receive useful feedback. Previously, we considered Checklist-based Reading (CBR) and Perspective-based Reading (PBR), which are techniques to improve ad hoc reviews, but some deficiencies were noted. In our focus group, we organized a mini WW using these technique and results are summarized in this paper.

A Pattern Writer's Workshop (WW) is a peer-review method to improve pattern or pattern language papers. However, several problems may arise, leading to "ad hoc" review meetings where patterns are not systematically reviewed and authors do not receive useful feedback. Previously, we considered Checklist-based Reading (CBR) and Perspective-based Reading (PBR), which are techniques to improve ad hoc reviews, but some deficiencies were noted. In this paper, we propose an approach to improve WWs by providing a two-level checklist and refining perspectives for reviewing patterns. An experiment shows the strengths and weaknesses of this new approach.

As organizations transition to agile processes, Quality Assurance (QA) activities and attention to system quality need to evolve along with the evolution of development practices. Agile quality teams incrementally deliver working software while ensuring that important system qualities are also addressed. In order to pay appropriate attention to system qualities, they need to be visible and included as part of the prioritized work. This paper presents patterns for identifying system qualities and including them on the project roadmap, adding quality-related work items to the project backlog, and creating a quality radiator that communicates the status and goals for delivering system qualities.