iStar in Practice: On the identification of reusable SD Context Models Elements

Abstract

Modern enterprises rely on Information Systems (IS) required both to support their operation and provide information required to endorse strategic decisions. Because of their increasing complexity, such systems are usually constructed by integrating software components of different nature and origins into hybrid systems, for which architectural design plays a fundamental role. However, far from simple, this task is usually cumbersome. In previous work we have addressed this issue and proposed a four steps, pattern-based approach, aimed to help in the solution of this problem. In first steps, patterns are described as Context Models, which include recurring elements (actors and dependencies) identified in several industrial cases. In this work we further address this issue and present an study aimed at the validation and extension of such patterns, and/or the identification of new ones, by reviewing recurring elements appearing in 29 semi-industrial IS architectural design processes.

-

Modern enterprises rely on Information Systems (IS) specifically designed to manage the increasing interactions with their context. Enterprise Architecture (EA) [ 1 ], is a new approach involving several levels of architectural design, including IS architecture, which requires deep understanding of enterprise context and strategies. Enterprise Context Models (CM) are usually built to support this process, assisting enterprise decisionmakers to design and refine their business strategies and enterprise architects to understand what will be required from IS. Far from easy, the construction of such models is usually a cumbersome task, mainly due to communication gaps among technical personnel with limited knowledge of enterprise structure, operations and strategy, and their administrative counterparts imposing pressure and time constraints to the process.1

In order to deal with these problems, in the last few years we have intensively used the i* notation to bridge the gap among technical consultants and non-technical stakeholders [ 2 ] and proposed the DHARMA method [ 3 ], for discovering IS architecture departing from the construction of CM expressed in i*. The application of the first activities of this method in several industrial and academic cases, allowed us to identify a catalogue of patterns [ 4 ], which could be used as templates for both technical and Copyright © 2015 for this paper by its authors. Copying permitted for private and academic purposes. managerial personnel in order to improve their understanding. Patterns store knowledge represented by i* Strategic Dependency models, including generic environmental actors and their strategic dependencies. The catalogue distinguish two levels of abstraction, the higher applicable in general to any kind of enterprise and the lower which considers enterprise strategies describing how a particular enterprise operates.

Although very valuable in practice, we thought that the catalogue could be extended, with additional levels representing knowledge of more specific enterprise domains. In this paper we present initial findings in relation to this belief, which emerged after conducting several semi-industrial cases of applications of the DHARMA method. 2

The Case Studies

In the last three years we have conducted 29 semi-industrial cases of application of the DHARMA method (industrial cases conducted by senior Information Systems Engineering students with support of teachers, for which formal agreements existed, but were conducted with no cost for participant enterprises). Cases were part of a broader study conducted in Ecuadorian enterprises, intended to identify CMs patterns meant to improve the identification of IS architectures (System Actors -atomic software domains that structure the system-, services that must be covered by them and their relationships). CMs constructed for these processes were used to validate and extend the patterns presented in [ 4 ] (by measuring occurrence of the included elements), and to identify new domain specific ones.

In the study, 25 of the enterprises were small companies, 3 medium size, and the last one a large manufacturing company. This distribution aligns with the Ecuadorian reality, mainly structured with small companies (97,94%) [ 6 ]. Enterprises were categorized according to NACE Rev 2. Categories included: Manufacturing (wood, textiles, food and cardboard processing); Wholesale and retail trade (hardware and software, textiles, leather, home appliances, motorized vehicles and general goods); and Services (basic, specialized –language- and advanced education, and financial – accounting-) 3

Data Analysis

Actors and dependencies included in the resulting 29 CMs were extracted and placed in tables specifically designed to support the analysis process. Columns represent modelled enterprises whilst rows list the identified actors (table 2) and their corresponding dependencies (table 3). Actors identified in the 29 cases were grouped in relation to 8 of the generic actors identified in [ 4 ], Suppliers, Consumers, Strategic Partners, Distributors, Financial Institutions, Regulatory Agencies, Control Agencies, Competitors. Table cells are used to state the cases in which listed actors/dependency were identified. Total column adds up the number of occurrences of elements in each row, whilst percentage gives the relation among the totals and the number of case studies.

At the end, a total of 54 actors and 189 dependencies were identified in the 29 cases. All of the actors are instances of the generic actors identified in [ 4 ], which makes evident the validity of knowledge included in the proposed patterns in relation the this kind of elements. 23 out of 54 actors identified appear in at least 17% of the cases; 14 of them in at least 24% of the cases.

Enterprise 1 2 Sport Chavis Panadería Centenario FABRICA 3 4 CARTOPEL 5 Forjart 6 ElectroUnion 7 Muebleria BienStar 8 FEMUSA Mobiliarios 9 SANTANA Muebles

Importadora Tomebamba 10

JCEV Cia. Ltda. 11 12 TECNISUR 13 Trebol Roses 14 CAPEDI 15 Al Design 16 Giga Computers 17 APC Tecnología 18 HOLIDATSERV 19 TOTAL COMPU 20 Dress Up Store 21 KRISTEN 22 Sodilibro 23 enlinea.com 24

Calzado Turismo

ByB Asesoría contable y tributaria 25 26 Jardín ABC 27 Colegio Técnico Sudamericano 28 CORNATEC Cía. Ltda. 29 Golden Bridge

Important customer X X X X X X X X X X 10 34% identification ofWahcoletsoalercsustionmerfuture caXsesX. However we think that a more interesting2 fi7n%ding

Confident customer X 1 3% is the fact that actors grouped into generic actors define orthogonal dimensions that can

Frequent customer X X X 3 10% be used to categ oRertaiilzcustotmherem (see table 4 Xfor anXeXxcXerpt).X For instance,XAcXtors cat e7g2o4%rized e

Employee customer X 1 3%

Direct Customers under the SuppliSepercifsic agreaecnusetomreirc actor define at leXast three XdimensionXs: LocatXionX (l o5c1a7%l, na

Public institutions X X 2 7% tional, InternatioPrnivaatelo)rg;anKizatiionnsd of supply (pX roductsX –raw maXterials, supplies or tech3n1o0%logy

International custommer X 1 3% , or services); anCdash Vcusotomluer me (wholesale or retail). The importance of this fiXnding1 w3%ill be

Credit customer X X 2 7% illustrated in secPtriimoarynpro4du.ct or service X 1 3%

Secondary product X X 2 7% It is importaMnunticiptaolity notice that CMX XinX mXost of t hXeX cXasesX aXlXsoX iXnXcXluded Xgeneri1c5 5a2%ctors,

Fire offices X X X X X X 6 21% (even when m oTrardeeunsiopnecific instances haXve been identified) e.g. generic actorX S2up7p%liers Internal Revenue Service Ecuadorian Social Security Institute Superintendent of companies Ministry of education Ministry of labor relations Others (INCOP, ARCSA) Customs (SENAE) International standards agency

X X X X X X X X X X X

X X X

X X

X

X X X X X X X X X X X X X X X X X 27 93%

X X X X X X X 12 41%

X X 2 7%

X X 2 7%

X X X X 5 17%

X 2 7% X X X X 4 14%

X 1 3% and the instances Row Materials, Technology, Basic Services etc., included in Table 2. This fact supports the need of the “is-a” generalization-specialization construct included in i*, as a mean to support the grouping of dependencies shared by instances of a more generic actor. These dependencies representing intentional aspects common to all of them in relation particular organizational processes.

Similarly to actors, some dependencies are instances of more generic ones, included in patterns presented in [ 4 ], but also some additional ones were identified. 52 out of the 189 dependencies appeared in at least 17% of the cases; 36 of them in at least 24% of cases. Dependencies are related to specific actors and stored together with them in the patterns catalogue. Therefore, they can also be used as check lists to identify dependencies to be included in CM of future cases, e.g. by using the instantiation rules proposed in [ 4 ]. n o it c e ir D Because of problems with i* semantics, and the descriptions used by modelers in different cases, mapping of similar dependencies is not as straightforward as mapping actors. For instance, for the generic actor Supplier we found the objective "Payment Made" in 8 out of 29 cases. However, when later analyzed, it became evident that systems engineers were using other types of dependencies to state the same intentional aspect, in order to emphasize aspects that were relevant for their administrative counterparts, e.g. the soft goal "timely payment" or the resources "payment documents" or "cash/check". In addition to semantics, variations can be attributed to lack of experience of engineers, the existence of “unfamiliar” industrial glossaries or the fact that some dependencies were omitted as redundant. 4

Reusing Knowledge Elements

At this point, we have shown important evidence supporting reusability of the proposed patterns and their elements. Because of this, we can sustain that a good way to construct i* SD-based CM, instead of departing from scratch, is to reuse the elements included in the proposed patterns, going through them as a checklist and adopting those that are relevant for the enterprise context being modeled. Furthermore, in [ 4 ] we have defined several pattern instantiation rules specifically designed to support this process.

However, in this paper we argue that there can be and alternative and more systematic way to reuse CM elements (actors and dependencies), to construct complete i* SDbased CM from scratch and eventually automate this process. An important aspect emerging from this work, introduced in section 2, is the identification of several orthogonal dimensions useful to classify instances of generic the actors (see table 4 for an excerpt in relation to the Customer generic actor). Each of these dimensions has a set of associated value labels, representing potential actor instances (identified from CM of the 29 case studies). These labels have sets of generic dependencies (also identified from the 29 case studies) associated to them. Based on this table, practitioners (system engineers and administrative staff) can systematically identify a large number of actors on their operational context, by selecting and combining labels from each dimension. To illustrate the approach, let’s consider the first two labels of three of the Customer’s categorization dimensions in table 4, frequency/volume, distribution channel, and payment method. In this case, 12 combinations representing potential instances of actors in the context of the organization are possible: Potential Wholesaler Credit, Potential Wholesaler Cash, New Wholesaler Credit, New Wholesaler Cash, Important Wholesaler Credit, Important Wholesaler Cash, Potential Retailer Credit, Potential Retailer Cash, New Retailer Credit, New Retailer Cash, Important Retailer Credit, and Important Retailer Cash.

Let’s assume that in a particular case the New Wholesaler Credit Customer is selected from this set of combinations, then all the dependencies associated to labels included in the name are potential dependencies to be included in the CM of the organization, see figure 2. In this way, identification of dependencies can also be automated. Multi-inheritance shall be used in order to avoid duplication of dependencies in cases were several instances of a same generic actor include occurrences of the same labels on their names. Also dependencies associated to the generic actor have to be included in the model for the reasons explained in section 3. In this paper we have presented an approach to automate construction of i* SD basedCM, which reuses elements (actor and dependencies), included in the patterns presented in [ 4 ]. Elements in these patterns have been validated, and patterns have been extended with the results of 29 semi-industrial IS architectural design process, conducted in the last three years. All of these projects used the DHARMA method, which requires enterprise CM to be constructed as departing activity for a IS architectural design. We have also proposed a method to systematize the identification of context actors and dependencies, and eventually automate the construction of i*-based CM. it is important to remark that the proposal is based in a significant amount of empirical evidence which makes it highly useful. We are currently finishing the construction of a tool to support the method and exploring the ontological representation of patterns in order to improve CM construction, by automatically recommending the elements to be included in them.

References

1. The Open Group. The Open Group Architecture Framework (TOGAF) version 9 . The Open Group, 2009

2. Carvallo , J.P. Supporting Organizational Induction and Goals Alignment for COTS Components Selection by Means of i* . ICCBSS 2006

3. Carvallo , J.P. , Franch , X. On the Use of i* for Architecting Hybrid Systems: A Method and an Evaluation Report . PoEM 2009 .

4. Carvallo , J. P. , & Franch , X. Building Strategic Enterprise Context Models with i*: A Pattern-Based Approach . TEAR 2012 .

5. Steinberg , M. Enterprise Applications: A Conceptual Look at ERP, CRM, and SCM . Hill Associates Inc., 2006 .

6. http://aplicaciones2.ecuadorencifras.gob.ec/dashboard2/pagina3.php