@inbook {sa:2023:education, title = {A Better Way to Teach Software Architecture}, year = {2023}, pages = {101 - 110}, publisher = {Springer}, organization = {Springer}, abstract = {Software architecture education is a weak spot in many undergraduate programs in computer science and software engineering. While the concepts and practices used by software architects in industry are rich and varied, transferring this expertise into a university classroom has proved problematic. Bridging the gap between industry and academia requires ongoing, often heroic, effort. This is a {\textquotedblleft}chicken and egg{\textquotedblright} problem: Because there is a lack of good teaching materials, architecture is seldom taught, and because it is seldom taught, there has been little incentive to create good materials. We would like to change that. Our goal is to establish guidelines for how software architecture practices should be taught{\textemdash}both technical and non-technical topics{\textemdash}and to suggest appropriate teaching methods to best prepare students to be software architects in practice.}, keywords = {software architecture}, isbn = {978-3-031-36846-2}, doi = {10.1007/978-3-031-36847-9_6}, url = {https://link.springer.com/10.1007/978-3-031-36847-9_6}, author = {Kazman, Rick and Cai, Yuanfang and Godfrey, Michael W. and Cesare Pautasso and Liu, Anna}, editor = {Pelliccione, Patrizio and Kazman, Rick and Weber, Ingo and Liu, Anna} } @inbook {sa:2023:empirical, title = {An Empirical Basis for Software Architecture Research}, booktitle = { Software Architecture - Research Roadmaps from the Community }, year = {2023}, pages = {87 - 100}, publisher = {Springer}, organization = {Springer}, abstract = {Despite the clear need for and importance of performing empirical studies as part of software architecture research, there is still a lack of curated, standardized, clean, well-maintained, documented, easily accessible, reusable, and shared datasets. In this chapter, we provide an overview of the problems, of the motivations, and of the opportunities currently related to mining and sharing datasets for researchers in software architecture. We first explore and describe which artifacts should be included into such datasets, such as code, documentation, and requirements, but also including other architecturally relevant artifacts, such as architectural decision records, models, and other kinds of documentation. This information can be complemented with revision history logs, social metadata, and email or chat discussion archives. The availability of such datasets would enable not only architectural reconstruction studies but would also help to catalyze broader and more ambitious program of empirical studies in software architecture research.}, keywords = {software architecture}, isbn = {978-3-031-36846-2}, doi = {10.1007/978-3-031-36847-9_5}, url = {https://link.springer.com/chapter/10.1007/978-3-031-36847-9_5}, author = {Rick Kazman and Roberto Tonelli and Cesare Pautasso}, editor = {Pelliccione, Patrizio and Kazman, Rick and Weber, Ingo and Liu, Anna} } @conference {2022:sose:ccc, title = {Cargo-Cult Containerization: A Critical View of Containers in Modern Software Development}, booktitle = {16th International Conference on Service-Oriented System Engineering (SOSE 2022)}, year = {2022}, month = {August}, publisher = {IEEE}, organization = {IEEE}, address = {San Francisco, USA}, abstract = {Software is increasingly developed and deployed using containers. While the concept of a container is conceptually straightforward, there are various issues to be considered while using them, ranging from technical details inside containers to the orchestration of containers that jointly form a meaningful application. In recent years, the use of containers has become so prevalent that developers have a tendency to resort to cargo-cult containerization {\textendash} ritual adherence to the use of containers just because so many others are doing the same thing. In this paper, we study advantages and downsides of containers in modern- day software development. We foresee the use of containers to spread into new areas, including IoT systems and embedded devices. At the same time, we caution against indiscriminate use of containers, since excessive containerization can have adverse impacts on software maintenance and overall complexity of a system architecture.}, keywords = {containers, software architecture}, author = {Tommi Mikkonen and Cesare Pautasso and Kari Systa and Antero Taivalsaari} } @book {bapis2021, title = {Beautiful APIs}, year = {2021}, publisher = {LeanPub}, organization = {LeanPub}, abstract = {This book presents the catalog of a virtual exhibition featuring the structural visualizations of 93 Web APIs of different sizes and shapes. The diagrams are drawn based on the exact API specification found on some open source repository. While there are many books on how to design good APIs, the goal of this book is to show a small sample of actual API designs. There is a lot that can be learned from them. All APIs represented are Web APIs: they come from the time when many attempted with very different results to use the HTTP protocol to remotely invoke software delivered as a service. The APIs have been selected mainly due to their visual appearance.}, keywords = {API visualization, software architecture}, url = {https://leanpub.com/beautiful-apis/}, author = {Cesare Pautasso} } @conference {2021:icwe:fullstack, title = {Full Stack is Not What It Used to Be}, booktitle = {21st International Conference on Web Engineering (ICWE2021)}, year = {2021}, month = {May}, publisher = {Springer}, organization = {Springer}, address = {Biarritz, France}, abstract = {The traditional definition of full stack development refers to a skill set that is required for writing software both for the frontend and backend of a web application or site. In recent years, the scope of full stack development has expanded significantly, though. Today, a full stack software developer is assumed to master various additional areas especially related to cloud infrastructure and deployment, message brokers and data analytics technologies. In addition, the emergence of Internet of Things (IoT) and the rapidly spreading use of AI/ML technologies are introducing additional skill set requirements. In this paper, we discuss the expectations for a modern full stack developer based on our industry observations, and argue that these expectations have significant implications for software and web engineering education.}, keywords = {Cloud, Education, Internet of Things, IoT, Programmable World, software architecture, software engineering, Web engineering}, doi = {10.1007/978-3-030-74296-6_28}, author = {Antero Taivalsaari and Tommi Mikkonen and Cesare Pautasso and Kari Systa} } @inbook {2021:icwe:liquid, title = {Towards Seamless IoT Device-Edge-Cloud Continuum}, booktitle = {Communications in Computer and Information Science}, volume = {1508}, number = {ICWE 2021 Workshops}, year = {2021}, pages = {82 - 98}, publisher = {Springer}, organization = {Springer}, abstract = {In this paper we revisit a taxonomy of client-side IoT software architectures that we presented a few years ago. We note that the emergence of inexpensive AI/ML hardware and new communication technologies are broadening the architectural options for IoT devices even further. These options can have a significant impact on the overall end-to-end architecture and topology of IoT systems, e.g., in determining how much computation can be performed on the edge of the network. We study the implications of the IoT device architecture choices in light of the new observations, as well as make some new predictions about future directions. Additionally, we make a case for isomorphic IoT systems in which development complexity is alleviated with consistent use of technologies across the entire stack, providing a seamless continuum from edge devices all the way to the cloud.}, keywords = {Edge Computing, Embedded devices, Internet of Things, Isomorphic software, liquid software, Programmable World, software architecture, software engineering}, isbn = {978-3-030-92230-6}, issn = {1865-0929}, doi = {10.1007/978-3-030-92231-3_8}, url = {https://link.springer.com/chapter/10.1007/978-3-030-92231-3_8}, author = {Taivalsaari, Antero and Mikkonen, Tommi and Pautasso, Cesare} } @book {book:sa, title = {Software Architecture: visual lecture notes}, year = {2020}, publisher = {LeanPub}, organization = {LeanPub}, abstract = {From quality attributes to how to design and model components, interfaces, connectors, containers, all the way to services and microservices. These are the revised and illustrated notes of the Software Architecture lecture of the Master in Software and Data Engineering held at the Software Institute at USI Lugano, Switzerland during the Spring of 2020. The book includes the script for these lectures:
  1. Introduction
  2. Quality Attributes
  3. Definitions
  4. Modeling Software Architecture
  5. Modularity and Components
  6. Reusability and Interfaces
  7. Composability and Connectors
  8. Compatibility and Coupling
  9. Deployability, Portability and Containers
  10. Scalability
  11. Availability and Services
  12. Flexibility and Microservices
}, keywords = {software architecture}, url = {https://leanpub.com/software-architecture/}, author = {Cesare Pautasso} } @article {2018:ieeesw, title = {The Web as a Software Connector: Integration Resting on Linked Resources}, journal = {IEEE Software}, volume = {35}, year = {2018}, month = {January/February}, pages = {93 - 98}, abstract = {The web, seen as a graph of linked resources shared between microservices, can serve as an integration style. It offers unique characteristics and possibilities regarding dataflow, control flow, and other qualities, compared to file transfer, shared databases, remote procedure calls, and asynchronous messaging. Carrying these insights in your toolbox will make you aware of all the options to consider next time you build loosely coupled integrated systems.}, keywords = {coupling, REST, software architecture}, doi = {10.1109/MS.2017.4541049}, url = {http://ieeexplore.ieee.org/document/8239944/}, author = {Cesare Pautasso and Olaf Zimmermann} } @article {2017:jwe:liquid, title = {Architecting Liquid Software}, journal = {Journal of Web Engineering}, volume = {16}, year = {2017}, month = {September}, pages = {433-470}, abstract = {The Liquid Software metaphor refers to software that can operate seamlessly across multiple devices owned by one or multiple users. Liquid software applications can take advantage of the computing, storage and communication resources available on all the devices owned by the user. Liquid software applications can also dynamically migrate from one device to another, following the user{\textquoteright}s attention and usage context. The key design goal in Liquid Software development is to minimize the additional efforts arising from multiple device ownership (e.g., installation, synchronization and general maintenance of personal computers, smartphones, tablets, home and car displays, and wearable devices), while keeping the users in full control of their devices, applications and data. In this paper we present the design space for Liquid Software, categorizing and discussing the most important architectural dimensions and technical choices. We also provide an introduction and comparison of two frameworks implementing Liquid Software capabilities in the context of the World Wide Web. }, keywords = {design space, liquid software, multi-device programming, software architecture}, doi = {10.26421/JWE16.5-6}, url = {http://www.rintonpress.com/journals/jweonline.html$\#$v16n56}, author = {Andrea Gallidabino and Cesare Pautasso and Tommi Mikkonen and Kari Systa and Jari-Pekka Voutilainen and Antero Taivalsaari} } @conference {2017:icsa:blockchain, title = {A Taxonomy of Blockchain-based Systems for Architecture Design}, booktitle = {1st IEEE International Conference on Software Architecture (ICSA 2017)}, year = {2017}, month = {April}, publisher = {IEEE}, organization = {IEEE}, address = {Gothenburg, Sweden}, abstract = {Blockchain is an emerging technology for decentralised and transactional data sharing across a large network of untrusted participants. It enables new forms of distributed software architectures, where agreement on shared states can be established without trusting a central integration point. A major difficulty for architects designing applications based on blockchain is that the technology has many configurations and variants. Since blockchains are at an early stage, there is little product data or reliable technology evaluation available to compare different blockchains. In this paper, we propose how to classify and compare blockchains and blockchain-based systems to assist with the design and assessment of their impact on software architectures. Our taxonomy captures major architectural characteristics of blockchains and the impact of their principal design decisions. This taxonomy is intended to help with important architectural considerations about the performance and quality attributes of blockchain-based systems.}, keywords = {blockchain, software architecture}, author = {Xiwei Xu and Ingo Weber and Liming Zhu and Mark Staples and Jan Bosch and Len Bass and Cesare Pautasso and Paul Rimba} } @inproceedings {saw:2011:shark, title = {Goals, questions and metrics for architectural decision models}, year = {2011}, month = {May}, pages = {21{\textendash}28}, publisher = {ACM}, address = {Waikiki, Hawaii, USA}, abstract = {Architectural decisions are the key element behind the design process leading to a software architecture. Making software architects aware of the implications of their decisions is only the beginning of what can be achieved by capturing the rationale and the constraints influencing the decision making process in a reusable body of architectural knowledge. In this paper we propose a metric-based approach to the analysis of architectural decision models. Using a hierarchically-structured approach we identify a number of useful goals and stakeholders involved in the architectural design process. Next, we sketch a set of metrics to provide data for the evaluation of the aforementioned goals. Our aim is to stimulate a discussion on how to find indicators relevant for software architects by measuring the intrinsic properties of architectural knowledge.}, keywords = {architectural decision modeling, metrics, SAW, software architecture, visualization}, isbn = {978-1-4503-0596-9}, doi = {10.1145/1988676.1988682}, author = {Marcin Nowak and Cesare Pautasso} } @inproceedings {clavos:2009:pesos, title = {Embedding continuous lifelong verification in service life cycles}, year = {2009}, month = {May}, pages = {99-102}, address = {Vancouver, Canada}, abstract = {Service-oriented systems are an instantiation of open world software, which is characterized by high dynamism and decentralization. These properties strongly impact on how service-oriented systems are engineered, built, and operated, as well as verified. To address the challenges of applying verification to open service-oriented systems, in this position paper we propose to apply verification across the entire life cycle of a service and introduce a verification-oriented service life cycle.}, keywords = {continuous lifelong verification, formal verification, monitoring, service contracts, service life cycles, service-oriented systems, software architecture, software engineering}, doi = {10.1109/PESOS.2009.5068828}, author = {Domenico Bianculli and Carlo Ghezzi and Cesare Pautasso} }