- Email: [email protected]
Variable Contents of Enterprise Models
Available online at www.sciencedirect.com
ScienceDirect Procedia Computer Science 104 (2017) 89 – 96
ICTE 2016, December 2016, Riga, Latvia
Variable Contents of Enterprise Models Marite Kirikovaa,* a
Department of Artificial Intelligence and Systems Engineering, Riga Technical University, 1 Kalku, Riga, LV-1658, Latvia
Abstract In information systems development models are used to represent real and target enterprise systems. Ideally the enterprise could have two basic enterprise models – an As-Is model an To-Be model that may integrate all representations of the enterprise relevant to information systems development. Although there are many different suggested approaches how to model the enterprise, no consensus exists of what exactly should be the spectrum of model elements and corresponding to them enterprise artifacts for successful enterprise and information systems development. In this paper we propose an approach of identifying core enterprise model constituents for different systems development settings. The approach is based on the integration of professional knowledge regarding artifacts used in various systems development cases with the variations of a continuous requirements engineering framework that combines traditional requirements identification functions with additional continuous audit, monitoring and analytics activities. © Published by Elsevier B.V.B.V. This is an open access article under the CC BY-NC-ND license © 2017 2016The TheAuthors. Authors. Published by Elsevier (http://creativecommons.org/licenses/by-nc-nd/4.0/). Peer-review under responsibility of organizing committee of the scientific committee of the international conference; ICTE 2016. Peer-review under responsibility of organizing committee of the scientific committee of the international conference; ICTE 2016 Keywords: Enterprise modeling; Enterprise models; FREEDOM framework
1. Introduction There are many purposes of enterprise modeling1. Usually the application of enterprise modelling is related to particular changes in company strategies, policies, and operations. Whenever the changes take place in an enterprise, the enterprise models would be expected to change correspondingly. However, in the practice, not always the changes in the particular aspects of the enterprise (including information systems development) are supplemented
* Corresponding author. Tel.: +371-26188383. E-mail address: [email protected]
1877-0509 © 2017 The Authors. Published by Elsevier B.V. This is an open access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/). Peer-review under responsibility of organizing committee of the scientific committee of the international conference; ICTE 2016 doi:10.1016/j.procs.2017.01.077
90
Marite Kirikova / Procedia Computer Science 104 (2017) 89 – 96
with the changes in the enterprise models. The out-dated enterprise models hinder the possibility to continuously maintain alignment between the enterprise models and information systems artefacts. The misalignment between the models and the artefacts, in turn, causes rework, time pressure, and errors in requirements engineering for enterprise and their information systems development. Ideally an enterprise would create and maintain two basic enterprise models that can integrate different representations of the enterprise – one of them (As-Is model) showing the current situation in the enterprise and another one (To-Be) model showing the desired state of the enterprise. The gap between these two models could be considered as a moving target of enterprise and its information systems development2. While there are many different suggested ways how to model the enterprises, for instance: 4EM3 and i*4, Enterprise Architecture models (e.g., TOGAF5), and enterprise architecture modelling language ArchiMate6, there is no consensus concerning the spectrum of model elements and corresponding to them enterprise artefacts. Taking into consideration that the enterprises and information system projects differ, we cannot expect that there is only one set of enterprise model constituents applicable to all situations. Thus, finding the right set of enterprise model constituents for the particular enterprise and information systems development situation is essential, because, on the one hand, missing of some elements may cause unexpected problems in the development process and, on the other hand, the inclusion of unnecessary elements misuses the time and effort of involved enterprise modelling participants and overcomplicates the use of models. Thus the research problem addressed in this paper is the situational identification of pragmatically appropriate set of constituents of enterprise models for continuous enterprise and information systems development. To proceed towards the solution of this problem we propose the approach for identification of enterprise model constituents that is based on the FREEDOM framework7,8 of continuous requirements engineering. The paper is structured as follows. In Section 2 the FREEDOM framework and its variants and corresponding ranges of freedom of enterprise operation are discussed. In Section 3 the role of enterprise models in the framework is further discussed focusing on the possibility to apply framework analytics; and the approach for identification of enterprise model constituents is proposed. In Section 4 applicability of the proposed approach and its impact on analytical capabilities of the framework is discussed. Section 5 consists of brief conclusions. 2. The FREEDOM framework and its variants The FREEDOM framework was proposed for the purpose of continuous requirements engineering7. The framework is flexible with respect to the actual number of basic functions involved in an enterprise and information systems engineering8. Here we will briefly introduce the framework and focus on the ranges of freedom that it offers. Also we will emphasize the role of enterprise models in the FREEDOM framework. The FREEDOM Framework is illustrated in Fig. 1. It has the following main constituents (functions): F - Future representation, R Reality representation, E1 - requirements Engineering, E2 - fulfillment Engineering, D - Design and implementation, O - Operations, and M - Management. In Fig. 1 information flows only between the E1, E2, D, O, M functions and and E1 and external environment are highlighted. However, all functions in the middle of the figure, namely E1, E2, D, O, and M receive information from and provide information for F and R functions. These flows are not shown in Fig. 1 with the purpose to do not overcomplicate the outlook of the framework. The information flows from R and F to other functions are shown further in Fig. 2 where again, for the sake of simplification of representation, only one direction of the flows is depicted, while in reality the flows are bi-directional. The constituents of the FREEDOM framework should be viewed as functions with changeable granularity8, e.g. E2 - fulfilment Engineering can be fully "moved into (inside of)" E1 - requirements Engineering, and form function EE - requirements Engineering and fulfilment Engineering; or D - Design and implementation can be fully "moved into" E - fulfilment Engineering and form function ED - fulfilment Engineering and Design and implementation; and so forth. In other words: the functions can be represented in an integrated manner in different combinations. Below the functions of the FREEDOM framework are briefly described. F - Future representation is the constituent of the framework that is responsible for the representation of the ToBe situation, i.e., the representation of a vision of the target enterprise. Artefacts that are developed by this function are mainly different enterprise models5,9, enterprise architecture development artifacts5, project plans, design documents, and even results of predictive analytics10 that represent and characterize an envisioned future situation. These artefacts may be developed by F itself and also can be contributed by other constituents of the FREEDOM
Marite Kirikova / Procedia Computer Science 104 (2017) 89 – 96
framework. Therefore, functions E1, E2, D, O, and M are related to the F (the relationships are not shown in Fig.1). In this paper we mainly focus on this (F) function and the next (R) function, as they are the ones that include the enterprise model construction and/or maintenance.
Fig. 1. Outlook of the FREEDOM framework8.
R - Reality representation is responsible for all artefacts that represent the present (As-Is) situation. The types of these artefacts are similar to those of F, with just the difference that here the information is about the current situation. Like in F, the contents may be developed by R itself or by other constituents of the FREEDOM framework. Therefore E1, E2 , D, O, and M functions are related to the R (the relationships are not shown in Fig.1). Information available in databases, warehouses, and other IT systems also may belong to R. The mapping and traceability between F and R is to be established and maintained; and the gap between F and R addressed by enterprise and information systems development activities. E1 - requirements Engineering is the function dedicated to the model and tool based acquisition and management of high quality requirements that can be used by functions located on the right from E1 in the framework. E1 to a large extent can help to meet the challenge mentioned in the previous paragraph. It also can richly contribute to F and R. While in many cases requirements engineering is related to information systems development, the FREEDOM framework does not restrict it to information technology issues. E1 is understood here in a broad sense practically referring to any changes in the enterprise. E2 - fulfilment Engineering is the function that takes care of handling project portfolios that would lead to the fulfilment of stated requirements. This function can introduce branches in the model. Details of the branching are outside the scope of this paper. Position of E2 might seem bit unusual from the point of view of traditional systems development lifecycles. However, the FREEDOM framework (1) just shows the relationships between the functions and should not be considered as a particular lifecycle and (2) despite it is common to put the design next to the requirements engineering11, we have to take into consideration that the requirements engineering, design, and implementation are often distributed and overlapping nowadays and include cross-cutting concerns, e.g. security12,13; therefore, there engineered process(es) shall take care of their continuous alignment, flexibility, and quality. In simpler cases E2 can be included in (merged with) E1 or it can include (be merged with) D. D - Design and implementation is the function that produces the design and handles implementation of the target system. The border between the design and implementation may be more or less strictly defined depending on the fulfilment strategies, methods, chosen lifecycles, and guidelines established in E2. O - Operations regard the actual operation of the implemented system, including its maintenance. M - Management refers to all levels of management under which the target system operates. The management can influence both the reality and its representation function R (see the wide arrow to R in Fig. 1) and the future vision and its representation function F (see the wide arrow to F in Fig. 1). It is assumed that knowledge continuously propagates from E1 towards O in a managed and transparent way. It is also assumed that each function can acquire information from other functions and can provide feedback to other functions. The management function can provide direct requests for actions to all other functions (Fig. 1 shows it only for E1). All functions can have the capability to acquire information from the wider external environment
91
92
Marite Kirikova / Procedia Computer Science 104 (2017) 89 – 96
beyond the reach of F and R (in Fig. 1, for outlook simplification reasons, the "sensor" in external environment is shown only for E1). As mentioned above the framework is flexible with respect to the granularity of functions. For different enterprise there can be different structure of the functions. Larger enterprises may need the original structure of the framework while smaller companies may wish to integrate several functions. Also it has to be mentioned that each function in the framework itself can be represented with one of the possible variants of the FREEDOM framework (in a smaller scale)8. The framework is build so that that a constant information propagation from E1 towards M is possible. By this information the function on the left can set specific restrictions to the functions on the right. However, these restrictions are relative, and there can be a certain range of freedom for other functions where they do not depend on the engineered requirements, engineered fulfilment, design and implementation and operations. Among the others the following five cases can be mentioned: x
x x x x
While we are used to say that requirements change continuously, still, the strictly approved changes that require enterprise wide requirements and fulfilment engineering are less frequent than smaller adjustments at operational or design levels. Thus, the management can have a range of freedom even if other things in the enterprise do not change; i.e. the M function can be improved without changing the operations. This gives an opportunity to handle relationships with other enterprises in the environment more effectively, give better feedback, etc. O and M can be changed without changing the basic design of enterprise processes and information systems. This can provide more efficient management and operations, however, if add-on applications are made, this can harden the change process in future14,15 D, O and M can be changed without changing the portfolios and systems development approaches. This gives an opportunity to experiment with the designs and chose the best solutions for the given situation For the same set of initial requirements it is possible to define different E2, D, O and M in case the situation in the enterprise or its environment changes and requires different distribution of resources E1 at the enterprise level can change and correspondingly enforce new possibilities in E2. D, O and M
If the changes are done, they have to be forward propagated; i.e. if operations are changed, likely there will be changes in the management, and if designs are changed likely there will be corresponding changes in the operations. So we can say that the stable part of the functions is on the left of the point from which the independent changes can be done. It is necessary to note, that the freedom or independence with respect to the changes can cause high enterprise and information systems development complexity; e.g. independent changes made in D may cause problems when changes are introduced in the functions on the left of the freedom point, because of the misalignment that has been caused by the changes in the design. Moreover, there can be simultaneous relatively independent changes in E2, D, O and M. These possible simultaneous changes can cause the high complexity of the situation, which is hard to be handled if there are no appropriate F and R available. Handling of this complexity is hardly possible with pure top down approaches of systems engineering. Therefore the FREEDOM framework has information relationships (see Fig.1), which stays for such methods as "monitoring", "audit" and "analytics". To apply these methods, it is necessary to have means for having at least partly defined relationship between constituents of F and R and constituents of other functions of the FREEDOM framework. Consequently, taking into consideration that enterprise modelling is a part of F and R, the availability of appropriate enterprise models is essential. Taking into consideration that different ranges of freedom will be in force for different variants of granularity of the FREEDOM framework, there can be a high variability of the framework's variants. Nevertheless for each enterprise likely there will be one dominating variant of the framework. Assuming this, it is important to find appropriate enterprise models for F and R of the enterprise. In the next section the approach that allows defining enterprise model constituents for different variants of the FRREDOM framework is proposed. 3. The approach for selecting the enterprise model constituents This section is devoted to the question of the selection of enterprise model content for F and R functions of the FREEDOM framework. While there are different variants of the framework possible still these two functions (F and R) always are in their place, - the framework prescribes two representations of the enterprise: the envisioned future
Marite Kirikova / Procedia Computer Science 104 (2017) 89 – 96
representation (To-Be) and the representation of a current situation, i.e. reality (As-Is). What is included in these representations depends on a particular FREEDOM framework variant. We assume that as a minimum, the F and R should contain all information about the enterprise that is needed to perform tasks of other functions of the framework that use the information about the enterprise. For different variants of the framework the required information may be different. For instance, if the E1, E2 and D are merged, as it would be in agile approaches, the contents of enterprise models may be not as rich as it would be when using E1, E2 and D separately. We propose the following FREEDOM framework based approach for identifying constituents of enterprise models used for functions F and R of the framework: x Choose the FREEDOM framework variant with respect to the granularity of functions8 x Decide on the possible ranges of freedom (see explanation in Section 2) x Examine information flows from F and R with respect to the choices done in points 1 and 2 - select the scope of enterprise model elements according to the expected content of the information flows x On the basis of the content identified in Point 3, establish an enterprise meta-model that can amalgamate or integrate all identified elements The meta-model developed in Point 4 has to distinguish between As-Is and To-Be elements, to be useful for identifying gaps in the enterprise models for further developments. The gaps can be denoted similarly as it is done in ArchiMate6. We can also draw a parallel between work packages in ArchiMate and the tasks of E2 (fulfilment Engineering) of the FREEDOM framework. The difference is in that ArchiMate does not directly relate the content of the enterprise architecture to specific enterprise and information systems development approach for which a particular variant of the FREEDOM framework is chosen. The core of the proposed approach is Point 3 which requires to analyze E1, E2 ,D, O, and M (or integrated) functions of the chosen variant of the FREEDOM framework and identify all information item types or constituents of enterprise representation that are needed for practical realization of these functions (see Fig. 2).
Fig. 2. Identifying constituents of enterprise models.
The analysis of the functions can be based on practiced project management and systems development methods or particular knowledge bodies. In the next section we will discuss whether really different approaches, methods and knowledge bodies (and corresponding to them variants of FREEDOM framework) require variable (different) constituents of enterprise models for F and R functions of the framework, and how these constituents can be useful in FREEDOM framework monitoring, audit and analytics.
93
94
Marite Kirikova / Procedia Computer Science 104 (2017) 89 – 96
4. Towards variable set of enterprise model constituents To theoretically validate whether various combinations of enterprise model constituents will be obtained in different enterprise and information systems development settings, we analyzed several project management and systems development approaches and methods and several knowledge bodies of some standards relevant in systems engineering. When analyzing these approaches, methods, and standards, we paid attention to the artefacts mentioned in them. So far we have focused on artefacts related to only one function of the FREEDOM framework, namely, E1 requirements Engineering16. We assume that, if we know which artefacts are used in particular approaches, methods and standards with respect to requirements engineering, we can derive corresponding enterprise model constituents related to requirements engineering function. It should be noted here that other functions of the FREEDOM framework may suggest additional enterprise model constituents. Table 1 shows an excerpt of the results of analysis of enterprise architecture framework TOGAF5, RUP methodology17, BABOK18, IREB standard19 and SCRUM20. Taking into consideration that in different approaches similar or even the same artefacts are sometimes named differently, for the final use for enterprise model content definition, the artefacts have to be decomposed to smaller units to strictly understand their content. The table shows only a part of raw data, therefore, there are cases where the items partly overlap. In a particular row mark “X” is mentioned only in the cases when the descriptions of items of respective columns use exactly the same term as is displayed in the first column of the table in that row. There are cases when the term intuitively is covered by several rows; however, mark “X” is included only in the row of exact wording of the artefact. Table 1. Requirements related artefacts in TOGAF, RUP, BABOK, IREB, and SCRUM. Titles of the artifacts Training materials Business function model Business functions specifications Business goals Business rule model Business requirements Business processes representation Business indicators Work plan for realization stage Systems context documentation) Classification of documents Entity–relationship model for database Physical data model System Functions Specifications Definition (Criteria) of Done Sprint/product backlog Forms release model Change requests Configuration model The concept of storage system Team Application code Application component model Application installation plan User activity system model script User Interface Model Logical Data Model Organizational structure Requests from stakeholders Application architecture Application components specifications Software system specification System function model System functions a script model System Rules model
TOGAF
RUP
X X X
X X X X X
X X X
X
BABOK
IREB
AGILE
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
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 X X X X X X X
X X
X
X
95
Marite Kirikova / Procedia Computer Science 104 (2017) 89 – 96
Test example model Test software functionality model Test software component specification model Service-Function Catalogue
X X X X
X X X
X X X X
Despite the data is row, the preliminary results can give some insights in what are the expected enterprise models for the FREEDOM framework variants. It is not a surprise that all columns consider business goals, business process representation, data, and performers (both the performers of organizational tasks and implementers of information systems changes). From this we can conclude that any enterprise model has to have these four models. However, in Table 1 these four constituents (shown in italic) are the only items that are covered by all columns. In all other cases some differences are seen. This, at least for the requirements Engineering function (E2) assures that the enterprise model constituents will be different for specific enterprise and systems development setting. There are also the following artefacts, for which it is not clear how exactly they should be related to enterprise models: x In the lists of artefacts there are documents of different plans for different stages of systems development (see as an example two shaded items in the upper part of Table 1) x Among the other artifacts there are also artifacts related to testing (see as an example three shaded items at the bottom part of Table 1) Another question to be answered is whether the fact that the enterprise models correspond to the artefacts used in a particular enterprise and systems development setting can facilitate the application of the framework analytics activities. Taking into consideration, that the analysed artefacts are related to requirements engineering function, we consider here the related fork on application of analytics in requirements engineering. This gives an opportunity to cross check whether the relationship between analytics activities and detected constituents of enterprise models can be established. The following requirements engineering analytics activities have been reported in the related work: x Analytics based on software development indicators. From this we can learn that the analytics in D function of the FREEDIM framework can be useful. This work does address the E1 function only partly, nevertheless some of the indicators mentioned in the article such as, e.g. "responsible people", correspond to the artefacts identified in Table 1 x Web analytics that refers to the use of data about website usage. This analytics activity supports E1 with respect to environment analysis; however, it does not provide information that would be applicable for evaluation of variants of enterprise models x Visual analytics related to requirements structure. This approach would have a potential for providing models of the analytics based on the constituents of the enterprise models thus aligning the analytics model to the appropriate variant of the enterprise model x An overview of visual analytics methods for requirements engineering refers to several approaches of visualization that take into consideration also the enterprise model constituents corresponding to items reflected in Table 1 The analysis of artefacts as the base of constituents of the enterprise models used in the FREEDOM framework, and brief analysis of related work in requirements analytics allows seeing that for different enterprise and information systems development settings, various appropriate enterprise models are needed. Existence of these models might be helpful for identifying the gap between the current and future situations without waste of time and without missing relevant constituents of the model. The enterprise models with appropriate constituents would help to develop the analytics models easier and thus support the enterprise development by effective requirements analytics and monitoring. We can assume that appropriately chosen variants of enterprise models would be helpful also for auditing the requirements (e.g. in requirements walkthroughs sessions). 5. Conclusion While the enterprise modelling is a well established discipline1, still, in real life situations, there are problems in the application of enterprise models. In this paper we propose the approach for selecting enterprise models with such constituents that correspond to particular enterprise and information systems development settings. The variability of the settings (and respectively - variants of enterprise models) is illustrated using the FREEDOM
96
Marite Kirikova / Procedia Computer Science 104 (2017) 89 – 96
framework. The framework was initially established for purposes of continuous requirements engineering and, additionally to its main functions, incorporates monitoring, audit and analytics activities. The first experiments with the proposed approach show that, while it is evident that there are the differences in required enterprise models, there are also particular constituents that are present in all analyzed cases, namely business goals model, business process model, data model, and the representation of the team which is the change agent. Future work includes deeper analysis with respect to other functions of the FREEDOM framework and practical experiments with the approach in different enterprise and information systems development settings. Acknowledgements The work is supported in part by the Latvian National research program SOPHIS under g. a. Nr.10-4/VPP-4/11. References 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20.
Seigerroth U. The Diversity of Enterprise Modeling – a Taxonomy for Enterprise Modeling Actions. Complex Systems Informatics and Modeling Quarterly. 4; 2015. p. 12–31. Oemig C. When Analysts turn into Boxers: An Introduction to Pre-Sales Requirements Engineering. Complex Systems Informatics and Modeling Quarterly. 3; 2015. p. 1-14. Sandkuhl K et al. Enterprise Modeling Tackling Business Challenges with the 4EM Method. Springer; 2014. Yu E. Modeling organizations for information systems requirements engineering. In: Proceedings of IEEE International Symposium on Requirements Engineering; 1993. p. 34–41. TOGAF 9.1. Part II: Architecture Development Method (ADM). Available: http://pubs.opengroup.org/architecture/togaf9doc/arch/chap05.html. The Open Group. ArchiMate. 2.0-3.0 Specification. Available: https://www2.opengroup.org/ogsys/jsp/publications/ PublicationDetails.jsp?publicationid=12480. Kirikova M. Continuous Requirements Engineering in FREEDOM Framework: a Position Paper. 22nd International Conference REFSQ 2016. Vol. 1564; 2016. Kirikova M. Towards Framing the Continuous Information Systems Engineering. Joint Proceedings of the BIR 2016. Available: http://ceur-ws.org/Vol-1684/. Weber H. Continuous engineering of information and communication infrastructures. FASE 99. LNCS 1377; 1999. p. 22–29. Finlay S. Predictive Analytics, Data Mining and Big Data: Myths, Misconceptions and Methods. Springer; 2014. Richter M, Fluckiger M. User-Centred Engineering. Springer; 2014. Kaiser B et al. Contract-Based Design of Embedded Systems Integrating Nominal Behavior and Safety. Complex Systems Informatics and Modeling Quarterly. 4; 2015. p. 66–91. Schmitt C, Liggesmeyer P. Getting Grip on Security Requirements Elicitation by Structuring and Reusing Security Requirements Sources. Complex Systems Informatics and Modeling Quarterly. 3; 2015. p. 15–34. Alksnis G et al. Enabling Support of Collaborative Cross-enterprise Business Processes for Legacy ERP Systems. Complex Systems Informatics and Modeling Quarterly. 2; 2015. p. 1-18. Silic M et al. Influence of Shadow IT on Innovation in Organizations. Complex Systems Informatics and Modeling Quarterly. 8; 2016. p. 68-80. Sirokovs A. Requirements Engineering Artefacts. Master Thesis Report No. 2. Riga: RTU; 2016. (in Latvian). Rational Unified Process Best Practices for Software Development Teams. Available: https://www.ibm.com/developerworks/rational /library/content/03July/1000/1251/1251_bestpractices_TP026B.pdf. BABOK Guide – IIBA. Available: http://www.iiba.org/babok-guide.aspx. IREB standards. Available: https://www.ireb.org/en. SRUM Guides. Available: http://www.scrumguides.org.
Marite Kirikova is a Professor in Riga Technical University, Latvia. She has more than 150 publications on the topics of Requirements Engineering, Business Process Modelling, Knowledge Management, and Systems Development. She has done field work at Stockholm University, Copenhagen University, Denmark, and Boise State University, USA. Currently in her research she focuses on information systems design in the context of agile and viable systems paradigms. Contact her at [email protected].
ScienceDirect Procedia Computer Science 104 (2017) 89 – 96
ICTE 2016, December 2016, Riga, Latvia
Variable Contents of Enterprise Models Marite Kirikovaa,* a
Department of Artificial Intelligence and Systems Engineering, Riga Technical University, 1 Kalku, Riga, LV-1658, Latvia
Abstract In information systems development models are used to represent real and target enterprise systems. Ideally the enterprise could have two basic enterprise models – an As-Is model an To-Be model that may integrate all representations of the enterprise relevant to information systems development. Although there are many different suggested approaches how to model the enterprise, no consensus exists of what exactly should be the spectrum of model elements and corresponding to them enterprise artifacts for successful enterprise and information systems development. In this paper we propose an approach of identifying core enterprise model constituents for different systems development settings. The approach is based on the integration of professional knowledge regarding artifacts used in various systems development cases with the variations of a continuous requirements engineering framework that combines traditional requirements identification functions with additional continuous audit, monitoring and analytics activities. © Published by Elsevier B.V.B.V. This is an open access article under the CC BY-NC-ND license © 2017 2016The TheAuthors. Authors. Published by Elsevier (http://creativecommons.org/licenses/by-nc-nd/4.0/). Peer-review under responsibility of organizing committee of the scientific committee of the international conference; ICTE 2016. Peer-review under responsibility of organizing committee of the scientific committee of the international conference; ICTE 2016 Keywords: Enterprise modeling; Enterprise models; FREEDOM framework
1. Introduction There are many purposes of enterprise modeling1. Usually the application of enterprise modelling is related to particular changes in company strategies, policies, and operations. Whenever the changes take place in an enterprise, the enterprise models would be expected to change correspondingly. However, in the practice, not always the changes in the particular aspects of the enterprise (including information systems development) are supplemented
* Corresponding author. Tel.: +371-26188383. E-mail address: [email protected]
1877-0509 © 2017 The Authors. Published by Elsevier B.V. This is an open access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/). Peer-review under responsibility of organizing committee of the scientific committee of the international conference; ICTE 2016 doi:10.1016/j.procs.2017.01.077
90
Marite Kirikova / Procedia Computer Science 104 (2017) 89 – 96
with the changes in the enterprise models. The out-dated enterprise models hinder the possibility to continuously maintain alignment between the enterprise models and information systems artefacts. The misalignment between the models and the artefacts, in turn, causes rework, time pressure, and errors in requirements engineering for enterprise and their information systems development. Ideally an enterprise would create and maintain two basic enterprise models that can integrate different representations of the enterprise – one of them (As-Is model) showing the current situation in the enterprise and another one (To-Be) model showing the desired state of the enterprise. The gap between these two models could be considered as a moving target of enterprise and its information systems development2. While there are many different suggested ways how to model the enterprises, for instance: 4EM3 and i*4, Enterprise Architecture models (e.g., TOGAF5), and enterprise architecture modelling language ArchiMate6, there is no consensus concerning the spectrum of model elements and corresponding to them enterprise artefacts. Taking into consideration that the enterprises and information system projects differ, we cannot expect that there is only one set of enterprise model constituents applicable to all situations. Thus, finding the right set of enterprise model constituents for the particular enterprise and information systems development situation is essential, because, on the one hand, missing of some elements may cause unexpected problems in the development process and, on the other hand, the inclusion of unnecessary elements misuses the time and effort of involved enterprise modelling participants and overcomplicates the use of models. Thus the research problem addressed in this paper is the situational identification of pragmatically appropriate set of constituents of enterprise models for continuous enterprise and information systems development. To proceed towards the solution of this problem we propose the approach for identification of enterprise model constituents that is based on the FREEDOM framework7,8 of continuous requirements engineering. The paper is structured as follows. In Section 2 the FREEDOM framework and its variants and corresponding ranges of freedom of enterprise operation are discussed. In Section 3 the role of enterprise models in the framework is further discussed focusing on the possibility to apply framework analytics; and the approach for identification of enterprise model constituents is proposed. In Section 4 applicability of the proposed approach and its impact on analytical capabilities of the framework is discussed. Section 5 consists of brief conclusions. 2. The FREEDOM framework and its variants The FREEDOM framework was proposed for the purpose of continuous requirements engineering7. The framework is flexible with respect to the actual number of basic functions involved in an enterprise and information systems engineering8. Here we will briefly introduce the framework and focus on the ranges of freedom that it offers. Also we will emphasize the role of enterprise models in the FREEDOM framework. The FREEDOM Framework is illustrated in Fig. 1. It has the following main constituents (functions): F - Future representation, R Reality representation, E1 - requirements Engineering, E2 - fulfillment Engineering, D - Design and implementation, O - Operations, and M - Management. In Fig. 1 information flows only between the E1, E2, D, O, M functions and and E1 and external environment are highlighted. However, all functions in the middle of the figure, namely E1, E2, D, O, and M receive information from and provide information for F and R functions. These flows are not shown in Fig. 1 with the purpose to do not overcomplicate the outlook of the framework. The information flows from R and F to other functions are shown further in Fig. 2 where again, for the sake of simplification of representation, only one direction of the flows is depicted, while in reality the flows are bi-directional. The constituents of the FREEDOM framework should be viewed as functions with changeable granularity8, e.g. E2 - fulfilment Engineering can be fully "moved into (inside of)" E1 - requirements Engineering, and form function EE - requirements Engineering and fulfilment Engineering; or D - Design and implementation can be fully "moved into" E - fulfilment Engineering and form function ED - fulfilment Engineering and Design and implementation; and so forth. In other words: the functions can be represented in an integrated manner in different combinations. Below the functions of the FREEDOM framework are briefly described. F - Future representation is the constituent of the framework that is responsible for the representation of the ToBe situation, i.e., the representation of a vision of the target enterprise. Artefacts that are developed by this function are mainly different enterprise models5,9, enterprise architecture development artifacts5, project plans, design documents, and even results of predictive analytics10 that represent and characterize an envisioned future situation. These artefacts may be developed by F itself and also can be contributed by other constituents of the FREEDOM
Marite Kirikova / Procedia Computer Science 104 (2017) 89 – 96
framework. Therefore, functions E1, E2, D, O, and M are related to the F (the relationships are not shown in Fig.1). In this paper we mainly focus on this (F) function and the next (R) function, as they are the ones that include the enterprise model construction and/or maintenance.
Fig. 1. Outlook of the FREEDOM framework8.
R - Reality representation is responsible for all artefacts that represent the present (As-Is) situation. The types of these artefacts are similar to those of F, with just the difference that here the information is about the current situation. Like in F, the contents may be developed by R itself or by other constituents of the FREEDOM framework. Therefore E1, E2 , D, O, and M functions are related to the R (the relationships are not shown in Fig.1). Information available in databases, warehouses, and other IT systems also may belong to R. The mapping and traceability between F and R is to be established and maintained; and the gap between F and R addressed by enterprise and information systems development activities. E1 - requirements Engineering is the function dedicated to the model and tool based acquisition and management of high quality requirements that can be used by functions located on the right from E1 in the framework. E1 to a large extent can help to meet the challenge mentioned in the previous paragraph. It also can richly contribute to F and R. While in many cases requirements engineering is related to information systems development, the FREEDOM framework does not restrict it to information technology issues. E1 is understood here in a broad sense practically referring to any changes in the enterprise. E2 - fulfilment Engineering is the function that takes care of handling project portfolios that would lead to the fulfilment of stated requirements. This function can introduce branches in the model. Details of the branching are outside the scope of this paper. Position of E2 might seem bit unusual from the point of view of traditional systems development lifecycles. However, the FREEDOM framework (1) just shows the relationships between the functions and should not be considered as a particular lifecycle and (2) despite it is common to put the design next to the requirements engineering11, we have to take into consideration that the requirements engineering, design, and implementation are often distributed and overlapping nowadays and include cross-cutting concerns, e.g. security12,13; therefore, there engineered process(es) shall take care of their continuous alignment, flexibility, and quality. In simpler cases E2 can be included in (merged with) E1 or it can include (be merged with) D. D - Design and implementation is the function that produces the design and handles implementation of the target system. The border between the design and implementation may be more or less strictly defined depending on the fulfilment strategies, methods, chosen lifecycles, and guidelines established in E2. O - Operations regard the actual operation of the implemented system, including its maintenance. M - Management refers to all levels of management under which the target system operates. The management can influence both the reality and its representation function R (see the wide arrow to R in Fig. 1) and the future vision and its representation function F (see the wide arrow to F in Fig. 1). It is assumed that knowledge continuously propagates from E1 towards O in a managed and transparent way. It is also assumed that each function can acquire information from other functions and can provide feedback to other functions. The management function can provide direct requests for actions to all other functions (Fig. 1 shows it only for E1). All functions can have the capability to acquire information from the wider external environment
91
92
Marite Kirikova / Procedia Computer Science 104 (2017) 89 – 96
beyond the reach of F and R (in Fig. 1, for outlook simplification reasons, the "sensor" in external environment is shown only for E1). As mentioned above the framework is flexible with respect to the granularity of functions. For different enterprise there can be different structure of the functions. Larger enterprises may need the original structure of the framework while smaller companies may wish to integrate several functions. Also it has to be mentioned that each function in the framework itself can be represented with one of the possible variants of the FREEDOM framework (in a smaller scale)8. The framework is build so that that a constant information propagation from E1 towards M is possible. By this information the function on the left can set specific restrictions to the functions on the right. However, these restrictions are relative, and there can be a certain range of freedom for other functions where they do not depend on the engineered requirements, engineered fulfilment, design and implementation and operations. Among the others the following five cases can be mentioned: x
x x x x
While we are used to say that requirements change continuously, still, the strictly approved changes that require enterprise wide requirements and fulfilment engineering are less frequent than smaller adjustments at operational or design levels. Thus, the management can have a range of freedom even if other things in the enterprise do not change; i.e. the M function can be improved without changing the operations. This gives an opportunity to handle relationships with other enterprises in the environment more effectively, give better feedback, etc. O and M can be changed without changing the basic design of enterprise processes and information systems. This can provide more efficient management and operations, however, if add-on applications are made, this can harden the change process in future14,15 D, O and M can be changed without changing the portfolios and systems development approaches. This gives an opportunity to experiment with the designs and chose the best solutions for the given situation For the same set of initial requirements it is possible to define different E2, D, O and M in case the situation in the enterprise or its environment changes and requires different distribution of resources E1 at the enterprise level can change and correspondingly enforce new possibilities in E2. D, O and M
If the changes are done, they have to be forward propagated; i.e. if operations are changed, likely there will be changes in the management, and if designs are changed likely there will be corresponding changes in the operations. So we can say that the stable part of the functions is on the left of the point from which the independent changes can be done. It is necessary to note, that the freedom or independence with respect to the changes can cause high enterprise and information systems development complexity; e.g. independent changes made in D may cause problems when changes are introduced in the functions on the left of the freedom point, because of the misalignment that has been caused by the changes in the design. Moreover, there can be simultaneous relatively independent changes in E2, D, O and M. These possible simultaneous changes can cause the high complexity of the situation, which is hard to be handled if there are no appropriate F and R available. Handling of this complexity is hardly possible with pure top down approaches of systems engineering. Therefore the FREEDOM framework has information relationships (see Fig.1), which stays for such methods as "monitoring", "audit" and "analytics". To apply these methods, it is necessary to have means for having at least partly defined relationship between constituents of F and R and constituents of other functions of the FREEDOM framework. Consequently, taking into consideration that enterprise modelling is a part of F and R, the availability of appropriate enterprise models is essential. Taking into consideration that different ranges of freedom will be in force for different variants of granularity of the FREEDOM framework, there can be a high variability of the framework's variants. Nevertheless for each enterprise likely there will be one dominating variant of the framework. Assuming this, it is important to find appropriate enterprise models for F and R of the enterprise. In the next section the approach that allows defining enterprise model constituents for different variants of the FRREDOM framework is proposed. 3. The approach for selecting the enterprise model constituents This section is devoted to the question of the selection of enterprise model content for F and R functions of the FREEDOM framework. While there are different variants of the framework possible still these two functions (F and R) always are in their place, - the framework prescribes two representations of the enterprise: the envisioned future
Marite Kirikova / Procedia Computer Science 104 (2017) 89 – 96
representation (To-Be) and the representation of a current situation, i.e. reality (As-Is). What is included in these representations depends on a particular FREEDOM framework variant. We assume that as a minimum, the F and R should contain all information about the enterprise that is needed to perform tasks of other functions of the framework that use the information about the enterprise. For different variants of the framework the required information may be different. For instance, if the E1, E2 and D are merged, as it would be in agile approaches, the contents of enterprise models may be not as rich as it would be when using E1, E2 and D separately. We propose the following FREEDOM framework based approach for identifying constituents of enterprise models used for functions F and R of the framework: x Choose the FREEDOM framework variant with respect to the granularity of functions8 x Decide on the possible ranges of freedom (see explanation in Section 2) x Examine information flows from F and R with respect to the choices done in points 1 and 2 - select the scope of enterprise model elements according to the expected content of the information flows x On the basis of the content identified in Point 3, establish an enterprise meta-model that can amalgamate or integrate all identified elements The meta-model developed in Point 4 has to distinguish between As-Is and To-Be elements, to be useful for identifying gaps in the enterprise models for further developments. The gaps can be denoted similarly as it is done in ArchiMate6. We can also draw a parallel between work packages in ArchiMate and the tasks of E2 (fulfilment Engineering) of the FREEDOM framework. The difference is in that ArchiMate does not directly relate the content of the enterprise architecture to specific enterprise and information systems development approach for which a particular variant of the FREEDOM framework is chosen. The core of the proposed approach is Point 3 which requires to analyze E1, E2 ,D, O, and M (or integrated) functions of the chosen variant of the FREEDOM framework and identify all information item types or constituents of enterprise representation that are needed for practical realization of these functions (see Fig. 2).
Fig. 2. Identifying constituents of enterprise models.
The analysis of the functions can be based on practiced project management and systems development methods or particular knowledge bodies. In the next section we will discuss whether really different approaches, methods and knowledge bodies (and corresponding to them variants of FREEDOM framework) require variable (different) constituents of enterprise models for F and R functions of the framework, and how these constituents can be useful in FREEDOM framework monitoring, audit and analytics.
93
94
Marite Kirikova / Procedia Computer Science 104 (2017) 89 – 96
4. Towards variable set of enterprise model constituents To theoretically validate whether various combinations of enterprise model constituents will be obtained in different enterprise and information systems development settings, we analyzed several project management and systems development approaches and methods and several knowledge bodies of some standards relevant in systems engineering. When analyzing these approaches, methods, and standards, we paid attention to the artefacts mentioned in them. So far we have focused on artefacts related to only one function of the FREEDOM framework, namely, E1 requirements Engineering16. We assume that, if we know which artefacts are used in particular approaches, methods and standards with respect to requirements engineering, we can derive corresponding enterprise model constituents related to requirements engineering function. It should be noted here that other functions of the FREEDOM framework may suggest additional enterprise model constituents. Table 1 shows an excerpt of the results of analysis of enterprise architecture framework TOGAF5, RUP methodology17, BABOK18, IREB standard19 and SCRUM20. Taking into consideration that in different approaches similar or even the same artefacts are sometimes named differently, for the final use for enterprise model content definition, the artefacts have to be decomposed to smaller units to strictly understand their content. The table shows only a part of raw data, therefore, there are cases where the items partly overlap. In a particular row mark “X” is mentioned only in the cases when the descriptions of items of respective columns use exactly the same term as is displayed in the first column of the table in that row. There are cases when the term intuitively is covered by several rows; however, mark “X” is included only in the row of exact wording of the artefact. Table 1. Requirements related artefacts in TOGAF, RUP, BABOK, IREB, and SCRUM. Titles of the artifacts Training materials Business function model Business functions specifications Business goals Business rule model Business requirements Business processes representation Business indicators Work plan for realization stage Systems context documentation) Classification of documents Entity–relationship model for database Physical data model System Functions Specifications Definition (Criteria) of Done Sprint/product backlog Forms release model Change requests Configuration model The concept of storage system Team Application code Application component model Application installation plan User activity system model script User Interface Model Logical Data Model Organizational structure Requests from stakeholders Application architecture Application components specifications Software system specification System function model System functions a script model System Rules model
TOGAF
RUP
X X X
X X X X X
X X X
X
BABOK
IREB
AGILE
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
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 X X X X X X X
X X
X
X
95
Marite Kirikova / Procedia Computer Science 104 (2017) 89 – 96
Test example model Test software functionality model Test software component specification model Service-Function Catalogue
X X X X
X X X
X X X X
Despite the data is row, the preliminary results can give some insights in what are the expected enterprise models for the FREEDOM framework variants. It is not a surprise that all columns consider business goals, business process representation, data, and performers (both the performers of organizational tasks and implementers of information systems changes). From this we can conclude that any enterprise model has to have these four models. However, in Table 1 these four constituents (shown in italic) are the only items that are covered by all columns. In all other cases some differences are seen. This, at least for the requirements Engineering function (E2) assures that the enterprise model constituents will be different for specific enterprise and systems development setting. There are also the following artefacts, for which it is not clear how exactly they should be related to enterprise models: x In the lists of artefacts there are documents of different plans for different stages of systems development (see as an example two shaded items in the upper part of Table 1) x Among the other artifacts there are also artifacts related to testing (see as an example three shaded items at the bottom part of Table 1) Another question to be answered is whether the fact that the enterprise models correspond to the artefacts used in a particular enterprise and systems development setting can facilitate the application of the framework analytics activities. Taking into consideration, that the analysed artefacts are related to requirements engineering function, we consider here the related fork on application of analytics in requirements engineering. This gives an opportunity to cross check whether the relationship between analytics activities and detected constituents of enterprise models can be established. The following requirements engineering analytics activities have been reported in the related work: x Analytics based on software development indicators. From this we can learn that the analytics in D function of the FREEDIM framework can be useful. This work does address the E1 function only partly, nevertheless some of the indicators mentioned in the article such as, e.g. "responsible people", correspond to the artefacts identified in Table 1 x Web analytics that refers to the use of data about website usage. This analytics activity supports E1 with respect to environment analysis; however, it does not provide information that would be applicable for evaluation of variants of enterprise models x Visual analytics related to requirements structure. This approach would have a potential for providing models of the analytics based on the constituents of the enterprise models thus aligning the analytics model to the appropriate variant of the enterprise model x An overview of visual analytics methods for requirements engineering refers to several approaches of visualization that take into consideration also the enterprise model constituents corresponding to items reflected in Table 1 The analysis of artefacts as the base of constituents of the enterprise models used in the FREEDOM framework, and brief analysis of related work in requirements analytics allows seeing that for different enterprise and information systems development settings, various appropriate enterprise models are needed. Existence of these models might be helpful for identifying the gap between the current and future situations without waste of time and without missing relevant constituents of the model. The enterprise models with appropriate constituents would help to develop the analytics models easier and thus support the enterprise development by effective requirements analytics and monitoring. We can assume that appropriately chosen variants of enterprise models would be helpful also for auditing the requirements (e.g. in requirements walkthroughs sessions). 5. Conclusion While the enterprise modelling is a well established discipline1, still, in real life situations, there are problems in the application of enterprise models. In this paper we propose the approach for selecting enterprise models with such constituents that correspond to particular enterprise and information systems development settings. The variability of the settings (and respectively - variants of enterprise models) is illustrated using the FREEDOM
96
Marite Kirikova / Procedia Computer Science 104 (2017) 89 – 96
framework. The framework was initially established for purposes of continuous requirements engineering and, additionally to its main functions, incorporates monitoring, audit and analytics activities. The first experiments with the proposed approach show that, while it is evident that there are the differences in required enterprise models, there are also particular constituents that are present in all analyzed cases, namely business goals model, business process model, data model, and the representation of the team which is the change agent. Future work includes deeper analysis with respect to other functions of the FREEDOM framework and practical experiments with the approach in different enterprise and information systems development settings. Acknowledgements The work is supported in part by the Latvian National research program SOPHIS under g. a. Nr.10-4/VPP-4/11. References 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20.
Seigerroth U. The Diversity of Enterprise Modeling – a Taxonomy for Enterprise Modeling Actions. Complex Systems Informatics and Modeling Quarterly. 4; 2015. p. 12–31. Oemig C. When Analysts turn into Boxers: An Introduction to Pre-Sales Requirements Engineering. Complex Systems Informatics and Modeling Quarterly. 3; 2015. p. 1-14. Sandkuhl K et al. Enterprise Modeling Tackling Business Challenges with the 4EM Method. Springer; 2014. Yu E. Modeling organizations for information systems requirements engineering. In: Proceedings of IEEE International Symposium on Requirements Engineering; 1993. p. 34–41. TOGAF 9.1. Part II: Architecture Development Method (ADM). Available: http://pubs.opengroup.org/architecture/togaf9doc/arch/chap05.html. The Open Group. ArchiMate. 2.0-3.0 Specification. Available: https://www2.opengroup.org/ogsys/jsp/publications/ PublicationDetails.jsp?publicationid=12480. Kirikova M. Continuous Requirements Engineering in FREEDOM Framework: a Position Paper. 22nd International Conference REFSQ 2016. Vol. 1564; 2016. Kirikova M. Towards Framing the Continuous Information Systems Engineering. Joint Proceedings of the BIR 2016. Available: http://ceur-ws.org/Vol-1684/. Weber H. Continuous engineering of information and communication infrastructures. FASE 99. LNCS 1377; 1999. p. 22–29. Finlay S. Predictive Analytics, Data Mining and Big Data: Myths, Misconceptions and Methods. Springer; 2014. Richter M, Fluckiger M. User-Centred Engineering. Springer; 2014. Kaiser B et al. Contract-Based Design of Embedded Systems Integrating Nominal Behavior and Safety. Complex Systems Informatics and Modeling Quarterly. 4; 2015. p. 66–91. Schmitt C, Liggesmeyer P. Getting Grip on Security Requirements Elicitation by Structuring and Reusing Security Requirements Sources. Complex Systems Informatics and Modeling Quarterly. 3; 2015. p. 15–34. Alksnis G et al. Enabling Support of Collaborative Cross-enterprise Business Processes for Legacy ERP Systems. Complex Systems Informatics and Modeling Quarterly. 2; 2015. p. 1-18. Silic M et al. Influence of Shadow IT on Innovation in Organizations. Complex Systems Informatics and Modeling Quarterly. 8; 2016. p. 68-80. Sirokovs A. Requirements Engineering Artefacts. Master Thesis Report No. 2. Riga: RTU; 2016. (in Latvian). Rational Unified Process Best Practices for Software Development Teams. Available: https://www.ibm.com/developerworks/rational /library/content/03July/1000/1251/1251_bestpractices_TP026B.pdf. BABOK Guide – IIBA. Available: http://www.iiba.org/babok-guide.aspx. IREB standards. Available: https://www.ireb.org/en. SRUM Guides. Available: http://www.scrumguides.org.
Marite Kirikova is a Professor in Riga Technical University, Latvia. She has more than 150 publications on the topics of Requirements Engineering, Business Process Modelling, Knowledge Management, and Systems Development. She has done field work at Stockholm University, Copenhagen University, Denmark, and Boise State University, USA. Currently in her research she focuses on information systems design in the context of agile and viable systems paradigms. Contact her at [email protected].