Information Systems lay at the heart of today's enterprise organizations. As the organizations grow, Information Systems should evolve to adapt to new requirements emerging from changes in business models, including the adoption of new services paradigms or operational improvements. These emerging requirements impact Information Systems Architecture, requiring a continuous analysis and adaptation to new realities. In previous work, we have proposed the DHARMA Method aimed at the identification of Information System Architecture by means of the i* framework. In this on-going work we focus in the results of activity 4 of the method, which uses SR diagrams to analyze interoperability among System Actors. The results of the application of this method in a large industrial case, are used to illustrate the proposal.
Information Systems (IS) are essential in today’s enterprise organizations, being a
fundamental tool to support operation and decision-making processes. As the organizations
grow, IS should evolve in accordance and adapt to new requirements emerging from
changes in business models, including the adoption of new services paradigms or
operational improvements. In the last decades, several alternatives to the traditional
development of software from scratch, have emerged in order to construct such IS. In the
usual case, they are built as hybrid systems which integrate several software
components of different nature and origins e.g., legacy systems, web services, commercial
components (typically referred as COTS) and, Free and/or Open Source Software
(FOSS). In previous work [
The DHARMA method has been applied in over 130 industrial cases, which helped
to discover: a set of patterns [
This document is structured as follows: Section 2 presents the background and related work, section 3 presents the case study used to illustrate this on-going work, section 4 introduces a discussion how DHARMA can be used to support interoperability analysis and section 5 presents some conclusions and future lines of work. 2
The DHARMA method [
Activity 3. Decomposition of system goals. Dependencies included in the CM are analyzed and decomposed into a hierarchy of goals required to satisfy them. The goals represent the services that the system must provide. An i* SR diagram for the system is built.
Activity 4. Identification of system architecture. This activity includes the
identification of System Actors (SA), which play a role in the system and represent atomic
software domains. Goals identified in Activity 3 are analyzed and semantically
grouped. Each aggrupation revels the services that are expected to be covered by SA.
In previous works, we have presented a catalog of actors and dependencies [
As consequence of this work, we were able to confirm that, the size of resulting models makes difficult to visualize IS architecture, and thus, to analyze functional and non-functional coverage SA by software components, and communication interfaces among them, represented by dependencies among covered SA. To support this process, in this work, we focus in Activity 4 of the DHARMA method and present a first result in the effort to analyze interoperability among SA in a graphical environment.
In [
As part of this work, we have applied the DHARMA method and therefore the i* framework in a Public Institute of Higher Education in Ecuador, which purpose is to provide professional education services and research activities. The organization is composed by 26 Departments and Administrative Areas, representing the Organizational Actors (OAs).
The aim of applying DHARMA in that institution was to perform the strategic planning of IT. The resulting model was used to identify projects of development, acquisition and evolution of software needed to implement the IS, as well as communication interfaces between them.
A technical team of 8 experts was formed and trained in the i* framework and the DHARMA method; the team performed interviews to different OAs and created several models as explained in the next paragraphs.
Activity 1. At the end of the interviews, 42 Actors were identified, 26 Organizational Actors (OA) and 16 Context Actors (CA). A total of 596 Strategic Dependencies (SD) were identified, among them: 43 represent Resources, 500 Goals and 53 Qualities. Since the information was collected by different teams, we performed a validation of all actors and dependencies identified and combine them into a final model. At the end we deleted 32 duplicated dependencies and added 49 new ones. Combined SD model includes 613 dependencies (30 Resources, 533 Goals and 50 Qualities).
Activity 2. Each dependency in the combined SD model was analyzed in order to define its feasibility for being automated. We found that 497 out of 613 dependencies were prone be totally automated, whilst 94 could be partially automated. These dependencies were included into the resulting SD IS Context model.
Activity 3. We created a SR decomposition, using a Use Case based analysis considering CRUDs, transactions, procedures and queries, required to automate each dependency in the SD IS context model. Final SR model of the IS included 976 elements.
Activity 4. Elements in the SR model of the IS were semantically clustered into 123 atomic SA, which at the end where categorized into 18 components (or modules) grouping SA in similar functional areas. There are several possible scenarios for this: functionality of a SA covered by a single component; functionality of several SA covered by a single component; functionality of a SA covered by several components for redundancy reasons -e.g ubiquity-; or even the case where no software components exist to cover the functionality of a SA, requiring the construction of bespoke software. Identified components interoperate with each other through one or more interfaces, represented by links among SR elements within each component boundary (see figure 2 for an excerpt of the resulting IS model).
Human Resources
ICT
Planning Direction
Planned budget Speed in purchasing
procedures Timely services payments Payment procedures carried out Automated processes Processes established
Processing
time Requirements
defined Requirements
Procedures executed
Internal procedure registered ICT
Process acquisitions
Budget structure verified
Investment projectscontrolled
Payment request registered
Accounting registration registered Payment attended Notify about the state oftheprocess help
Send e - mail
Budget reforms carried out Budget elaborated make
help Budget project elaborated
Planned budget Budget availability Reportsof budgetary structures Fig. 2. Excerpt of the i* model of the IS.
Budgetary certificate
Project summary Speed in the process
Budgetary structures
Budget Requests for budgetary reforms made Prepare statistical tables of budget expenses Financial Management
Business intelligence
Ininvdepiscltaamntoernst Ininpvderoiscjtaemtcotesrnst
Project evaluation indicators
Investment projects managed
Investment project approved proIjnevcetsptmroepnotsInevdestment plaInnevxeepscltaumnteednt indicators calculated
Project management
Investment projects evaluated Investment plan
approved Investment plan elaborated Planning and processes
Deeping the analysis of the i* model resulting from Activity 4 of DHARMA, we argue that the analysis consists in the identification of which SA should implement the intentional elements identified in Activity 3, and which should use the intentional elements implemented in other SA (by linking them as intentional elements outside their boundary). At the end, these links represent the communication interfaces among SA.
Table 1 has been constructed from the resulting SR IS model, by counting the number of intentional element links between pairs of SA. Table 1 (a) shows the number of interfaces considering the direction of the links, whilst table 1 (b) shows the sum of the communication interfaces existing between a pair of SA.
As example, for table 1 (a) consider the SA Project Management which interacts with Business Intelligence through three links, and Business Intelligence requires one interaction from Project Management. On the other hand, table 1 (b) shows that Project Management and Business Intelligence interact between them a total of four times.
In other words, the construction of the final i* SR diagram allowed us to determine the communication interfaces between different components, which also are directly related to the interoperability of the whole IS. These communication interfaces – showed in table 1 (b) - have been represented in a chord diagram (figure 3). Each SA is represented by one color and the lines between them represent the intentional element links. The width of each line is directly related with the number of intentional element links between a pair of actors. This figure summarizes the findings from the final i* SR model and provides an overview of how interoperable SA are within IS architecture and thus, which SA requires more attention because of the degree of interconnection with other IS components. Also, departing from this figure, information systems architects will be able to justify, or not, the need of a service bus, to estimate the number of services to be hosted and the characteristics or kind of data that services to be implemented shall carry.
Additionally, this representation helps to focus into the SA with greater interoperability requirements (e.g. those demanding the most communication interfaces) and to prioritize its implementation or adaptation. Bidirectional traceability provided by the models created through the activities of the DHARMA method, help to improve impact analysis. Since dependences with CA and OA are linked to intentional elements within the scope of SA, any strategic decision in relation to them (e.g. inclusion of new ECA or OA, change in the intentional element in relation to them), can be used to map the impact on intentional elements in IS architecture.
Research t tc enm je e rPo gaan m
Itc In this work we presented an on-going work in relation to interoperability of software components in hybrid IS. We started by applying the i* framework and the DHARMA method to define IS architecture in a large-scale project. The resulting artifacts were used to analyze interoperability among SA (atomic software domains within an IS and the software components covering its functionality). This analysis allowed for the visual identification of the more critical components in terms of interoperability within the IS and the nature of the interfaces required to implement data communication among them. As future work, we pretend to analyze in depth the identified interfaces and how they can be translated to communication mechanisms e.g. web services. By identifying these elements in an early stage of IS engineering, we hope to be able to reason about the best possible scenarios to simplify hybrid IS architecture, as well as its implementation and evolution.