Considering Quality of a Service in an Intentional Approach

International audienceThe success of service-based applications is based on service technologies such as Web services. Nevertheless, the benefits of the Service-Oriented Architecture (SOA) remain mainly at the software level, since business people are often unable to fully exploit its benefits due to their unfamiliarity with such software level technology. The intentional Service-Oriented Architecture (iSOA) suggests a move from the function-driven SOA to intention-driven SOA in order to provide service description understandable by business practitioners. However, such transposition from business to implementation level should also consider Quality of Service (QoS) aspects. In this paper, we propose modeling the Quality of intentional Service (QoiS) by introducing the quality goals and their qualitative and quantitative evaluation. We also propose populating the intentional service registry of the iSOA architecture with the QoiS description

Driving The Business Service-Oriented Architecture Enabled Initiative

Service-oriented architecture (SOA) continues to gain interest and deliver its business value as so many organisations are force to integrate increasingly diverse legacy systems and complex application environments. Organisations are moving towards implementing SOA initiative to become business SOA-enabled for reducing complexity and increasing business agility. Driving the initiative of SOA into business requires a set of requirements in order to successfully implement SOA. These requirements are four fundamentals of SOA initiative with associated seven elements of SOA which have been discovered via thoroughly literature analysis. A model therefore is proposed for businesses to understand how to implement and run SOA to actually achieving benefits from their SOA initiative

Fostering the adoption of i* by practitioners: some challenges and research directions

The i* framework is a widespread formalism in the software engineering discipline that allows expressing intentionality of system actors. From the time it was issued, in the mid-nineties, a growing research community has adopted it either in its standard form or formulating variations in order to adapt it to some particular purpose. New methods, techniques and tools have made evolve the framework in a way that it may be currently considered quite mature from the scientific perspective. However, the i* framework has not been transferred to practitioners at the same extent yet: industrial experiences using i* are not many and have been mainly conducted by i* experts that are part of that very research community. Therefore, it may be argued that some steps are needed for boosting the adoption of i* by practitioners. In this chapter, we identify some scientific challenges whose overcoming could represent a step towards this goal. For each challenge, we present the problem that is addressed, its current state of the art and some envisaged lines of research.Preprin

Liiketoiminnan ja IT järjestelmien yhteiskehittäminen tietojärjestelmävaatimusten määrittelyvaiheessa

New and old information systems are being developed everyday. Still, most of the information systems do not meet customers’ needs: information system reliability, usability, and suitability for the task are not adequate. Information system developers and customers do not understand each others’ work processes and world views enough to be able to communicate sufficiently. Thus, the voice of the customers is often not heard or understood during the information system development process. Requirements elicitation is the first and a critical phase in the systems design process. If the right requirements are captured during this phase, there is a higher potential for the system to satisfy the customers’ needs. This study answers to the research question: how can business and IT systems be co-designed during requirements elicitation? Two sub-questions of this study are: What are the interdependencies between information system provider and customer during requirements elicitation? How should the interdependencies between information system provider and customer during requirements elicitation be coordinated? The literature of the study consists of information system development and coordination theories. Requirements engineering, communication, and involvement of customers theories are important parts of the literature. The thesis includes three case studies including action research. The case studies are about the requirements elicitation phase of an already existing, large financial information system development project. The Finnish information system provider wanted to elicit the requirements for the information system together with the customers: three bank groups. The cases took place between August 2006 and November 2007. Action research was carried out applying SimLab’s business process development method. Data was collected by interviews (28 people), process modeling sessions and simulation day discussions, two questionnaires, feedback forms, and observation. The results of the thesis are summarized into a conceptual framework that describes the process of co-designing business and IT systems during requirements elicitation. The process consists of three steps: 1) sharing IT and business knowledge through process modeling and simulations, 2) creating common understanding about common work processes and IS and business requirements, and 3) agreeing upon the coordination methods to be used during requirements elicitation and applying them. In addition, the findings suggest a new interdependency, named systemic interdependency, to coordination literature. Systemic interdependency is suggested to be coordinated by a new coordination mode, facilitated mutual adjustment.Uusia ja vanhoja tietojärjestelmiä kehitetään jatkuvasti. Silti ne eivät tunnu vastaavan asiakkaiden tarpeita. Järjestelmät eivät ole riittävän luotettavia, helposti käytettäviä eivätkä sovellu työtehtävän suorittamiseen. Tietojärjestelmäkehittäjät ja asiakkaat eivät ymmärrä toistensa työprosesseja ja ajatusmalleja, jotta voisivat keskustella asioista riittävästi. Tämän takia asiakkaan ääntä ei yleensä kuunnella tai ymmärretä tietojärjestelmän kehittämisprosessin aikana. Vaatimusten määrittely on ensimmäinen ja kriittinen vaihe tietojärjestelmäkehitysprosessissa. Jos oikeat vaatimukset järjestelmälle löydetään tässä vaiheessa, järjestelmällä on paremmat mahdollisuudet täyttää asiakkaiden vaatimukset. Tämä tutkimus vastaa tutkimuskysymykseen: miten liiketoimintaa ja tietojärjestelmiä voidaan kehittää yhdessä tietojärjestelmävaatimusten määrittelyvaiheessa? Tutkimuksen alakysymykset ovat: Mitkä ovat tietojärjestelmätoimittajan ja asiakkaan väliset riippuvuudet vaatimusmäärittelyvaiheessa? Miten tietojärjestelmätoimittajan ja asiakkaan välisiä riippuvuuksia pitäisi koordinoida vaatimusmäärittelyn yhteydessä? Tutkimuksen kirjallisuustutkimus kohdistuu tietojärjestelmäkehityksen ja koordinoinnin teorioihin sekä vaatimusmäärittelyn, viestinnän ja asiakkaiden osallistamisen tutkimukseen. Työn empiirinen osuus käsittää kolme tapaustutkimusta, jotka toteutettiin toimintatutkimuksena. Kaikissa kolmessa tapaustutkimuksessa kehitettiin olemassa olevaa, isoa finanssialan tietojärjestelmää sen kehitysprojektin vaatimusmäärittelyvaiheessa. Suomalainen tietojärjestelmätoimittaja halusi selvittää tietojärjestelmävaatimukset yhdessä asiakkaidensa, kolmen pankkiryhmän kanssa. Tapaukset tutkittiin elokuun 2006 ja marraskuun 2007 välisenä aikana. Toimintatutkimus tapahtui SimLab™ liiketoimintaprosessien kehitysmenetelmän avulla. Tutkimusaineisto kerättiin haastatteluin (28 henkilöä), prosessimallinnus- ja simulointikeskustelujen, kahden kyselyn, palautelomakkeiden ja havainnoinnin avulla. Tutkimuksen tuloksena esitetään käsitteellinen prosessimalli liiketoiminnan ja tietojärjestelmien yhteiskehittämiselle vaatimusmäärittelyvaiheessa. Malli koostuu kolmesta vaiheesta: 1) tietotekniikka- ja liiketoimintatietämyksen jakaminen liiketoimintaprosessien mallinnusten ja -simulointien avulla, 2) yhteisen ymmärryksen rakentaminen koskien työprosesseja ja liiketoiminta- ja tietojärjestelmävaatimuksia ja 3) yhteinen sopiminen vaatimusmäärittelyn aikana käytettävistä koordinointikeinoista ja näiden keinojen soveltaminen. Lisäksi tutkimuksessa löydetään uusi tehtävien välinen riippuvuus, jota kutsutaan systeemiseksi riippuvuudeksi. Tätä koordinointikirjallisuudelle uutta riippuvuutta esitellään koordinoitavaksi uudella koordinointikeinolla, jota kutsutaan fasilitoiduksi molemminpuoliseksi mukautumiseksi

GQ-BPAOntoSOA: A goal- and object- based semantic framework for deriving software services from an organisation’s goals and riva business process architecture

Understanding a business organisation is a primary activity that is required for deriving service-oriented systems that assist in carrying out the business activities of an organisation. Business IT alignment is one of the hot topics that concerns with aligning business needs and system needs in order to keep a business organisation competitive in a market. One example in this area is the BPAOntoSOA framework that aligned business process architecture and the service-oriented model of computing. The BPAOntoSOA framework is a semantically enriched framework for deriving service oriented architecture candidate software services from a Riva-based business process architecture. The BPAOntoSOA framework was recently proposed in order to align the candidate software services to the business processes presented in a Riva business process architecture. The activities of the BPAOntoSOA framework are structured into two-semantic-based layers that are formed in a top-down manner. The top layer, the BPAOnt ontology instantiation layer, concerned with conceptualising the Riva business process architecture and the associated business process models. The bottom layer, which is the software service identification layer, concerned with the semantic identification of the service-oriented architecture candidate software services and their associated capabilities. In this layer, RPA clusters were used to describe the derived candidate software service. Ontologies were used in order to support addressing the semantic representation. However, the BPAOntoSOA framework has two limitations. First, the derived candidate software services are identified without considering the business goals. Second, the desired quality of service requirements that constrain the functionality of the software services are absent. This research is concerned with resolving these two limitations within the BPAOntoSOA framework. In this research, the original BPAOntoSOA framework has been extended into the GQ-BPAOntoSOA framework. A new semantic-based layer has been added into the two original layers. The new layer is concerned with conceptualising the goal- and quality- oriented models in order to address their absence in the original BPAOntoSOA framework. The new layer is called the GQOnt ontology instantiation layer. This extension has highlighted the need for aligning the models within the original BPAOnt intonation layer with the ones in the new layer. This is because the BPAOnt was the base for the identification of the candidate software services and capabilities. Therefore, a novel alignment approach has been proposed in order to address this need. Also, the original service identification approach is refined in order to adapt with the integration of goals and quality requirements.The GQ-BPAOntoSOA framework, which is a goal-based and quality-linked extended BPAOntoSOA framework, has been evaluated using the Cancer Care Registration process. This is the same case study used in the evaluation of the BPAOntoSOA framework. And this is required in order to investigate the implication of integrating goals and quality requirements into the pre-existing BPAOntoSOA framework-driven candidate software services. This has shown that: (1) the GQOnt ontology does not only contribute to the extension of the BPAOntoSOA framework, yet it also contributes to providing a semantic representation of a business strategy view for an organisation. The GQOnt ontology acts as an independent repository of knowledge in order to have an early agreement between stakeholders with regard to business goals and quality requirements. The semantic representation could be reused for different purposes with respect to the needs. (2) the alignment approach has bridged the gap between goal-oriented models and Riva-based business process architectures. (3) the Riva business process architecture modelling method and business process models have been enriched with the integration of goals and quality requirements in order to provide a rich representation of business process architecture and process models that reflect an important information for the given organisation. (4) The service identification approach used in the original BPAOntoSOA framework has been enriched with goals and quality requirements. This has affected the identification of candidate software services (clusters) and their capabilities. Also, the derived candidate software services have conformed to service-oriented architecture principles. Accordingly, This research has bridged the gap between the BPAOntoSOA framework and the business goals and quality requirements. This is anticipated to lead to highly consistent, correct and complete software service specifications