Jaap Kabbedijk

Steering Insight: An Exploration of the Ruby Software Ecosystem

Software products are part of a larger network of products, suppliers and partners, called a software ecosystem, working together in order to provide functionality for the users and generate profit for the vendors. Not much is known about the characteristics and relationships within such a software ecosystem. This paper presents an overview of the open source Ruby ecosystem and lists its elements, characteristics, descriptives, roles, cliques and relationships. Data is gathered using the Git decentralized source code management system and is analyzed using social network and statistical analysis techniques. Our analysis shows that the Ruby ecosystem exists out of a couple very distinctive roles developers fulfil. It also shows that within the Ruby ecosystem only a small ‘core’ of approximately 10% of all developers and gems (Ruby packages) are dominant within the ecosystem. At this point in time it appears that the rails community would benefit from motivating current developers to work together more, instead of supporting new developers or gems in order to get a healthy ecosystem.

Customer Involvement in Requirements Management: Lessons from Mass Market Software Development

Product software vendors are regularly challenged with identifying and selecting the requirements of upcoming product releases. Companies struggle to involve their customers and have a hard time selecting the right requirements from the enormous number of candidate requirements. This paper presents a practical approach to overcome these problems by including customers in the requirements management process through different types of involvement. The presented case illustrates how software requirements are gathered from customers, by involving them on three different levels. Based on the industrial experiences we present six lessons from customer involvement in large scale requirements management.

Variability in multi-tenant environments: architectural design patterns from industry

In order to serve a lot of different customers in a SaaS environment, software vendors have to comply to a range of different varying requirements in their software product. Because of these varying requirements and the large number of customers, a variable multitenant solution is needed to achieve this goal. This paper gives a pragmatic approach to the concepts of multi-tenancy and variability in SaaS environments and proposes three architectural patterns that support variability in multi-tenant SaaS environments. The Customizable Data Views pattern, the Module Dependent Menu pattern and the Pre/Post Update Hooks pattern are explained and shown as good practices for applying variability in a multi-tenant SaaS environment. All patterns are based on case studies performed at two large software vendors in the Netherlands who are offering an ERP software product as a service.

Defining multi-tenancy

HighlightsWe analyzed the academic and industrial perspective on multi-tenancy.No different interpretation of multi-tenancy exists between academia and industry.A different interpretation of multi-tenancy exists within academia and industry.We provide an overall definition for the concept of multi-tenancy.We provide seven future research themes for multi-tenancy. Software as a service is frequently offered in a multi-tenant style, where customers of the application and their end-users share resources such as software and hardware among all users, without necessarily sharing data. It is surprising that, with such a popular paradigm, little agreement exists with regard to the definition, domain, and challenges of multi-tenancy. This absence is detrimental to the research community and the industry, as it hampers progress in the domain of multi-tenancy and enables organizations and academics to wield their own definitions to further their commercial or research agendas.In this article, a systematic mapping study on multi-tenancy is described in which 761 academic papers and 371 industrial blogs are analysed. Both the industrial and academic perspective are assessed, in order to get a complete overview. The definition and topic maps provide a comprehensive overview of the domain, while the research agenda, listing four important research topics, provides a roadmap for future research efforts.

A case study of the variability consequences of the CQRS pattern in online business software

In order to maximize their customer base, business software vendors are trying to offer software products that support the business needs of as many customers as possible. The more standardized a software product is, the easier it will be to serve large numbers of uniform customers. However, if customers are not homogeneous, a trade-off must be made between flexibility and complexity. A case study is presented showing the implementation of the Command Query Responsibility Pattern (CQRS), a pattern dictating the strict separation between commands and queries. The study was performed at a large software product vendor currently designing a software product based on CQRS. Seven sub patterns related to CQRS are identified and discussed. The research results show the CQRS pattern is implemented and how its different sub patterns can result in a high level of variability within a software product and how the different sub patterns can interact to achieve this.

The role of variability patterns in multi-tenant business software

Within the business software domain it is crucial for a software vendor to comply to different customer requirements. Traditionally this could be done by offering different products to different customers, but because multi-tenant business software deployments use one software product to serve all customers, this is no longer possible. Software vendors have to make sure that one instance of a software product is variable enough to support all different requirements from all different customers. This ability is defined as tenant-based variability. Within this paper a conceptual model is presented, explaining the role software patterns play in solving variability implementation problems in multi-tenant business software. Different important aspects of patterns are explained, like forces and consequences and are linked to concepts in the problem domain. The paper suggests that variability patterns play a large role in addressing variability in multi-tenant business software and provide a valuable vocabulary for researching, reporting, thinking and communicating about variability solutions in online software products.

Exploring factors affecting decision outcome and lead time in large-scale requirements engineering

Lead time, defined as the duration between the moment a request was filed and the moment the decision was made, is an important aspect of decision making in market‐driven requirements engineering. Minimizing lead time allows software companies to focus their resources on the most profitable functionality and enables them to remain competitive within the quickly changing software market. Achieving and sustaining low decision lead time and the resulting high decision efficiency require a better understanding of factors that may affect both decision lead time and outcome. In order to identify possible factors, we conducted an exploratory two‐stage case study that combines the statistical analysis of seven possible relationships among decision characteristics at a large company with a survey of industry participants. Our results show that the number of products affected by a decision increases the time needed to make a decision. Practitioners should take this aspect into consideration when planning for efficient decision making and possibly reducing the complexity of decisions. Our results also show that when a change request originates from an important customer, the request is more often accepted. The results provide input into the discussion of whether a large company should focus on only a few of its large customers and disregard its significantly larger group of small customers. The results provide valuable insights for researchers, who can use them to plan research of decision‐making processes and methods, and for practitioners, who can use them to optimize their decision‐making processes. In future work, we plan to investigate other decision characteristics, such as the number of stakeholders involved in the discussion about the potential change or the number of dependencies between software components. Copyright

Multi-tenant Architecture Comparison

Software architects struggle to choose an adequate architectural style for multi-tenant software systems. Bad choices result in poor performance, low scalability, limited flexibility, and obstruct software evolution. We present a comparison of 12 Multi-Tenant Architecture (MTA) patterns that supports architects in choosing the most suitable architectural pattern, using 17 assessment criteria. Both patterns and criteria were evaluated by domain experts. Five architecture assessment rules of thumb are presented in the paper, aimed at making fast and efficient design decisions. The comparison provides architects with an effective method for selecting the applicable multi-tenant architecture pattern, saving them effort, time, and mitigating the effects of making wrong decisions.