Constructing an Information Model for Application ... - CEUR-WS.org

Constructing an Information Model for Application Landscape Management Sabine Buckl, Alexander M. Ernst, Florian Matthes, Christian M. Schweda Software Engineering betrieblicher Informationssysteme Technische Universit¨ at M¨ unchen Boltzmannstraße 3, 85748 Garching

Abstract. The managed evolution of the application landscape is commonly regarded a focal point of enterprise architecture (EA) management. Therein, aspects of future planning and historization apply, for which no generally accepted information model yet exists. This paper addresses this challenge by identifying requirements regarding an information model for temporal application landscape management from an extensive survey, during which the demands from practitioners and existing tool support for EA management were analyzed. Furthermore, we discuss shortcomings of existing approaches to landscape management in literature and propose an information model, which can address the identified requirements via modeling techniques from nearby disciplines.

1

Introduction

Enteprise Architecture (EA) management is a topic many companies are currently addressing or planning to address in the nearby future. As a consequence of the demand from practice, a multitude of approaches to EA management has been proposed in academia [3, 9], by standardization bodies [15], or practitioners [13]. These approaches differ widely concerning the coverage of EA management aspects – for a comprehensive comparison see e. g. [1]. Nevertheless, most of them agree on the application landscape (application layer ) being an important management asset [1, 14]. Notwithstanding, the level of abstractness and granularity of information needed to perform EA management differs between the various approaches. As a consequence, different information models1 defining the structure of the respective EA documentation are used. Information modeled in accordance to these models is utilized to provide EA management decision support, e.g. via analyses or visualizations. Decision making as part of the management process should not be considered a one-time task, but is repeated, as the management process enters a new cycle of Plan, Do, Check, and Act [6]. This emphasizes on the importance of historization of management decisions. While some EA management approaches from literature account for this fact (cf. Section 3), the presented information models 1

Consistent to the terminology as used e. g. in [4], we call the meta model for EA documentation an information model.

Proceedings of CAiSE Forum 2009

55

do not reflect this adequately as historization specific concepts are not provided. This lack of support leads to the research question addressed in this article: How should an information model for landscape management be designed respecting both business and IT aspects, and supporting future planning and historization of decisions? The remainder of the article is structured as follows: Section 2 provides detailed requirements for a temporal information model. Section 3 gives an overview on approaches to landscape management. An information model fulfilling the requirements is introduced in Section 4. Section 5 summarizes the paper and sketches interesting directions for future research.

2

Elicit requirements for landscape management

The research question from above leads to a distinction between three different types of landscapes, which are of importance in the context of future planning: – the current landscape, reflecting the landscape at a given point in time, – planned landscapes, which are derived from planned projects for transforming the landscape until a certain point in time, and – the target landscape, envisioning an ideal landscape state to be pursued. Information on these landscapes should adequately be described and maintained in a single and consistent model for the EA, which also accounts for the close relationships between application landscape and project portfolio management. These management tasks are related via planned landscapes, which should be derived from the transforming projects selected in a project portfolio. Thereby, analyses of the application landscape can be used to provide decision support. This also leads to aspects of time-dependency, as planned and target landscapes may evolve over time, such that different (historic) states thereof may exist. Additionally, the idea of variants for planned landscapes resulting from the selection of different project portfolios has to be considered. Summarizing, three different dimension of distinction for landscape management exist: – firstly, a landscape is planned for for a specific time, – secondly, a landscape is modeled at a certain point in time, and – thirdly, different landscape variants of a planned landscape may exist. Application landscape management has been a topic of the Enterprise Architecture Management Tool Survey 2008 [12] – a survey on the capabiltities of current EA management tools. The evaluation criteria of the survey were developed in cooperation with 30 industry partners and describe EA management related tasks from a practitioners point of view. The core concern of each task is given in the survey and is further detailed to fine-grained questions. Exemplary questions in the context of landscape management read as follows [12]: Proceedings of CAiSE Forum 2009

56

– What does the current application landscape look like? Which business applications support which business process at which organizational unit? – How is, according to the current plan, the application landscape going to look like in January 2010? From there the following requirements for an information model for application landscape management can be derived (for more details on the derivation see [5]). Such a model must: R1 contain a ternary relationship in order to support analyses regarding current and future business support, R2 allow to envision business support providers in order to facilitate target landscape planning without having to specify implementation details, R3 support the deduction of future landscapes from the project tasks, which execute the transition from the current to the future business support, R4 ensure the traceability of management decisions by storing historic information of past planning states, and R5 foster the creation of landscape variants based on distinct project portfolios in order to tightly integrate project portfolio management activities.

3

Related work

Subsequently, we briefly introduce selected approaches to landscape management and emphasize on their coverage of time-related aspects. In [2], Braun and Winter present the application landscape as the set of an enterprise’s business applications and their interdependencies. Respectively, the information model contains the classes application and interface. These concepts from the application layer can be connected to elements from the organizational layer, i.e. the business processes in order to describe the provided business support. Nevertheless, the model does not account for analyses with more than one organizational unit involved, as the question where the business support takes place is not discussed. In addition, time-dependence and project-dependence are only partially addressed in the information model. In the systemic enterprise architecture methodology (SEAM) [11] ways to document and analyze EAs are discussed. The approach focuses on multi-levelmodeling from enterprise down to component level. The importance of traceability is emphasized, although not targeting temporal traceability but inter-level traceability of relationships. The approach further introduces the more abstract concept of the computational object, effectively replacing the business application. Nevertheless, time-depedency or project-dependency are not alluded to. Jonkers et al. present in [9] a language for enterprise modeling, targeting the three layers of business, application, and technology. The concepts on the different layers can be used to model the current application landscape, especially the business support provided by applications via interfaces. The approach further refines the description of the business support via the concepts of business- and application-services. These concepts can be used to describe the existence of a Proceedings of CAiSE Forum 2009

57

support without having to specify the application actually responsible for the support. Thereby, target landscape planning is facilitated, while neither planned landscapes nor projects are in the scope of the presented language. The approach of multi-perspective enterprise modelling (MEMO) (see e.g. [8]) explicitly accounts for the modeling of concepts, like business applications, in their context, described via organizational units and business processes. The respective modeling language concerned with IT aspects is the IT modeling language (ITML) [10]. According to the reference process described as complementing the language, these concepts should not only be used for documentation, but also for landscape planning. Nevertheless, projects are not part of the model, which also does not explicitely account for issues of time-dependence. The Open Group Architecture Framework (TOGAF) [15] provides a cyclic model for the EA management process called Architecture Development Method consisting of distinct management phases. The phase architecture vision is concerned with the development of a target architecture, which is operationalized via a series of intermediate transition architectures, i.e. planned landscapes. The information model of TOGAF puts special emphasis on architecture constituents – projects are only included on a very abstract level and are not linked to the affected architecture concepts. Time-dependency is also not alluded to.

4

Developing a temporal information model

Before we present an information model, which fulfills the requirements from Section 2, we introduce and define the core concepts relevant in application landscape management in an informal way. Business application A business application refers to a deployment of a software system at a distinct location. In landscape management, the business applications are limited to those software systems, which support at least one business process. Business process A business process is defined as a sequence of logical, individual functions with connections in between. A process here should not be identified with a single process step. It should be considered a coarse grained process at a level similar to the one used in value chains. Business support provider A business support provider refers to an concept providing support for a business process. This concept is not planned in detail but is part of a target landscape vision. Organizational unit An organizational unit represents a subdivision of the organization according to its internal structure. An organizational unit is a node of a hierarchical organization structure, e.g. a department or a branch. Project Projects apply changes to the application landscapes and are scheduled by different temporal properties [7], i.e. their startDate and endDate. Further, projects are plannedAt respectively removedAt certain points in time referring to the time of their creation or deletion. This effectively results in a period of validity assigned to each project. Proceedings of CAiSE Forum 2009

58

Fig. 1. Information model satisfying the requirements from Section 2

The aforementioned concepts are used in the information model for application landscape management shown in Figure 1. This information model utilizes the stereotype to indicate, that instances of the respective concepts can be introduced, migrated, or retired by project tasks – for details see on the stereotype see Figure 2 and [5].

Fig. 2. Pattern explicating the relationships of a concept

5

Summary and outlook

This article motivated the importance of modeling time- and project-dependencies of application landscapes as part of a holistic EA management approach, and detailed requirements for modeling these dependencies. We showed, that current EA management approaches do not adequately consider this topic. Finally, we briefly presented an information model addressing the these requirements. With this information model at hand, we point to two interesting directions for future research. On the one hand, the information model has yet not been applied in a practial EA management endeavor, such that we could not assess the Proceedings of CAiSE Forum 2009

59

complexity of its usage. On the other hand, application landscape management is not the only EA related management process, which has time- and projectdependencies. It would hence be interesting to analyze, how the model presented can be applied in the context of other management processes. There also the question arises, if a time- and project-dependency EA management pattern [3] can be abstracted from the solution presented above.

References 1. S. Aier, C. Riege, and R. Winter. Unternehmensarchitektur - Literatur¨ uberblick und Stand der Praxis. Wirtschaftsinformatik, 50(4), 2008. 2. C. Braun and R. Winter. A comprehensive Enterprise Architecture Metamodel. In J. Desel and U. Frank, editors, Enterprise Modelling and Information Systems Architectures 2005, volume 75 of LNI, pages 64–79. GI, 2005. 3. S. Buckl, A. M. Ernst, J. Lankes, and F. Matthes. Enterprise Architecture Management Pattern Catalog (Version 1.0, February 2008). Technical report, Chair for Informatics 19 (sebis), Technische Universit¨ at M¨ unchen, Munich, 2008. 4. S. Buckl, A. M. Ernst, J. Lankes, F. Matthes, C. Schweda, and A. Wittenburg. Generating Visualizations of Enterprise Architectures using Model Transformation (extended version). Enterprise Modelling and Information Systems Architectures – An International Journal, 2(2), 2007. 5. S. Buckl, A. M. Ernst, F. Matthes, and C. A. Schweda. An Information Model for Managed Application Landscape Evolution. Journal of Enterprise Architecture (JEA), 2009 (to be published). 6. E. W. Deming. Out of the Crisis. MIT Press (MA), 1982. 7. M. Fowler. Analysis patterns: Temporal property. http://martinfowler.com/ ap2/temporalProperty.html (cited 2008-11-25), 2008. 8. U. Frank. Multi-perspective Enterprise Modeling (memo) – Conceptual Framework and Modeling Languages. In Proceedings of the 35th Annual Hawaii International Conference on System Sciences 35, pages 1258–1267, 2002. 9. H. Jonkers, L. Goenewegen, M. Bonsangue, and R. van Buuren. A Language for Enterprise Modelling. In M. Lankhorst, editor, Enterprise Architecture at Work. Springer, Berlin, Heidelberg, New York, 2005. 10. L. Kirchner. Eine Methode zur Unterst¨ utzung des IT-Managements im Rahmen der Unternehmensmodellierung. PhD thesis, Universit¨ at Duisburg-Essen, Berlin, 2008. 11. L.-S. Le and A. Wegmann. Definition of an Object-oriented Modeling Language for Enterprise Architecture. System Sciences, 2005. HICSS ’05. Proceedings of the 38th Annual Hawaii International Conference on, pages 179c, 2005. 12. F. Matthes, S. Buckl, J. Leitel, and C. M. Schweda. Enterprise Architecture Management Tool Survey 2008. Chair for Informatics 19 (sebis), Technische Universtit¨ at M¨ unchen, Munich, 2008. 13. K. D. Niemann. From Enterprise Architecture to IT Governance – Elements of Effective IT Management. Vieweg+Teubner, 2006. 14. M. Pulkkinen. Systemic Management of Architectural Decisions in Enterprise Architecture Planning. Four Dimensions and Three Abstraction Levels. System Sciences, 2006. HICSS ’06. Proceedings of the 39th Annual Hawaii International Conference on, pages 179c, 2006. 15. The Open Group. TOGAF ”Enterprise Edition” Version 9. 2009. Proceedings of CAiSE Forum 2009

60