The state of micro frontends:challenges of applying and adopting client-side microservices

Abstract. Software development had been around for centuries and the need to provide the right techniques for delivering it, it’s indispensable as the market is growing fast. Many companies have adapted microservices as a transition from monolithic backend applications. While the microservice approach solved various issues present in backend applications, frontend architecture is still composed as a monolithic application. Issues arise as the frontend application increases in scale and become difficult to maintain. This study aims to give an introduction to micro frontend architecture as a technique of solving different issues present in frontend development. It will analyze how the micro frontend approach is perceived by developers with different levels of experience compared to a more traditional approach of developing monolithic frontend application, single page application. To provide answers for the question, we compared the performance of 6 developers with different levels of experience that architectured and implemented a simple frontend application using single page application and micro frontend. The results showed that developers’ experience mattered while developing single page application as the approach was perceived as easy. On the micro frontend counterpart, having previous experience with setting up micro frontend applications had a major impact on the perceived difficulty. Although the perceived difficulty of micro frontend remains higher compared to single page application, developers shared the same consent for using the micro frontend approach for large-scale applications

On Making Architecturally Significant Decisions in Agile Development : Case Study

Päätöksenteko on tärkeä osa ohjelmistokehitystä erityisesti kun kyse on ohjelmistoarkkitehtuurista. Ohjelmistoarkkitehtuuri voidaan jopa ajatella joukkona arkkitehtuurisia päätöksiä. Päätöksenteko vaikuttaa siis hyvin paljon siihen millaiseksi ohjelmistoarkkitehtuuri muodostuu. Tämä tutkielma tutkii arkkitehtuurista päätöksentoa ohjelmistokehitysprojektiin liittyen. Tämä tutkielma esittää tapaustutkimuksen tulokset, joiden pääasiallisena lähteenä on ollut haastattelut. Tapaustutkimuksen tapaus on yksittäinen tapaus, joka tehtiin alihankitun ohjelmistokehitysprojektin aikana. Päätökseen liittyy ohjelmistokehitystiimi ja useita sidosryhmiä asiakkaan puolelta, mukaanlukien arkkitehtejä. Ohjelmistokehitystiimi reagoi nopeasti päätöksen tarpeellisuuteen kun tarve nousi esille projektin aikana. Suurin osa päätöksentekoon liittyvästä työstä tehtiin ketterän ohjelmistokehityksen lomassa sujuvasti. Vain lopullinen päätös asiakkaalta tapahtui erillään ohjelmistokehitysprosessista. Tämä viimeinen hyväksyntä annettiin vasta jälkeenpäin, kun päätös oli jo käytännössä päätetty ja implementoitu. Tämä kuvaa hyvin kuinka vaikeaa on yhdistää ohjelmistokehityksen ulkopuolista päätöksentekoa ohjelmistokehitysprosessiin tehokkaasti. Tämän tutkimuksen tapauksessa päätöksenteossa oli työnjako, jossa yksi henkilö tutki ja valmisteli päätöksen. Tämän henkilön työ muodosti suurimman osan tehdystä työstä päätökseen liittyen. Tämän tyyppinen työnjako voisi mahdollisesti olla yleistettävissä päätöksentekoon yleisesti ohjelmistokehityksen piirissä.Decision-making is an important part of all of software development. This is especially true in the context of software architecture. Software architecture can even be thought of as a set of architectural decisions. Decision-making therefore plays a large part in influencing the architecture of a system. This thesis studies architecturally significant decision-making in the context of a software development project. This thesis presents the results of a case study where the primary source of data was interviews. The case is a single decision made in the middle of a subcontracted project. It involves the development team and several stakeholders from the client, including architects. The decision was handled quickly by the development team when an acute need for a decision arose. The work relating to the decision-making was mostly done within the agile development process used by the development team. Only the final approval from the client was done outside the development process. This final approval was given after the decision was already decided in practise and an implementation based on it was built. This illustrates how difficult it is to incorporate outside decision-making into software development. The decision-making also had a division of labour where one person did the researching and preparing of the the decision. This constituted most of the work done relating to the decision. This type of division of labour may perhaps be generalized further into other decision-making elsewhere within software development generally

Recognising object-oriented software design quality : a practitioner-based questionnaire survey

Design quality is vital if software is to be maintainable. What practices do developers actually use to achieve design quality in their day-to-day work and which of these do they find most useful? To discover the extent to which practitioners concern themselves with object-oriented design quality and the approaches used when determining quality in practice, a questionnaire survey of 102 software practitioners, approximately half from the UK and the remainder from elsewhere around the world was used. Individual and peer experience are major contributors to design quality. Classic design guidelines, well-known lower level practices, tools and metrics all can also contribute positively to design quality. There is a potential relationship between testing practices and design quality. Inexperience, time pressures, novel problems, novel technology, and imprecise or changing requirements may have a negative impact on quality. Respondents with most experience are more confident in their design decisions, place more value on reviews by team leads and are more likely to rate design quality as very important. For practitioners, these results identify the techniques and tools that other practitioners find effective. For researchers, the results highlight a need for more work investigating the role of experience in the design process and the contribution experience makes to quality. There is also the potential for more in-depth studies of how practitioners are actually using design guidance, including Clean Code. Lastly, the potential relationship between testing practices and design quality merits further investigation

Eristämismekanismeja selainpohjaisille ohjelmistoarkkitehtuureille

Traditional backend-oriented web applications are increasingly being replaced by frontend applications, which execute directly in the user's browser. Web application performance has been shown to directly affect business performance, and frontend applications enable unique performance improvements. However, building complex applications within the browser is still a new and poorly understood field, and engineering efforts within the field are often plagued by quality issues. This thesis addresses the current research gap around frontend applications, by investigating the applicability of isolation mechanisms available in browsers to frontend application architecture. We review the important publications around the topic, forming an overview of current research, and current best practices in the field. We use this understanding, combined with relevant industry experience, to categorize the available isolation mechanisms to four classes: state and variable isolation, isolation from the DOM, isolation within the DOM, and execution isolation. For each class, we provide background and concrete examples on both the related quality issues, as well as tools for their mitigation. Finally, we use the ISO 25010 quality standard to evaluate the impact of these isolation mechanisms on frontend application quality. Our results suggest that the application of the previously introduced isolation mechanisms has the potential to significantly improve several key areas of frontend application quality, most importantly compatibility and maintainability, but also performance and security. Many of these mechanisms also imply tradeoffs between other quality attributes, most commonly performance. Future work could include developing frontend application architectures that leverage these isolation mechanisms to their full potential.Perinteisiä palvelinorientoituneita verkko-ohjelmistoja korvataan kiihtyvällä vauhdilla selainpohjaisilla ohjelmistoilla. Verkko-ohjelmistojen suorituskyvyn on osoitettu vaikuttavan suoraan yritysten tulokseen, ja selainpohjaiset ohjelmistot mahdollistavat huomattavia parannuksia suorituskykyyn. Monimutkaisten selainpohjaisten ohjelmistojen rakentaminen on kuitenkin uusi ja huonosti ymmärretty ala, ja sillä tapahtuva kehitystyö on ollut laatuongelmien piinaamaa. Tässä diplomityössä täydennetään puutteellista tutkimusta selainpohjaisista ohjelmistoista tutkimalla selaimista löytyvien eristysmekanismien soveltuvuutta näiden ohjelmistojen arkkitehtuurin parantamiseen. Käymme läpi tärkeimmät alan julkaisut muodostaen yleiskuvan tutkimuksen tilasta ja parhaiksi katsotuista käytännöistä alan harjoittajien keskuudessa. Yhdistämällä kirjallisuuskatsauksen tulokset omaan työkokemukseemme alalta, luokittelemme selainten käytettävissä olevat eristysmekanismit neljään kategoriaan: tilan ja muuttujien eristäminen, eristäminen DOM:ista, eristäminen DOM:in sisällä sekä suorituksen eristäminen. Käsittelemme tämän jälkeen löydetyt kategoriat sekä esitämme niihin liittyviä konkreettisia laatuongelmia sekä työkaluja näiden ongelmien ratkaisuun. Lopuksi arvioimme näiden eristysmekanismien vaikutusta selainpohjaisten ohjelmistojen laatuun ISO 25010 -laatustandardin avulla. Tuloksemme osoittavat että työssä esitettyjen eristysmekanismien käyttö saattaisi parantaa ohjelmistojen laatua usealla tärkeällä alueella. Näistä merkittävimpiä ovat yhteensopivuus ja ylläpidettävyys, mutta hyötyjä voitaisiin saada myös suorituskyvyn sekä tietoturvan parantumisella. Toisaalta monet esitellyistä mekanismeista myös vaativat kompromisseja muiden laatuvaatimusten osalta. Jatkotutkimusta tarvittaisiin selainpohjaisista arkkitehtuureista, jotka hyödyntäisivät paremmin työssä esitettyjä eristysmekanismeja

A meshing tool product line architecture

Meshing tools are extremely complex pieces of software. Traditionally, they have been built in a one by one basis, without systematically reusing already developed parts. The area has matured so that we can currently think of building meshing tools in a more industrial manner. Software product lines is a trend in software development that promotes systematic reuse. We propose a layered product line architecture for meshing tools that can be instantiated with different algorithms, ways of implementing basic concepts, and even for two or three dimensional meshing tools. We specify it formally using xADL and we show that the architecture is compatible with a series of already built tools. This work is the beginning of a domain analysis that has the potential to go beyond the sometimes rigid descriptions provided by architectural description languages.1st International Workshop on Advanced Software Engineering: Expanding the Frontiers of Software Technology - Session 1: Software ArchitectureRed de Universidades con Carreras en Informática (RedUNCI

O Paradigma "Code Push-Down"

A SAP é um dos maiores e mais bem-conceituados fornecedores de sistemas ERP. Tal como a maioria dos sistemas ERP, estes também têm estado em constante evolução. Desde a disponibilização da sua base de dados SAP High-Speed Analytical Appliance (HANA), a SAP tem tentado persuadir os seus clientes a adotar esta base de dados. Em 2018, a SAP anunciou que iria acabar o suporte do seu ERP, SAP ECC, favorecendo a adoção do seu novo ERP, SAP S/4 HANA, que apenas suporta o uso de bases de dados SAP HANA. O suporte estava previsto acabar em 2025, no entanto foi adiado para 2027 a pedido dos seus clientes. O fim deste suporte significa que uma porção significativa dos clientes da SAP irão migrar para o ERP SAP S/4 HANA (+ SAP HANA) e, como recomendado pela SAP, provavelmente também irão adotar o paradigma de desenvolvimento “Code Push-Down”, que se foca em empurrar lógica aplicacional para a camada/nível da base de dados. Apesar desta mudança no paradigma de desenvolvimento poder, supostamente, trazer benefícios significativos de desempenho, também pode ter consequências no que toca às outras qualidades do software desenvolvido. Este trabalho tem como objetivo analisar o paradigma de desenvolvimento “Code PushDown”, descobrir possíveis desvantagens/limitações e tentar elaborar um guião geral de como aplicar o paradigma de forma a tentar mitigá-las. E talvez, ao suceder nos seus objetivos, também incentivar a realização de mais trabalhos sobre o tema.SAP is one of the biggest and most well-established ERP system providers. Like most ERP systems, their ERP systems and surrounding ecosystems have been in constant evolution. Since the introduction of their SAP High-Speed Analytical Appliance (HANA) database, they have been pushing their clients towards its adoption. In 2018, they announced the end of support for their SAP ECC ERP in favor of the new SAP S/4 HANA ERP, which only supports SAP HANA. This end of support was to take place in 2025 but, due to requests by their customers, it has since been extended to 2027. This end of support means a significant portion of SAP’s clients are migrating to SAP S/4 HANA (+ SAP HANA) and, as recommended by SAP, will most likely also adopt their “Code PushDown” development paradigm, which is based around pushing application logic down to the database tier/layer. Although this shift in development paradigms can, supposedly, bring significant gains in performance, it may also have consequences when it comes to other qualities of the developed software. This work aims to analyze the “Code Push-Down” development paradigm, discover possible downsides/tradeoffs and try to provide general guidelines on how to apply it in order to possibly mitigate them. And perhaps, by succeeding in meeting the objectives, to incentivize further work about this topic

A Lean Enterprise Architecture Approach as an Enabler for Organizational Agility : Case: Metso Outotec

In the era where delivery speed is perceived more important than IT landscape integration, consistency and long-term planning, different architectural approaches have become important considerations of information systems management. Moreover, recent studies have shown that the need for a holistic EA is often overlooked, when organizations try to apply agile development models, which may lead to several problems, such as technical debt, redundant rework, inconsistent communication, decentralized and siloed architecture design, unsustainable architecture, and inconsistence in coding style. Hence, with the growing deployment of scaling agile methods there is a need for purpose-fit approaches to integrate EA frameworks to enable organization agility while maintaining long-term vision. This study aims to explore how EA activities are put into practices in a company deploying large-scale agile development methods – namely EA deliverables, EA benefits, EA concerns and EA enablers. In total, 13 semi-structured interviews were conducted from a case company, and an analysis was done using the Gioia method. As a result, EA deliverables (business objective deliverables, intentional architecture deliverables, and emergent design deliverables), EA benefits (organizational agility and organizational robustness), EA concerns (immaturity, disengagement, urgency, and resistance and anti-patterns), and EA enablers (communication and collaboration, Lean EA, and EA culture) were identified. The enterprise architecture practices used by the case company were in line with the guidelines and best practices recommended by the literature and industry experts. Moreover, a literature review provided some theoretical constructs and suggestions, namely the Lean EA development (LEAD) method and the design principles of architectural thinking for supporting organizational agility, which can be recommended to be applied by the case company or any other organization scaling agile