Sietse Overbeek

Enhancing Visibility in International Supply Chains: The Data Pipeline Concept

With increasing global trade and growing emphasis on security, enhanced information sharing between actors in global supply chains is required. Currently, the data about cargo available in the supply chain does not provide a timely and accurate description of the goods. To solve this data quality issue, data should be captured upstream at the point where goods are packed for transport to the buyer. Without ICT, it was not possible to get timely access to the original trade data. The data pipeline concept is an IT innovation to enable capturing data at the source. The data pipeline accesses existing information systems used by the parties in international supply chains. This paper explores the data pipeline concept and the benefits that businesses and governments could obtain from such an innovation. This study also identifies the need for a public-private governance model that has to accompany the technical innovation.

A language for multi-perspective goal modelling: Challenges, requirements and solutions

Successful implementation of an enterprise strategy, the reorganization of an enterprise, the successful enterprise-wide adoption of a new enterprise resource planning system, or simply being able to manage the daily operations at an enterprise in general are all common examples of organizational actions that are strongly interrelated with the achievement of goals related to these actions. From the research as presented in this paper, it becomes clear that it is not elementary to clearly formulate goals and to understand how to achieve them. In two use scenarios, it is described how the executive board of a mid-sized bank in Germany wants to achieve their overall goal to increase the bank appraisal. The first scenario deals with determining who is responsible for goal creation and accomplishment, while the second scenario deals with describing a concrete goal system. A domain-specific modelling language (DSML) for designing goal models is proposed that provides solutions for requirements that are derived from the described scenarios. This DSML is coined the ‘goal modelling language’ (GoalML), which enables the development of goal models from multiple perspectives in order to relate goals with their context and vice versa.

A Comparative Analysis of Selected Enterprise Modeling Approaches

Complexity inherent to the management of organizational action recommends the use of instruments that support the structured description and analysis of organizations. A variety of enterprise modeling (EM) methods have been developed to serve these purposes. To contribute to the elucidation of their conceptual differences, overlaps, and focal points, this paper analyzes four selected EM methods based on a designed analysis framework. It includes an assessment of the methods’ key goals and purposes, central assumptions, and concepts. The paper concludes with a suggestion of future research topics.

AN EVENT-DRIVEN ARCHITECTURE FOR INTEGRATING INFORMATION, PROCESSES AND SERVICES IN A PLASTIC TOYS SUPPLY CHAIN

In global supply chains, a multitude of public and private organizations collaborate to reach the collective goal of transporting goods from the seller to the buyer. Given the dynamicity of global ...

Describing Criteria for Selecting a Scrum Tool Using the Technology Acceptance Model

Scrum teams extensively use tools to support their processes, but little attention has been given to criteria a Scrum team applies in its selection of such a tool. A greenfield approach was used to explore these criteria. To this extent twelve Scrum teams were asked to list criteria and assigned weights in their decision processes. After having chosen and used a tool for a number of Sprints, the teams also evaluated the selected tools. Using the Technology Acceptance Model to structure findings, two major categories were identified: Perceived usefulness, alias criteria directly related to Scrum, and perceived ease of use. Most teams listed more or less the same criteria. Within the categories several specific subcategories were distinguished, for instance burn-down chart support or multi-platform aspects. Teams evaluated more issues, positive or negative, within the Scrum-related criteria. The findings indicate that Scrum teams prefer perceived usefulness over perceived ease of use. In other words: Specific support of Scrum, especially its artefacts, are of greater value to a team than general tool considerations.

DevOps competences and maturity for software producing organizations

Software producing organizations aim to release high quality software faster, which triggers the adoption of DevOps. However, not many artifacts are available that aid in adopting DevOps. In an attempt to bridge this gap, a DevOps Competence Model showing an overview of the areas to be considered in adopting DevOps is proposed. Also, a DevOps Maturity Model is proposed that presents a growth path for software producing organizations. Both these models incorporate perspectives that are made up of focus areas which in turn are made up of capabilities. Apart from designing and validating these models by means of expert workshops, a case study has been conducted where assessees answered questions to gain insight into which capabilities were implemented. From the answers, maturity profiles were extracted that supported the assessees in becoming more DevOps mature.

Influence of Software Product Management Maturity on Usage of Artefacts in Agile Software Development

Context: Agile software development (ASD) uses ‘agile’ artefacts such as user stories and product backlogs as well as ‘non-agile’ artefacts, for instance designs and test plans. Rationales for incorporating especially non-agile artefacts by an agile team mainly remain unknown territory. Goal: We start off to explore influences on artefacts usage, and state our research question as: To what extent does maturity relate to the usage of artefacts in ASD in software product organizations? Method: In our multiple case study 14 software product organizations were visited where software product management maturity was rated and their artefacts usage listed. Results: We found maturity to be negatively correlated with the non-agile/all artefacts ratio. In other words, the more mature software product management is, the fewer non-agile artefacts are used in ASD. Conclusions: This suggests that an organizational factor influences an agile team in its artefacts usage, contradictory to the concept of self-organizing agile teams.

Coupling Elements of a Framework for Cognitive Matchmaking with Enterprise Models

Actors working in knowledge intensive organizations have to cope with an increased cognitive load by increasing complexity of knowledge intensive tasks that these actors have to fulfill. This is caused by developments such as: Globalization, growing product and service complexity, customers that become more and more powerful, outsourcing, and inter-organizational alliances that cause organizations to grow more rapidly. Excessive cognitive load negatively influences the quality of knowledge intensive task fulfillment. It is discussed how elements from a cognitive matchmaking framework can be coupled with an example enterprise model to partly provide a solution for avoiding cognitive load of actors in becoming too excessive. This exercise enables to achieve a better understanding of the cognitive fit of actor types and knowledge intensive task types they have to fulfill.

A DevOps Implementation Framework for Large Agile-Based Financial Organizations

Modern large-scale financial organizations show an interest in embracing a DevOps way of working in addition to Agile adoption. Implementing DevOps next to Agile enhances certain Agile practices while extending other practices. Although there are quite some DevOps maturity models available in the literature, they are either not specific to large-scale financial organizations or do not include the Agile aspects within the desired scope. This study has been performed to identify why such organizations are interested in implementing DevOps and how this implementation can be guided by a conceptual framework. As a result, a list of drivers, a generic DevOps implementation framework and driver-dependent variations are presented. The development of these artifacts has been realized through a design science research method and they have been validated by practitioners from financial organizations in the Netherlands. The practitioners have identified the developed artifacts as useful, mainly to educate people within their organizations. Moreover, the artifacts have been applied to real organizational goals to demonstrate how they can be of help to identify the useful measurement units, which in turn can help to measure and achieve their DevOps transformation goals. Thus, the developed artifacts are not only serving as a baseline for future research but are also useful for existing financial organizations to commence and get ahead with their DevOps implementations.

Working software over comprehensive documentation – Rationales of agile teams for artefacts usage

Agile software development (ASD) promotes working software over comprehensive documentation. Still, recent research has shown agile teams to use quite a number of artefacts. Whereas some artefacts may be adopted because they are inherently included in an ASD method, an agile team decides itself on the usage of additional artefacts. However, explicit rationales for using them remain unclear. We start off to explore those rationales, and state our primary research question as: What are rationales for agile teams to use artefacts? Our research method was a multiple case study. In 19 agile teams we identified 55 artefacts and concluded that they in general confirm existing research results. We introduce five rationales underlying the usage of artefacts in ASD: (1) Adoption of ASD leads to agile artefacts, (2) team-internal communication leads to functional and technical design artefacts, (3) quality assurance leads to test-related artefacts, (4) agile teams impose governance on their own activities, and (5) external influences impose user-related material. With our contribution we substantiate the theoretical basis of the Agile Manifesto in general and contribute to the current research with regard to the usage of artefacts in ASD in particular. Agile teams themselves may from this research extract guidelines to use more or less comprehensive documentation.