Enterprise architecture for small and medium-sized enterprises

Enterprise architecture (EA) is used as a holistic approach to keep things aligned in a company. Some emphasize the use of EA to align IT with the business, others see it broader and use it to also keep the processes aligned with the strategy. Although a lot of research is being done on EA, still hardly anything is known about its use in the context of a small and medium sized enterprise (SME). Because of some specific characteristics of SMEs, it is interesting to look how EA can be applied in a SME. In this PhD, we present an approach for EA for SMEs, which combines four dimensions to get a holistic overview, while keeping things aligned. The approach is developed with special attention towards the characteristics of SMEs. Case studies are used to refine the metamodel and develop an adequate method, while tool support is being developed to enable the validation rounds

The use of the concept of event in enterprise ontologies and requirements engineering literature.

The concept of event is used in a lot of meanings. It can be the possible outcome of doing something (probability theory), it can be a business transaction (accounting), or just a plain happening. In software engineering, the concept of event is also used a lot. It is used to accomplish loose coupling between software components or to realise interaction between different services. There is however not a consensus on the meaning of `an event'. In enterprise ontologies, an event is defined as a happening at one point in time, or as an activity which takes time to complete. In requirement engineering, the same different uses can be found, together with an event as a request for something that needs to be done. These differences can also be found in implementation. All these distinct purposes of the word event make it difficult to integrate and use different requirement engineering techniques. Comparison or transformations between models drawn in different grammars is impossible because of the ambiguity of the concept of event. We define three meanings for an event that are used by enterprise ontologies and requirement engineering techniques: an achievement (happening at one point in time), an activity (happening over time) and a request (a demand for something that needs to be done). We also identify a missing link between real economic events, the events defined in the requirements model and the events used in implementation.Requirements modelling; Enterprise ontology; Process modelling; Dynamic; Event;

Naming the Pain in Requirements Engineering: A Design for a Global Family of Surveys and First Results from Germany

For many years, we have observed industry struggling in defining a high quality requirements engineering (RE) and researchers trying to understand industrial expectations and problems. Although we are investigating the discipline with a plethora of empirical studies, they still do not allow for empirical generalisations. To lay an empirical and externally valid foundation about the state of the practice in RE, we aim at a series of open and reproducible surveys that allow us to steer future research in a problem-driven manner. We designed a globally distributed family of surveys in joint collaborations with different researchers and completed the first run in Germany. The instrument is based on a theory in the form of a set of hypotheses inferred from our experiences and available studies. We test each hypothesis in our theory and identify further candidates to extend the theory by correlation and Grounded Theory analysis. In this article, we report on the design of the family of surveys, its underlying theory, and the full results obtained from Germany with participants from 58 companies. The results reveal, for example, a tendency to improve RE via internally defined qualitative methods rather than relying on normative approaches like CMMI. We also discovered various RE problems that are statistically significant in practice. For instance, we could corroborate communication flaws or moving targets as problems in practice. Our results are not yet fully representative but already give first insights into current practices and problems in RE, and they allow us to draw lessons learnt for future replications. Our results obtained from this first run in Germany make us confident that the survey design and instrument are well-suited to be replicated and, thereby, to create a generalisable empirical basis of RE in practice

Platforms and Protocols for the Internet of Things

Building a general architecture for the Internet of Things (IoT) is a very complex task, exacerbated by the extremely large variety of devices, link layer technologies, and services that may be involved in such a system. In this paper, we identify the main blocks of a generic IoT architecture, describing their features and requirements, and analyze the most common approaches proposed in the literature for each block. In particular, we compare three of the most important communication technologies for IoT purposes, i.e., REST, MQTT, and AMQP, and we also analyze three IoT platforms: openHAB, Sentilo, and Parse. The analysis will prove the importance of adopting an integrated approach that jointly addresses several issues and is able to flexibly accommodate the requirements of the various elements of the system. We also discuss a use case which illustrates the design challenges and the choices to make when selecting which protocols and technologies to use

Communication and control in small batch part manufacturing

This paper reports on the development of a real-time control network as an integrated part of a shop floor control system for small batch part manufacturing. The shop floor control system is called the production control system (PCS). The PCS aims at an improved control of small batch part manufacturing systems, enabling both a more flexible use of resources and a decrease in the economical batch size. For this, the PCS integrates various control functions such as scheduling, dispatching, workstation control and monitoring, whilst being connected on-line to the production equipment on the shop floor. The PCS can be applied irrespective of the level of automation on the shop floor. The control network is an essential part of the PCS, as it provides a real-time connection between the different modules (computers) of the PCS, which are geographically distributed over the shop floor. An overview of the requirements of such a control network is given. The description of the design includes the services developed, the protocols used and the physical layout of the network. A prototype of the PCS, including the control network, has been installed and tested in a pilot plant. The control network has proven that it can supply a manufacturing environment, consisting of equipment from different vendors with different levels of automation, with a reliable, low cost, real-time communication facility