An Enterprise Architecture Framework for Application ...

An Enterprise Architecture Framework for Application Consolidation in the Swedish Armed Forces Ulrik Franke and Pontus Johnson Industrial Information and Control Systems Royal Institute of Technology 100 44 Stockholm, Sweden {ulrikf, pj101}@ics.kth.se

Abstract—In this paper, application consolidation using Enterprise Architecture methods is considered, with an ongoing project in the Swedish Armed Forces as the point of departure. The decision-making features of application consolidation are first analyzed and formalized from the perspective of decision theory. Applying these insights, a more practical framework is then proposed, based primarily on the ISO/IEC 9126 standard, the Ministry of Defence Architecture Framework (MODAF), and the formalism of Probabilistic Relational Models (PRM). This framework supports cost-benefit analysis of application consolidation decision-making, thus helping to make these decisions more structured and transparent. Keywords-Application consolidation, Enterprise Architecture, Probabilistic Relational Models, ISO/IEC 9126, MODAF

I. I NTRODUCTION With increasing competition, smaller budgets and growing cost-awareness, consolidation projects have recently become popular among enterprise IT decision makers. Indeed, to ”help manage IT portfolio” has been identified as one of the top reasons for using Enterprise Architecture in large corporations [1]. In [2], IT consolidation features as one of the application scenarios frequently encountered in industrial use of Enterprise Architecture, and [3] identifies consolidation as one of the recent trends in enterprise level IT. This work is partly spawned by this general trend, but is also part of an ongoing research project in co-operation with the Swedish Armed Forces. The Swedish Armed Forces of today face a large number of challenges. There is an intense work on developing and strengthening financial management and control. The personnel provision is being re-made to create an all voluntary force, resulting in new challenges for officer training and soldier recruitment. Other challenges are found in the areas of training and deployment of units, command and control, logistics, and the structure of the supporting government agencies [4]. Naturally, these changes carry over to the IT area. To maximize efficiency and support to the core business, and to minimize cost, a number of IT related projects and programs have been initiated. One is the use of Enterprise Architecture, where Sweden works closely together with the United Kingdom in the development of the Ministry of

Defence Architecture Framework (MODAF). Another area is the PRIO system, an SAP solution recently taken into service to manage economy, HR, and logistics within the Armed Forces [5]. A third area is an application consolidation initiative, aiming to restructure the application landscape of the Armed Forces and – ultimately – cut costs. It is this initiative that the present work primarily aims to support. There is also a drive towards more service orientation in the Swedish Armed Forces. For example, the service orientation of MODAF since version 1.2 is largely due to the bilateral collaboration between the UK and Sweden. However, restructuring a large and diverse application landscape into the service-oriented paradigm is not easy. The present application consolidation project will have a crucial role in enabling a greater service-orientation, by documenting and eventually transforming the application landscape in order to make it more efficient and more transparent. The remainder of this paper is structured as follows. Section II contrasts the present contribution with some related work in the field of application consolidation. In section III, a general model of application consolidation decision-making is developed. This model is then applied in the two subsequent sections. Section IV deals with how to get good estimates of the data needed for application consolidation decision-making. Section V deals with the problems arising when dealing with intertwined application landscapes. These three sections are the locus of the main contribution, and in the end of section V, a practical and applicable framework for rational application consolidation decision-making is described. Section VI illustrates the framework with an example. Some concluding remarks are given in section VII. II. R ELATED WORK Many sources, such as [1], [2], [3] proclaim the importance of application consolidation, but considerably fewer provide practical guidelines and methods. Some application consolidation studies use elaborate models to simulate the behavior of future application landscapes, thus guiding decision-making. In [6], a mathematical model

is presented that predicts the impact of application consolidation on transaction response times, accurate to within a few percent. Similarly, [7] presents a framework for performance evaluation in the area of server consolidation. However, while very detailed, such frameworks are also limited. Typically, these simulations address single system qualities (such as performance) and achieve accuracy in these at the cost of generality; leaving other system qualities (such as availability, security etc.) out. Also, the notion of monetary cost is usually underdeveloped. Articles with an economics or accounting perspective naturally address the notion of cost in-depth. For example, [8] asks whether consolidation of back-office operations in banks really reduces operating costs. A thorough model is built, based on 1979-1996 data from the US Federal Reserve’s consolidation of its Fedwire electronic funds transfer system. However, such studies are not very applicable for the decision-maker embarking on a consolidation project. [9] looks at enterprise IT costs from an accounting perspective, and gives good examples of tracking and breakdown of costs. These insights are valuable and are put to use in the present article. However, [9] has too much cost focus and treats the benefits provided by the IT too shallowly. The present contribution aims to find a suitable balance between the technical and the cost perspectives as found in the literature, employing Enterprise Architecture methods. III. A GENERAL MODEL OF APPLICATION CONSOLIDATION DECISION - MAKING Today, most enterprises and business processes are supported by information systems. Most often, these information systems are interconnected into complex application landscapes, where it is not obvious which applications support which business processes, nor whether there is redundancy among the systems or the information they process. Application consolidation is an optimization of the application landscape, primarily by removing unnecessary applications. Some consolidation benefits commonly cited are (i) lower total cost of ownership, (ii) improved service levels and availability, and (iii) reduced business risks [7]. A decision maker managing an application consolidation project wants to save money, but still keep the benefits delivered by the applications on the same, or possible even on a higher, level. How should this problem be modeled? Using the framework of decision theory [10], it is possible to express it in terms of a cost-benefit analysis. Each application in the enterprise must then be identified with a cost and a utility. Some costs and utilities of applications are easy to find, such as the income from services sold to customers, or the license and electricity costs. Others are less easy to define and measure, such as the usability of an application or the customer satisfaction generated by high-availability services. Nevertheless, to make as rational decisions as possible, these costs and utilities should, preferably, all be weighed together.

Maintain u = u M − cM OP u: uu u u uu uu u uu Develop uM D D u u u = u − cD OP − cCAP uu 4 j u j u jjj uu uu jjjjjjjD u uu jjj Application decision II UUUU II UUU UU U II II II P UUUUUUU II * II Phase out RII u = −cP CAP II II II II II $ Replace P R u = uR − cR OP − cCAP − cCAP Figure 1.

Application consolidation decision-making.

First, consider the costs. Costs are often divided into two parts: (i) capital expenditures (CAPEX), i.e. one-time costs of procuring or developing an application, and (ii) operating expenditures (OPEX), i.e. on-going costs for running an application. Thus, when an application is left unchanged, the CAPEX is zero. We call this alternative to maintain the application. Conversely, in the case where an application is phased out completely, its OPEX afterwards is zero. We call this alternative to phase out the application. Clearly, maintain and phase out are extremes. In between are two more decisions. The first one is to develop an existing application. This means accepting a capital expenditure either to decrease future operating expenditure, or to increase the application utility. The second one is to replace an existing application. This means that one application is phased out, and another takes its place. Here, the capital expenditure consists of two parts; first, the phase-out cost of the old application, second, the phase-in cost of the new one. The operating expenditure in all cases will be that of the application running after implementation. The model proposed in Fig. 1 illustrates these four decisions. Depending on the action taken, one of four different outcomes will obtain. For each of the actions, there is some utility to be gained, and some costs to be carried, as depicted in Table I. The goal, of course, is to maximize utility, viz. the utility delivered by an application minus its cost. The problem is that at decision time, the real posterior utilities u and costs c are not available. Rather, they must be replaced by a priori estimates u ˆ and cˆ, used by the decision maker to be able to make a rational decision. In the next section,

Table I VARIABLES IN THE MODEL OF APPLICATION CONSOLIDATION DECISION - MAKING .

Utility Maintain Develop Phase out Replace

uM uD uR

Costs OPEX CAPEX cM OP cD cD OP CAP cP CAP R cOP cR CAP

we will get back to the issue of these estimates, and how we can address it. Given estimates u ˆ and cˆ, however, the naive decision maker’s problem for an application portfolio of n applications is then simply to pick the best of the four alternatives in each of the n cases, considered by itself:   u î (M ) = u ˆM − cˆM   OP     D D D u ˆ (D) = u ˆ − c ˆ − c ˆ i OP CAP argmax P {M,D,P,R} u î (P ) = −ˆ cCAP       P R − c ˆ − c ˆ u î (R) = u ˆR − cˆR CAP CAP OP However, this holds only if the applications can be evaluated independently of each other. This is, of course, rarely the case. Rather, a major rationale for application consolidation is the inherent complexity of intertwined applications. Thus in the general case, the utilities and cost of an application i are a function of all the other systems. This leads not to n independent simple maximization problems as above, but rather to a single much larger optimization problem made up of n coupled components. The fact that the problem inevitably exhibits a great degree of interdependencies indicates the need for a more holistic approach. The next sections outline such an approach. IV. E STIMATION OF UTILITIES AND COSTS To solve the problem described in section III, two issues need to be addressed. First, reliable estimation techniques must be used for the utilities u ˆ and costs cˆ. Second, the complexity of the many interconnections needs to be managed. A good framework requires both components. In this section, the estimation aspect will be addressed. To do so, we use the functional/non-functional dichotomy, known from software engineering [11]. Functional requirements describe application functions; its processing and displaying of data. Non-functional requirements describe how well such functions are carried out, e.g. throughput, and other non-functional properties, e.g. application availability. A. Estimating non-functional utilities Figure 2 displays the structure of the ISO/IEC 9126 standard [12]. The concepts used in this standard are a good starting point for the non-functional utility estimates. However, the nature of application consolidation decisionmaking makes it futile to expect to be able to use the

standard in full as defined in the three technical reports [13], [14], [15] accompanying the official standard document. The reason for this should be obvious: the need for application consolidation only arises when the application landscape is large, unruly, and difficult to observe in detail. So by definition, the letter of the detailed definitions of the ISO/IEC 9126 are ruled out. Its spirit can still be used, though. What can be achieved are, again, estimates. To choose suitable estimates, we loosely adhere to the model for choosing software assessment measures presented in [16], a method emphasizing the trade-off between precision and cost. In particular, a useful class of operationalizations are relative measures that relate requirements to measurements. To give an example, consider the reliability factor in the ISO/IEC 9126 standard. By the standard, it is broken down into (i) maturity, (ii) fault tolerance, (iii) recoverability, and (iv) reliability compliance. Each of these is itself broken down into metrics, such as estimated latent fault density, calculated by counting ”the number of faults detected during a defined trial period and predict potential number of future faults using a reliability growth estimation model” [13]. Again, such a detailed model cannot be applied to an application landscape in the hundreds or thousands, where the exact number of applications might not even be known, much less hundreds of applications characteristics on latent fault density. Instead, we operationalize a notion of availability, where stakeholders define an availability requirement. This requirement is then compared to the actual availability, as estimated by the users. While this is certainly a less precise measure than the one advocated in the ISO/IEC 9126 standard, it has three important benefits that makes it suitable for decision-making on application consolidation: Simplicity It is simple enough to be feasible to collect throughout a large application landscape. As it is put in [9]: ”The key is to avoid allowing the details to drown the analysis: understand the strategic questions up front and focus only on gathering the information necessary to answer those questions.” Separation of concerns The requirements are usually collected at one place in the enterprise, whereas the data needed to determine whether these requirements are fulfilled or not is generally collected at another. This aims to minimize the impact of self-serving bias and organizational rivalry on the quality of the assessment. Contextuality It firmly connects the application quality investigated to specific application requirements. In this way, we sidestep the question of what constitutes high or low availability in an objective sense, and are fully content to let this be contextual. This method of contrasting requirements with fulfillments can be used not only in the case of availability, but in the

Figure 2.

The structure of the ISO/IEC 9126 Software engineering – Product quality standard, adapted from [12].

Table II A PPLICATION QUALITIES OPERATIONALIZED USING THE REQUIREMENTS / FULFILLMENT TECHNIQUE .

Quality Business criticality Availabilty Information correctness Information security Response time Usability Throughput

Scale {Low, Medium, High} {None, Low, Medium, High, Very high} {Low, Medium, High } {Restricted, Confidential, Secret, Top secret} {1ms, 1s, 1min, 1h} {Low, Medium, High} {Low, Medium, High}

case of many other systems qualities as well. Table II lists the qualities thus operationalized in the present framework. This operationalization entails a simple relation for setting the final verdicts on an application quality, viz.  if actual x level  satisfactory ≥ x requirement Application quality x is  unsatisfactory otherwise B. Estimating functional utilities The ISO/IEC 9126 is generic insofar that it considers general software qualities. However, no standard is capable of accurately capture the actual utility that a particular software application can bring to a certain business. Assessing the actual contribution of a software application to a business is difficult. Again, however, our framework attempts to achieve the three properties listed in the previous subsection – simplicity, separation of concerns, and contextuality. The basic idea is the following: the degree to which a given application supports the business activities of an enterprise should not be assessed by any single stakeholder. In particular, the application users – who might be spread out in many different business processes – should have a relatively large say compared to the application owners,

i.e. the executives who have the formal but not always real responsibility for the system, even if the latter might be easier to interview. However, the fact that a single application most often supports multiple business processes – even more so in a service-oriented environment – hints that this is not only a matter of estimation, but also of complexity. More details on the proposed solution will thus be given below, in the context of complexity management. C. Estimating costs As described in section III, the following cost estimates are needed for application consolidation decisions: operating expenditures (OPEX) for an existing application (ˆ cM OP ), D R OPEX for future systems (ˆ cOP and cÔP ), and capital expenditures (CAPEX) in the form of development cost (ˆ cD CAP ), P R cCAP ). replacement cost (ˆ cCAP ), and phase-out cost (ˆ Out of these, the OPEX for an existing application (ˆ cM OP ) is by far the simplest, since the present OPEX for the application are known. Given the rule-of-thumb nature of application consolidation decision making, it is fully sufficient for most purposes to simply approximate using the values from the previous accounting period, possibly by linear extrapolation or similar standard techniques. As for the OPEX of a future application (ˆ cR ˆD OP and c OP ), the estimation is slightly more challenging. In the case where the future application is well-known, e.g. if another instance is already running somewhere in the enterprise, this information can be used. If not, the best data available must be put to use. It should be noted that one important aspect to this issue is the requirements engineering phase of ordering the new application. If the application is procured and developed by an external company, requirements on future maintenance needs should be part of the agreement. Similarly, if the new application is procured as a service, appropriate service level agreements (SLAs) play an important role in keeping future

of the particular application under consideration. Indeed, this is where estimation meets complexity, i.e. where the inter-application couplings identified in section III become a prominent part of the analysis. The management of this problem is the topic of the next section.

◊ Number of locations ◊ ◊ ◊ •

•

•

V. M ANAGING COMPLEXITY † No of connections

Legend: ◊ Quality of platform

◊ Collected attribute

◊ Quality of ◊

† Structural attribute • Calculated attribute

Figure 3. Dependencies for development (ˆ cD cR CAP ), replacement (ˆ CAP ), and phase out costs (ˆ cP ). CAP

In order to manage the problems of complexity, construed as those interaction effects between applications that arise because of different kinds of interconnections and dependencies, two tools will be used. First probabilistic relational models, a mathematical formalism for probabilistic descriptions of entities connected to each other. Second, the Ministry of Defence Architecture Framework, MODAF, an Enterprise Architecture framework developed by the British Ministry of Defence in close co-operation with other partners, such as Sweden. A. Probabilistic relational models

OPEX under control. Turning to CAPEX, Fig. 3 illustrates some reasonable assumptions on the behavior of the development (cD CAP ), P replacement (cR CAP ), and phase out costs (cCAP ). Basically, the idea is that different factors drive the costs for development of existing systems on the one hand, and replacement and phasing-out of systems on the other hand, and that these factors (size, complexity, etc.) can be estimated with the rather simple indicators used in the figure. In the figure, bolder arrows illustrate stronger influences. Prominent cost drivers in development project are the quality of the platform (e.g. operating system, networking features, etc.), the quality of code documentation, and the development paradigm used [17]. These factors, of course, can be expected to impact the phase-out cost as well, but to a lesser extent, since the need to fully grasp the details of an application being removed is less than that of one to be modified. The impact of these factors on the replacement cost, however, can be approximated to zero, as they concern the old application (recall though, that under the Replace scenario, both the replacement and the phase-out costs have to be payed). Conversely, the number of sub-organizations using an application, its number of actual users, and their usage frequency are factors that can be expected to have a significant impact on the replacement and phase-out costs, as these factors greatly affect the size and scope of such undertakings. Another factor increasing the size and scope of such projects is the number of connections to other systems. Naturally, many interconnections to other systems make a replacement or a removal of an application much more complicated, because the repercussions throughout the entire application landscape become more difficult to predict and manage. The notion of application interconnections hints that this estimation problem goes beyond the individual qualities

Bayesian networks are a mathematical formalism for reasoning under uncertainty, employed in many applications in recent years [18]. However, Bayesian networks are illsuited to cope with domains where the set of entities and relationships is not determined in advance. The realm of SOA is a prime example of such an ever-changing domain of reasoning. Bayesian analysis of such domains is the rationale for probabilistic relational models (PRMs) [19]. The PRM structure adds the concept of entities with attributes and relationships to the probabilistic framework of Bayesian networks. As succinctly put in [20], PRMs ”are to Bayesian networks as relational logic is to propositional logic”. A PRM specifies a template for a probability distribution over an architecture model. The template describes an architecture metamodel, and the probabilistic dependencies between attributes of the architecture objects. A PRM, together with an instantiated architecture model of specific objects and relations, defines a probability distribution over the attributes of the objects. The probability distribution can be used to infer the values of unknown attributes, given evidence of the values of a set of known attributes. An architecture metamodel M describes a set of classes, X = X1 , . . . , Xn . Each class is associated with a set of descriptive attributes A(X) and a set of reference slots R(X). For example, a class System might have the descriptive attribute Size, with domain {large, small}. A class Documentation might have a reference slot Describes whose range is the class System. An architecture instantiation I (or an architecture model) specifies the set of objects in each class X, the values for the attributes, and the reference slots of the objects. We also define a relational skeleton σr as a partial instantiation specifying objects and reference slots, but not attribute values.

x∈σr (X) A∈A(x)

where σr (X) are the objects of each class as specified by the relational skeleton σr . A PRM thus constitutes a formal machinery for calculating the probabilities of various architecture instantiations. This allows us to infer the probability that a certain attribute assumes a specific value, given some (possibly incomplete) evidence of the rest of the architecture instantiation. In addition to expressing and inferring uncertainty about attribute values as specified above, PRMs also provide support for specifying uncertainty about the structure of the instantiations. A more detailed description of this topic is, however, beyond the scope of the paper. B. The Ministry of Defence Architecture Framework MODAF, the Ministry of Defence Architecture Framework, is designed to support the creation of an enterprise architecture for the British Ministry of Defence [21]. In addition to the UK, MODAF is used by the Swedish Armed Forces and the Swedish Defence Materiel Administration in their architecture efforts. As MODAF is originally based upon version 1 of its U.S. counterpart DoDAF, the Department of Defense Architecture Framework, the two frameworks are closely related. Nevertheless there are significant differences. DoDAF defines four different views of its core architecture data model, CADM, viz. the Operational,

Figure 4.

STRATEGIC Views OPERATIONAL Views SERVICE-Orientated Views SYSTEM Views

ACQUISITION Views

TECHNICAL STANDARDS Views

ALL Views

A probabilistic relational model Π specifies a probability distribution over all instantiations I of the metamodel M. This probability distribution is specified as a Bayesian network [18], which consists of a qualitative dependency structure and associated quantitative parameters. The qualitative dependency structure is defined by associating with each attribute X.A a set of parents P a(X.A). An advantage of PRM:s over standard Bayesian networks is that the set of parents needs not be fixed at the instance level, but can grow and shrink dynamically as long as the parents are appropriately defined in the metamodel. We can also let x.A depend probabilistically on some aggregate property of several parent attributes, such as the mean (M EAN ) of one, two or ten parents, or the the cardinality (CARD) of this parent set. Other aggregation functions would include the logical operations AN D, OR, and N OT , or arithmetic operations such as SU M and P RODU CT . We can now define a probabilistic relational model (PRM) Π for a metamodel M as follows. For each class X ∈ X and each descriptive attribute A ∈ A(X), we have a set of parents P a(X.A), and a conditional probability distribution (CPD) that represents PΠ (X.A|P a(X.A)). Given a relational skeleton σr (i.e. a metamodel instantiated to all but the attribute values), a PRM Π specifies a probability distribution over a set of instantiations I consistent with σr : Y Y P (I|σr , Π) = P (x.A|P a(x.A))

The MODAF Architecture viewpoints, adapted from [21].

Systems and Services, Technical Standards and the All view. Each view is divided into different viewpoints, or products. MODAF closely adheres to this general structure, but features an extended set of viewpoints, as illustrated in Fig. 4. Each viewpoint consists of a number of views, that reveal different details of the overall architecture. 1. The Strategic Viewpoint is made up of Strategic Views (StVs), designed to support the process of realizing strategic intents through military capabilities. The viewpoint aims at providing tools for gap / overlap analysis, capability audit etc., supported by appropriate measures of effectiveness. 2. The Operational Viewpoint consists of Operational Views (OVs) that put the capabilities defined in the Strategic Viewpoint in the context of an operation. The viewpoint can be used in the development of user requirements, to capture future concepts, to support the operational planning processes, etc. 3. The Service-Orientated Viewpoint holds ServiceOrientated Views (SOVs) that specify services for use in a Service-Oriented Architecture (SOA). This specification includes orchestration and definitions of the capabilities delivered. 4. The System Viewpoint contains the System Views (SVs) and describe how capabilities are actually realized. Resources, broadly construed, and their interactions, as well as system interfaces and human-system interaction are in focus. SVs play a large role in the development of system solutions, as well as in the development of appropriate system requirements. 5. The Technical Standards Viewpoint comprises Technical Standards Views (TVs) that contain standards, rules, policy and guidance. These are not exclusively technical, but also include doctrine, Standard Operating Procedures (SOPs) etc. 6. The Acquisition Viewpoint is made of Acquisition Views (AcVs) that describe programs, projects and other activities involved in capability management and acquisition. 7. The All-Views Viewpoint holds All-Views (AVs) that provide an overall description of the architecture itself.

Views alone do not ensure semantic rigor in MODAF. Consistency and maintainability of MODAF models is ensured by the MODAF Meta Model (M3), defining the structure of the underlying architectural information presented in the views. The M3 is a key feature in making MODAF tools ”model-driven” or ”data-driven” – i.e. that views are convenient snapshot representations of underlying architectural data stored in a repository, rather than independent entities. Use of the MODAF metamodel enables the two essential elements of activity based cost analysis identified by [9]: Taxonomy There is a need for a well-defined set of processes, activities, products etc. that can form the dimensions of the cost analysis. The MODAF metamodel imposes such a taxonomy and forces semantic rigor upon the data collected. Application consolidation inherently entails comparisons of many applications from wide ranges of departments and business areas. There is a substantial risk of low data quality simply because different stakeholders have interpreted concepts differently. Forcing all modeling to be compliant with an established industry metamodel lowers these risks. Mapping Once the taxonomy is established, everything must be mapped into it. As was evident in sections III and IV, some of these mappings are rather complex, due to the interaction of many applications. The metamodel formalism provides a means of illustrating these complex many-to-many relationships, and the PRM notion of aggregation functions furthermore enables full use of these properties in formal decision-support models. C. A MODAF-compliant PRM for application consolidation The great benefit of using the MODAF metamodel in the context of application consolidation is that the estimates from section IV can be packaged, in a logical and coherent way, into attributes belonging to entities in a metamodel. The metamodel, of course, should be tailored specifically for the application consolidation decision-making scenario, meaning that it will consist of a subset of the M3. By including relations between the estimates/attributes, this is equivalent to creating a qualitative dependency structure of a PRM, as described in section V-A. The nature of these attribute relationships was hinted at in section IV, where cost drivers in different scenarios were discussed. The PRM formalism allows the expression of the informal picture given in Fig. 3 in a mathematically more precise manner. Perhaps most importantly, however, the combined MODAF/PRM formalism is very well suited to address the structural features of the application consolidation decision problem. The simplest such example is the number of connections-property featured in Fig. 3. When all the systems are properly modeled in a MODAF compliant PRM, this number – for each and every software application – becomes

readily available through the CARD aggregation function, returning the number of parents of a PRM object. Figure 5 depicts a MODAF compliant metamodel that has been augmented into a qualitative dependency structure, tailored for application consolidation decision-making. In many ways, this figure summarizes the previous discussion: The central element of Fig. 5 is the application, for which a recommendation (i.e. maintain, develop, phase out or replace) has to be made. This recommendation (the top attribute) is directly influenced by utilities and costs (the now familiar maintenance, development, phase out, and replacement costs) as prescribed by the general model developed in section III. However, these utilities and costs are not primary data collected. Instead, they are calculated attributes (marked with a •) in the PRM sense; they are causal descendants of other attributes that are either collected throughout the enterprise (marked with a ) or structural features of the model (marked with a †), i.e. emergent holistic properties of the models such as the number of connections between applications. To the left of the software entity are the two entities information element and information storage. To the right of the software entity are the two entities service level and service. These entities correspond to the two basic ways in which a software can support a business process; either by (i) storing or disseminating information, or (ii) by processing or changing information. On the top, these two concepts are connected to an operational activity with a single attribute to be collected: its criticality. This concept is adopted from [9] (where systems are deemed either ”mission-critical”, ”tier 2”, or ”tier 3”) and is used as follows: the importance of a software application in the context of application consolidation is inherited from the business processes it supports. Critical applications require better service levels. However, the notion of support is a complex one. In a service oriented environment, a single software can support numerous services, each and every one of which might support numerous business processes. This is where the PRM notion of aggregation function plays a vital role. By taking mean values over the criticality of the operational activities that a service supports, the criticality of a single particular service can be inferred. This criticality is then used to set the service requirement (storage requirement in the information case), so that this requirement corresponds to the criticality: a service that supports only processes of low importance does not need to be very good. By the requirements/fulfillment technique described in section IV, the requirement and the actual service level are compared to form the service utility attribute of the softwares making up the service. This works analogously on the information side, and covers the functional utilities. As for the non-functional utilities, these are based on the ISO-9126 quality attributes and operationalized as described in section IV-A using the requirements/fulfillment

• Criticality • Redundancy * • Criticality • Redundancy requires

◊ Criticality

needs *

◊ Security req. ◊ Correctness req.

◊ Availability req. ◊ Throughput req.

*

◊ Response time req.

1

needs

* • Usability req.

1

1

belongs to

1

1

• Service req.

() • Storage requirement provides

communicates with

()

◊ Actual service level • Quality of service

Recommendation

◊ Actual storage level

• Availability • Service utility

• Storage quality

• Throughput

• Information utility 1

• Correctness • Security level † Interoperability ◊ Actual security

1

Legend:

executes

Top attribute ◊ Collected attribute † Structural attribute • Calculated attribute

1 () ◊ Quality

◊ Licence cost • Number of users • Usage frequency † No of connections ◊ Documentation qual. ◊ Dev. paradigm ◊ Number of locations *

1 1

† Interoperability • Usability

◊ Actual availability ◊ Actual throughput ◊ Actual response time ◊ Experienced usability *

◊ Number of users ◊ Usage frequency

develops

1 1

maintains

provides

• Response time

• Phase out cost • Replacement cost • Maintenance cost • Development cost ◊ Training cost ◊ Operations cost ◊ Maintenance cost

◊ Actual correctness

Figure 5.

requires

• Number of users

◊ Cost efficiency

The qualitative dependency structure of the PRM for application consolidation, mapped to the MODAF metamodel (M3).

technique. On the information side, the qualities are security and correctness. On the service side, they are availability, throughput, response time and usability. Interoperability deserves a special remark. As indicated by the †, it is construed as a structural feature in both the information and the service context. The reason for this is that an interoperability check requires the traversal of all application-to-application connections, ensuring that compatible data formats and interfaces are consistently used along the way. Since the details of such interoperability checks are at the same time relatively straight-forward and require a relatively high technical granularity, they have been omitted in Fig. 5. More details on this approach to Enterprise Architecture interoperability assessments, employing metamodels and causal relations, can be found in [22]. A note on the naming of the entities is appropriate. The names given in Fig. 5 adher to MODAF naming conventions in the sense that all the entities, with definitions, are to be found in the M3. In some cases, however, the name of the MODAF entity is so generic that another name was adopted

in Fig. 5. In these cases, the original MODAF name is given within parenthesis. An example is the information storage entity, which is just a MODAF service level applied in a particular context. VI. S CENARIO - BASED DECISIONS The preceding discussion has shown how the two main problems of the account in section III – estimates and complexity – can be addressed using the combined PRM/MODAF framework. However, so far precious little has been said on how exactly to apply the data collected and structured by the PRM dependency structure of Fig. 5. There are many reasons for this. One important caveat is that application consolidation – despite our attempts – is not an exact science. There will invariably be elements and factors that are not properly taken into account by our model, or any other. This is also the reason why the top attribute is called recommendation rather than decision – we do not claim to have achieved full automation in the decision-making process. However, to illustrate the use of

Figure 6.

Two different scenarios.

the framework, Fig. 6 uses a simplified excerpt of the framework, implemented in the Bayesian network tool GeNIe [23], to illustrate its use for scenario-based decision making. In the figure to the left, we see that the high maintenace costs makes the framework recommend either replace or phase-out. In the figure to the right, low maintenance costs and fair quality of service makes maintain the favored alternative. However, it should be noted that the probabilistic framework allows for uncertainty in the recommendations, and transparently enables traceability of where the decisions come from. One of the greatest advantages of Enterprise Architecture models is that they enable this kind of decision making: whereas experimenting in the real world is costly and time-consuming, models can be played with to explore the consequences of decisions before they are actually made [24]. For these reasons, the use of scenarios in consolidation projects is advocated in [7]. One requirement for successful scenario evaluation, however, is that there is a standard by which to compare different scenarios, so that the good can be separated from the bad. The criterion prescribed in section III is the overall utility/cost ratio of the entire application landscape. However, since many of the constituent utilities and costs are only measured on crude ordinal scales in our approximate solution (as illustrated in table II), this ratio is not readily

available. Instead, we propose a proxy criterion: aim to minimize the service and information redundancies. This is not guaranteed to be sufficient, but it seems plausible to assume that it is at least necessary for an optimal solution. The redundancy attributes work in a similar way as do the criticalities and qualities of service, using PRM aggregation functions. The redundancy of a service is calculated using the (functional) actual service level provided by its constituent software systems, and grows with increasing overlap, i.e. if there are several software systems providing the same functionality. Minimizing these redundancy measures will not guarantee the best overall utility/cost ratio, but it will at least select plausible candidates. In this sense, it serves as a good heuristic when using the framework. VII. C ONCLUSIONS The contributions of the present paper are three-fold: First, an analysis and description of application consolidation from the perspective of decision theory is provided. The problem is formally characterized as a large optimization problem in random variables, and the practical problems of treating it as such are discussed. Second, the insights from the decision theoretical framework are applied to create a more practical framework for application consolidation using Enterprise Architecture methods, specifically using the ISO/IEC 9126 standard, the MODAF Enterprise Architecture framework,

and the formalism of Probabilistic Relational Models. Third, the use of this framework is discussed, and the use of scenarios to aid decision-making is proposed, along with a tentative criterion on how to evaluate the scenarios. The present framework was developed as part of a joint research project with the Swedish Armed Forces. In the near future, the framework will be put to use in an application consolidation project in the Armed Forces. This constitutes an important opportunity for further improvements, validation and practical testing of the present framework.

[12] International Organization for Standardization/International Electrotechnical Commission, “International Standard ISO/IEC 9126-1: Software engineering – Product quality – Part 1: Quality model,” ISO/IEC, Tech. Rep., 2001.

R EFERENCES

[15] ——, “Technical Report ISO/IEC TR 9126-4: Software engineering – Product quality – Part 4: Quality in use metrics,” ISO/IEC, Tech. Rep., 2004.

[1] D. Minoli, Enterprise Architecture A to Z. Auerbach Publications, 2008.

Boca Raton:

[2] T. Bucher, R. Fischer, S. Kurpjuweit, and R. Winter, “Analysis and application scenarios of enterprise architecture: An exploratory study,” in EDOCW ’06: Proceedings of the 10th IEEE on International Enterprise Distributed Object Computing Conference Workshops. Washington, DC, USA: IEEE Computer Society, 2006, p. 28. [3] P. Ranganathan and N. Jouppi, “Enterprise IT Trends and Implications for Architecture Research,” in HPCA ’05: Proceedings of the 11th International Symposium on HighPerformance Computer Architecture. Washington, DC, USA: IEEE Computer Society, 2005, pp. 253–256. [4] Swedish Armed Forces Headquarters, Public Relations Staff, “Swedish Armed Forces 2008,” http://www.mil.se/upload/dokumentfiler/ pop08-eng.pdf accessed May 31, 2009, Apr. 2009. [5] T. E. Engevall, “Nätverksbaserat Försvar (NBF) - läge och kurs,” Tidskrift i Sjöväsendet, vol. 173, no. 1, pp. 19–34, 2008. [6] C. Stewart, T. Kelly, and A. Zhang, “Exploiting nonstationarity for performance prediction,” SIGOPS Oper. Syst. Rev., vol. 41, no. 3, pp. 31–44, 2007. [7] A. Spellmann, K. Erickson, and J. Reynolds, “Server consolidation using performance modeling,” IT Professional, vol. 5, no. 5, pp. 31–36, 2003. [8] D. Hancock, D. B. Humphrey, and J. A. Wilcox, “Cost reductions in electronic payments: The roles of consolidation, economies of scale, and technical change,” Journal of Banking & Finance, vol. 23, no. 2-4, pp. 391–421, February 1999. [9] T. Iijima, “A practical way to manage IT costs,” Journal of Corporate Accounting & Finance, vol. 16, no. 5, pp. 13–20, 2005. [10] M. D. Resnik, Choices: An Introduction to Decision Theory. Minneapolis, MN: University of Minnesota Press, 1987. [11] I. Sommerville, Software Engineering (8th Edition). Addison Wesley, June 2006.

[13] ——, “Technical Report ISO/IEC TR 9126-2: Software engineering – Product quality – Part 2: External metrics,” ISO/IEC, Tech. Rep., 2003. [14] ——, “Technical Report ISO/IEC TR 9126-3: Software engineering – Product quality – Part 3: Internal metrics,” ISO/IEC, Tech. Rep., 2003.

[16] U. Franke, P. Johnson, R. Lagerström, J. Ullberg, D. Höo¨ k, M. Ekstedt, and J. König, “A formal method for cost and accuracy trade-off analysis in software assessment measures,” in Proc. 3rd International Conference on Research Challenges in Information Science (RCIS 2009), Fès, Morocco, Apr. 2009. [17] R. Lagerström and P. Johnson, “Using architectural models to predict the maintainability of enterprise systems,” in Proceedings of the 12th European Conference on Software Maintenance and Reengineering, Apr. 2008. [18] F. V. Jensen, Bayesian Networks and Decision Graphs. Secaucus, NJ, USA: Springer-Verlag New York, Inc., 2001. [19] N. Friedman, L. Getoor, D. Koller, and A. Pfeffer, “Learning probabilistic relational models,” in Proceedings of the Sixteenth International Joint Conference on Artificial Intelligence (IJCAI-99). Stockholm, Sweden: Morgan Kaufman, 1999, pp. 1300–1309. [20] L. Getoor, N. Friedman, D. Koller, A. Pfeffer, and B. Taskar, “Probabilistic relational models,” in An Introduction to Statistical Relational Learning, L. Getoor and B. Taskar, Eds. MIT Press, 2007. [21] Ministry of Defence, “MOD Architecture Framework version 1.2.003,” http://www.modaf.org.uk, accessed November 14, 2008, Ministry of Defence, UK, Tech. Rep., Sep. 2008. [22] J. Ullberg, R. Lagerström, and P. Johnson, “A framework for service interoperability analysis using enterprise architecture models,” in IEEE International Conference on Services Computing, Jul. 2008. [23] Decision System Laboratories, “About GeNIe and SMILE,” http://genie.sis.pitt.edu/about.html, 20052007, University of Pittsburgh. [24] P. Johnson, L. Nordström, and R. Lagerström, “Formalizing analysis of enterprise architecture,” in Interoperability for Enterprise Software and Applications Conference, Apr. 2006, p. 10.