Formalizing and Modeling Enterprise Architecture (EA) Principles with Goal-oriented Requirements Language (GRL)

Item does not contain fulltex

i* in practice: identifying frequent problems in its application

Several notations have been proposed in the last decades to support information system architecting, design and implementation. Although some of them have been widely adopted, their practical application remains cumbersome. Reasons are manifold: ambiguous semantics, confusing graphical representation, lack of safe guidelines, etc. In this paper, we explored the use of the i* framework in industry for modeling organizational context. We review the models resulting from 36 industrial collaborations conducted in the last five years, where i* has been intensively used by novice modellers, without previous exposure to i*, acting as junior consultants in the organizations. We identify and categorize the main problems that they faced and as a result, we propose a set of guidelines to improve the adoption and practical application of the framework.Peer ReviewedPostprint (author's final draft

Formalizing and Modeling Enterprise Architecture (EA) Principles with Goal-Oriented Requirements Language (GRL)

Item does not contain fulltex

An empirical study on the use of i* by non-technical stakeholders: the case of strategic dependency diagrams

Early phases of information systems engineering include the understanding of the enterprise’s context and the construction of models at different levels of decomposition, required to design the system architecture. These time-consuming activities are usually conducted by relatively large teams, composed of groups of non-technical stakeholders playing mostly an informative role (i.e. not involved in documentation and even less in modelling), led by few experienced technical consultants performing most of the documenting and modelling effort. This paper evaluates the ability of non-technical stakeholders to create strategic dependency diagrams written with the i* language in the design of the context model of a system architecture, and find out which difficulties they may encounter and what the quality of the models they build is. A case study involving non-technical stakeholders from 11 organizational areas in an Ecuadorian university held under the supervision and coordination of the two authors acting as consultants. The non-technical stakeholders identified the majority of the dependencies that should appear in the case study’s context model, although they experienced some difficulties in declaring the type of dependency, representing such dependencies graphically and applying the description guidelines provided in the training. Managers were observed to make more mistakes than other more operational roles. From the observations of these results, a set of methodological advices were compiled for their use in future, similar endeavours. It is concluded that non-technical stakeholders can take an active role in the construction of the context model. This conclusion is relevant for both researchers and practitioners involved in technology transfer actions with use of i*.Peer ReviewedPostprint (author's final draft

The Mechanics of Enterprise Architecture Principles

Inspired by the city planning metaphor, enterprise architecture (EA) has gained considerable attention from academia and industry for systematically planning an IT landscape. Since EA is a relatively young discipline, a great deal of its work focuses on architecture representations (descriptive EA) that conceptualize the different architecture layers, their components, and relationships. Beside architecture representations, EA should comprise principles that guide architecture design and evolution toward predefined value and outcomes (prescriptive EA). However, research on EA principles is still very limited. Notwithstanding the increasing consensus regarding EA principles’ role and definition, the limited publications neither discuss what can be considered suitable principles, nor explain how they can be turned into effective means to achieve expected EA outcomes. This study seeks to strengthen EA’s extant theoretical core by investigating EA principles through a mixed methods research design comprising a literature review, an expert study, and three case studies. The first contribution of this study is that it sheds light on the ambiguous interpretation of EA principles in extant research by ontologically distinguishing between principles and nonprinciples, as well as deriving a set of suitable EA (meta-)principles. The second contribution connects the nascent academic discourse on EA principles to studies on EA value and outcomes. This study conceptualizes the “mechanics” of EA principles as a value-creation process, where EA principles shape the architecture design and guide its evolution and thereby realize EA outcomes. Consequently, this study brings EA’s underserved, prescriptive aspect to the fore and helps enrich its theoretical foundations

RationalGRL: A Framework for Argumentation and Goal Modeling

Goal-oriented requirements modeling approaches aim to capture the intentions of the stakeholders involved in the development of an information system as goals and tasks. The process of constructing such goal models usually involves discussions between a requirements engineer and a group of stakeholders. Not all the arguments in such discussions can be captured as goals or tasks: e.g., the discussion whether to accept or reject a certain goal and the rationale for acceptance or rejection cannot be captured in goal models. In this paper, we apply techniques from computational argumentation to a goal modeling approach by using a coding analysis in which stakeholders discuss requirements for a Traffic Simulator. We combine a simplified version of a traditional goal model, the Goal-oriented Requirements Language (GRL), with ideas from argumentation on schemes for practical reasoning into a new framework (RationalGRL). RationalGRL provides a formal semantics and tool support to capture the discussions and outcomes of the argumentation process that leads to a goal model. We also define the RationalGRL development process to create a RationalGRL model