Enterprise Architecture: A Service Interoperability ... - Semantic Scholar

Enterprise Architecture: A Service Interoperability Analysis Framework Johan Ullberg1, Robert Lagerström1, Pontus Johnson1 1

Department of Industrial Information and Control Systems Royal Institute of Technology (KTH) {johanu, robertl, pj101}@ics.kth.se

Abstract. Enterprise architecture is a model-based approach to IT management used for promotion of good IT decision making. Thus, an enterprise architecture framework needs to support various forms of analysis. Creation of enterprise architecture models is costly and without intrinsic value, therefore it is desirable to create models that effectively support the sought after analysis. This paper presents an extended influence diagram describing theory of enterprise service interoperability. The theory is augmented with a metamodel containing the information needed to perform analysis of interoperability. A fictional example is provided to illustrate the employment of the metamodel and the theory in the context of IT decision making. Keywords: enterprise architecture, service-oriented architecture, interoperability analysis, extended influence diagrams

1 Introduction Enterprise architecture is an approach to enterprise information systems management that relies on models of the information systems and their environment. Instead of building the enterprise information system using trial and error, a set of models is proposed to predict the behavior and effects of changes to the system. The enterprise architecture models allow reasoning about the consequences of various scenarios and thereby support decision making. In order to predict which enterprise architecture scenario is preferable, three things are needed. Firstly, models over the two scenarios need to be created. Secondly, it is necessary to define what is desirable; the goal, i.e. high service interoperability. Thirdly, we need to understand the causal chains from scenario choice to goal. Suppose that scenario A features services with high availability affecting the interoperability positively but has several service descriptions which are not complete, affecting the interoperability negatively. However, scenario B is built up on service orchestration descriptions of high compatibility with respect to the available services, promoting high interoperability of the system. To make a decision on which scenario to choose is often difficult, particularly without a formal analysis. In order to perform this kind of analysis, the enterprise architecture models need to contain the proper information. In the above example, where the decision maker is in-

Johan Ullberg, Robert Lagerström, Pontus Johnson

terested in service interoperability, the models need to answer questions regarding service availability, service description completeness, and service orchestration description compatibility. The kind of information contained in a model is given by its metamodel, so it is important that enterprise architecture metamodels are properly designed. In order to determine if a metamodel is amenable to the analysis of a certain quality attribute, such as interoperability, it would be helpful with a structured account of that analysis. We will use a notation called Extended Influence Diagrams (EID) [1] in order to formalize the analysis of interoperability. Figure 1 depicts the relation between an enterprise architecture scenario, modeled using a metamodel, the analysis of the scenario, the formal specification of the analysis through an extended influence diagram and finally the output: the interoperability level.

Fig. 1. The relation between metamodels, enterprise architecture scenarios, analysis, formal specification of analysis, and the result of the analysis

The main contribution of this paper is a metamodel that supports the creation of enterprise architecture models amenable to service interoperability analysis. Also introduced are formalizations of such an analysis using extended influence diagrams. The remainder of this paper is delineated as follows; extended influence diagrams are introduced in section 2. Section 3 presents the framework for service interoperability analysis in the form of an extended influence diagram. Section 4 evaluates the usefulness of a number of common enterprise architecture metamodels. Section 5 proceeds to detail the content of the metamodel that supports service interoperability analysis. The applicability of the metamodel is demonstrated in the subsequent section 6. Finally, section 7 concludes the paper.

2 Extended Influence Diagrams Extended influence diagrams are graphic representations of decision problems coupled with a probabilistic inference engine. These diagrams may be used to formal-

Enterprise Architecture: A Service Interoperability Analysis Framework

ly specify enterprise architecture analysis [1]. The diagrams are an extension of influence diagrams, [2][3] which in turn are an enhancement of Bayesian networks [4][5]. In extended influence diagrams, random variables associated with chance nodes may assume values, or states, from a finite domain (cf. Figure 2). A variable could for example be service availability. These variables are connected with each other through causal or definitional arcs. Causal arcs capture relations of the real world, such as “higher service availability increases the system interoperability”. With the help of a conditional probability matrix for a certain variable A and knowledge of the current states of the causally influencing variables B and C, it is possible to infer the likelihood of node A assuming any of its states. Extended influence diagrams support probabilistic inference in the same manner as Bayesian networks do; given the value of one node, the values of related nodes can be calculated. For more comprehensive treatments on influence diagrams and extended influence diagrams see [1], [2], [3], [4], [5], [6], [7] and [8].

Fig. 2. An extended influence diagram and a simple example. With a chosen scenario in the decision node, the chance nodes will assume different values, thereby influencing the utility node [9].

3 A Framework for Enterprise Service Interoperability Analysis This section presents an extended influence diagram that captures theory from the field of service interoperability. The extended influence diagram is mainly influenced by [10][11][12][13][14]. Interoperability is the ability of two or more systems or components to exchange information and to use that information [15]. Adopted to the domain of services, enterprise service interoperability is the ability of services in an enterprise to exchange information and to use that information. Enterprise Service interoperability is divided into run-time enterprise service interoperability and design-time enterprise service interoperability, cf. Figure 3.


Fig. 3. The extended influence diagram for enterprise service interoperability containing factors influencing service interoperability and thereby of interest when performing analysis.

3.1 Run-Time Enterprise Service Interoperability Run-time interoperability is concerned with the interoperability of services that in the scenario under evaluation are supposed to be working together. It is divided into three sub categories; firstly, there are properties that can be assessed within the scope of a single service, service run-time interoperability. Secondly, the quality of service pair interaction captures aspects that can be measured by pair-wise comparison of all service pairs supposed to interact. Finally, some properties must be analyzed in a wider scope than that of pairs, namely in the power set scope (excluding the empty set and the sets with only one member), this is denoted quality of interaction for power set Service Run-Time Interoperability. The measurable properties of each service that are of importance at run time are the inherent properties of the service, cf. the node quality of service in Figure 3, service bus compatibility which is the service’s compatibility with the communication medium, the service bus and quality of service orchestration description, consisting of properties relating to the orchestration descriptions, i.e. a specification detailing the interaction of services [11]. The node quality of service is defined by the nodes correctness and availability. Correctness is the ability of the service to perform the intended task correctly. Availa-


bility of a service can be measured in terms of mean time to failure and mean time to repair. From a run-time point of view there are three properties of the service orchestration description that need to be attended. The first is that the orchestration description calls the operations of the service in a syntactically correct manner, syntactic compatibility with respect to service. The second, behavioral semantic compatibility with respect to service, is the subject of the orchestration description’s ability to act in conformity with the dynamics of the service. Generally this means to call the operations of the service in a permissible order. Finally, the denotational semantic compatibility with respect to service is concerned with the real world, the orchestration description and the service are denotationally equivalent if they refer to the same phenomenon in the real world [16], so that the service really executes what the orchestration description intended. Quality of Service Pair Interaction. When studying services in pairs there are two additional properties that can be assessed, namely protocol compatibility and syntactic compatibility. The first is a match of protocols so that the services share at least one compatible protocol. The latter is a comparison of the provided and invoked operations of the services, e.g. that the provided methods of the service provider must have the same syntax as the requests sent from the consumer for communication to be possible. Quality of Interaction for Power Set. When studying even larger sets of services, two additional factors of importance can be added to the theory. Both factors are concerned with semantic compatibility and are similar to those of Section 3.1 regarding semantics. The first, behavioral semantic compatibility, captures the behavior of the interaction, two concepts (e.g. services) are equivalent with respect to their behavioral semantics if they display the same dynamics, i.e., if their interaction patterns are equivalent [16]. The second, denotational semantic compatibility is concerned with the actual meaning of the services’ operations, so that they refer to the same operation in the real world. 3.2 Design-Time Enterprise Service Interoperability Design-time service interoperability is the matter of analyzing the effort needed for possible future constellations of services to interoperate, regardless of their current relationship to each other. Design-time interoperability is, as in the case of run-time interoperability, divided into three categories covering aspects of a single service, pairs of services and the power set of services, cf. the node service design-time interoperability as well as the previously mentioned quality of service pair interaction and quality of interaction for power set in Figure 3. Different from run-time interoperability is however how these services, pairs, and sets are selected, rather than only regarding services that in the currently assessed scenario are supposed to work together, the focus now is on all services available in the enterprise as well as all pairs and sets of services that possibly could work togeth-


er in some future scenario. As seen from Figure 3 the properties of concern for the pairs and the power set are the same as for run-time interoperability, see Section 3.1. Service Design-Time Interoperability At design time two of the properties measurable per service are common with those of interest at run time, the service bus compatibility and the quality of service as described in Section 3.1. Other properties that are of interest at design time are quality of service description, covering aspects of the service descriptions, descriptions containing for instance the behavior and abilities of the service [17], and service orchestration language compatibility stating to which degree the service is compatible with available languages for service orchestration. Finally, the node existence in service description repository corresponds to a validation that the description of the service is placed in a repository, a storage area used for discovery of services [18]. The quality of the service description is divided into five parts where the first, completeness, considers the service description coverage, i.e. that all abilities of the service are included in its description. Understandability means that the description can be easily understood. The third, syntactic correctness¸ ensures that the service description is syntactic correct with respect to the actual operations of the service. Behavioral semantic correctness implies that the dynamics in the description corresponds to that of the service itself, and finally denotational semantic correctness which is the matter of the service description really describing the same action that the service performs.

4 Enterprise Architecture Frameworks for Analysis With the requirement on enterprise architecture models to support enterprise architecture analysis follows a specific requirement on enterprise architecture metamodels. Specifically, all entities and attributes that are required for a complete analysis as specified in an extended influence diagram must be found in the enterprise architecture metamodel, in order for the corresponding model to be amenable to analysis. See Figure 4. A substantial number of enterprise architecture frameworks have been proposed in recent years, including the Zachman Framework [19], the Department of Defense Architecture Framework (DoDAF) [20] the Open Group Architecture Framework (TOGAF) [21], the Federal Enterprise Architecture (FEA) [22], the General Enterprise Reference Architecture and Methodology (GERAM) [23], Architektur integrierter Informationssysteme (ARIS) [24], the Metis Enterprise Architecture Framework (MEAF) [25], and more. When considering the suitability of the metamodels related to these frameworks to the enterprise architecture analysis considered in preceding sections, we have found significant difficulties. Firstly, a number of metamodels are not detailed enough to provide the information required for the analysis. We are interested in information such as for instance the complexity of a service. This is information that would typically be represented as an attribute in an entity in a metamodel. Many metamodels, including the Zachman Framework, the TOGAF and the GERAM, do not systematically propose attributes, thereby underspecifying their metamodels


with respect to the analysis proposed in the previous section. The frameworks that do specify attributes, e.g. DoDAF, FEA, and MEAF, contain few of the specific attributes required for the analysis described in Section 3. Finally and perhaps most importantly, many of the frameworks do not contain the entities that would be required.

Fig. 4. The properties found in an extended influence diagram determine what entities and attributes should be present in an enterprise architecture metamodel.

5 The Metamodel for Enterprise Service Interoperability Analysis In this section, we present the metamodel suggested for enterprise service interoperability analysis. The metamodel is constructed to satisfy the requirements of the preceding section, containing all of the entities and attributes necessary to conduct analysis of interoperability. 5.1 Entities in the Metamodel Services are independent building blocks that collectively represent an application environment, much like components of a software system. Services possess a number of qualities that components lack, e.g. the complete autonomy from other services which allows a service to be responsible for its own domain and services are typically limited in their scope to support a specific business function or a group of related functions [10]. For communication among services, each service has a service interface. The service interface contains the protocols a service needs for communication and it specifies which operations the service provides or invokes [11][26]. Services also have service descriptions. These are used for advertising and describing the service capabilities, behavior, quality, and its interface [17]. An example of a service description language is WSDL (Web Service Definition Language).


Services use a service bus, often referred to as an enterprise service bus (ESB), as a communication medium. The service bus is a middleware-like solution to manage message and transaction traffic [12]. As the amount of services and the number of versions of each service steadily increases it has become critical to keep track of the service descriptions. Thus, the need for a service description repository, i.e. a storage area containing all service descriptions and making the descriptions searchable. Each time a service requestor needs a service the requestor can find the most appropriate service for its intentions in the repository. A standard repository solution is the UDDI [18]. The service orchestration description is the specification that details and controls the orchestration of services to interact [11]. These descriptions are written in a service orchestration language, where BPEL (Business Process Execution Language) is considered an industry standard.

Fig. 5. The enterprise architecture metamodel for service interoperability analysis with its entities, attributes, and relations.

5.2 Attributes of the Metamodel For the purpose of service interoperability analysis, a metamodel without attributes would be inadequate. In an enterprise architecture model, many important concepts are best captured as entity attributes. As seen in Figure 5, some entities have attributes that correspond to the service interoperability extended influence diagram. The availability of a service, for instance, is of importance for the interoperability (according to the extended influence diagram of Section 3). Consequently, the service entity of our model explicitly contains the attribute availability. Analogously, the service description entity contains the attribute completeness, also found as a node in the extended influence diagram. Other attributes in the metamodel directly related to nodes in the EID are service correctness and service description understandability.


There are variables in the extended influence diagram not directly related to one attribute in the metamodel, e.g. service bus compatibility. This is represented in the metamodel by the attribute in service called compatible service buses and by the attribute type in the entity representing the service bus. If there is one compatible service bus in service that matches the service bus type, this means that the service and the service bus are compatible. Syntactic compatibility, protocol compatibility, and existence of service description in repository are other attributes evaluated in a similar manner. The values of two types of nodes in the extended influence diagram cannot be derived from the metamodel. These are the denotational and behavioral semantic compatibility and correctness nodes. It is well known that it is both practically and philosophically difficult to determine denotational equivalence. Although behavioral equivalence is possible to determine, it requires detailed dynamic models beyond the scope of the present work [16].

6 Modeling and Analyzing Using the Metamodel – An Example This section presents an example of an enterprise service interoperability analysis used as decision support for a Chief Information Officer (CIO) at LIAM Energy, a large power distribution company in Sweden. LIAM Energy has initiated an implementation of an Automatic Meter Reading (AMR) system. A pre-study revealed that a service-oriented solution would be the most appropriate and would provide the company with long-term business value. The CIO faces a choice between three suppliers of AMR software where no supplier is able to deliver all the wanted functionality, thus a combination is desirable. Our CIO will also face the task of integrating the meter reading system with the company’s existing service-oriented ERP system for billing purposes. This integration is needed because new regulations require distribution companies to keep track of outages and only bill their customers for actual electricity usage. Several possible scenarios must therefore be considered and the CIO decides that a formal evaluation of the candidate scenarios is to be performed. Based on the metamodel of Section 5 information on the entities and their attributes are collected, see Figure 6 for one scenario containing three services from three different vendors. Some examples of information that is gathered are the semantic correctness of the service description and the provided and invoked operations of the service interfaces. To find information on for instance provided operations, the code of the services was studied while information on the availability of services was found by performing interviews with the developers of the service. All collected variable values were then translated into discrete states, such as Low, Medium, or High, and used as input to the enterprise service interoperability analysis employing Bayesian theory as described in Section 2. When collecting information for the models, there is an issue of credibility. Low credibility may lead to a large uncertainty in the analysis, making it difficult for the CIO to take a rational decision. For instance, studying the code to find the operations of the service is a tedious work but, if done well, this will provide the CIO with high


credibility of the gathered information. Whereas, interviewing personnel, e.g. developers and architects, to find the availability of the service is less credible and also dependent on the experience of the personnel and the bias of the interviewer. Oftentimes it is very expensive to collect the information needed for a perfectly credible analysis. Since the analysis is based on the formalism of Extended Influence Diagrams this credibility variation can be handled, thus the presented method of analysis provides the CIO with an uncertainty degree in the result, shown in Figure 7 as bars indicating the range of values the result may assume.

Fig. 6. The enterprise architecture model of scenario A. In the model the service calculate energy cost has been enlarged to visualize its attribute values; correctness being High with 90 % certainty and availability being Medium with 80 % certainty.

The final result of the analysis is shown in Figure 7. As can be seen from the figure, scenario 2 didn’t achieve any service interoperability at all due to the choice of service bus with which only one of the services was compatible. Even though not detailed in this paper, the method allows for analysis of subcomponents and it is therefore possible to discover that scenario 3 has decent run-time interoperability but almost no design-time interoperability. Further, it is possible to see that scenario 1 and 4 both have near to perfect run-time interoperability and that scenario 4 scores a bit higher on design-time interoperability, yielding the higher total score. The CIO can


now make a rational decision, choosing the set of services providing the degree of interoperability needed by the enterprise.

Fig. 7. The comparison between the service interoperability of the different scenarios, the black I-bars indicate the uncertainty of the assessments.

7 Conclusion This paper has presented an enterprise service interoperability analysis framework in the form of an extended influence diagram with attributes affecting service interoperability and an enterprise architecture metamodel supporting the analysis. The metamodel consists of entities with accompanying attributes that can be used to create enterprise architecture models from which it is possible to extract precisely the information that is needed for quantitative enterprise service interoperability analysis. An example was provided illustrating the use of the metamodel and the extended influence diagram for analysis. Acknowledgements. The authors would like to thank Per Närman for his previous work on the topic of system quality analysis using enterprise architecture models [27].

9 References 1. Johnson, P., et al.: Enterprise Architecture Analysis with Extended Influence Diagrams. In: Information System Frontiers, vol 9(2), Springer, The Netherlands (2007) 2. Shachter, R.: Evaluating influence diagrams. Operations Research, 34(6) pp 871-882, Institute for Operations Research and the Management Sciences, Hanover Maryland (1986) 3. Howard, R.A., Matheson, J.E.: Influence Diagrams. Decision Analysis Vol. 2(3), pp. 127– 143, Institute for Operations Research and the Management Sciences, Hanover Maryland (2005)

Johan Ullberg, Robert Lagerström, Pontus Johnson 4. Neapolitan, R.: Learning Bayesian Networks. Prentice-Hall, Inc. Upper Saddle River, NJ, USA (2003) 5. Jensen, F.V.: Bayesian Networks and Decision Graphs. Springer New York, Secaucus, NJ, USA (2001) 6. Johnson, P., Lagerström, R., Närman, P.: Extended Influence Diagram Generation. In: Enterprise Interoperability II – New Challenges and Approaches, pp. 599-602, Springer, London (2007) 7. Shachter, R.: Probabilistic inference and influence diagrams. Operations Research, 36(4), pp 36-40 (1988) 8. Johnson, P., Ekstedt, M.: Enterprise Architecture – Models and Analyses for Information System Decision Making. Studentlitteratur, Lund, Sweden (2007) 9. Lagerström, R.: Analyzing System Maintainability Using Enterprise Architecture Models. In: Proceedings of the 2nd Workshop on Trends in Enterprise Architecture Research (TEAR’07), pp. 31-39, St Gallen, Switzerland (2007) 10.Erl, T.: Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services. Prentice Hall, New Jersey (2004) 11.Erl, T.: Service-Oriented Architecture: Concepts, Technology, and Design. Prentice Hall, New Jersey (2005) 12.Marks, E., Bell, M.: Service-Oriented Architecture: A Planning and Implementing Guide for Business and Technology. John Wiley & Sons, New Jersey (2006) 13.Kasunic, M., Anderson, W.: Measuring Systems Interoperability: Challenges and Opportunities. Technical Note, CMU/SEI-2004-TN-003, Software Engineering Institute, Carnegie Mellon University, Pittsburgh (2004) 14.Linthicum, D.: Enterprise Application Integration. Addison-Wesley, New Jersey (2000) 15.IEEE: Standard Glossary of Software Engineering Terminology. Std 610.12-1990. The Institute of Electrical and Electronics Engineers, New York (1990) 16.Saeed, J.: Semantics. Second Edition, Blackwell Publishing, Oxford, UK (2003) 17.Papazoglou, M., Georgakopoulos, D.: Service-Oriented Computing. In: Communications of the ACM, Vol. 46 No. 10 (2003) 18.Gottschalk, K., Graham, S., Kreger, H., Snell, J.: Introduction to Web services architecture. In: IBM Systems Journal, Vol. 41 No. 2 (2002) 19.Zachman, J.A.: A Framework for Information Systems Architecture. IBM Systems Journal, IBM, vol 26(3), pp 454-470 (1987) 20.Department of Defense Architecture Framework Working Group: DoD Architecture Framework, version 1.0. Department of Defense, USA (2004) 21.The Open Group: The Open Group Architecture Framework, version 8 Enterprise Edition. Reading U.K. (2005), http://www.opengroup.org/togaf/ 22.Office of Management and Budget: FEA Consolidated Reference Model Document Version 2.1. OMB, USA (2006) 23.IFAC-IFIP: Task Force on Architectures for Enterprise Integration Geram: Generalized enterprise reference architecture and methodology, version 1.6. (1999) 24.Scheer, A.W.: Business Process Engineering – Reference Models for Industrial Enterprises 2nd Edition. Springer Verlag, Heidelberg, Germany (1994) 25.Troux Technologies: Metis Architect – Datasheet. http://www.troux.com (2007) 26.Papazoglou, M.: Service-Oriented Computing: Concepts, Characteristics and Directions. In: Proceedings of the Fourth International Conference on Web Information Systems Engineering (WISE’03), IEEE (2003) 27.Närman, P., Johnson, P., Nordström, L.: Enterprise Architecture: A Framework Supporting System Quality Analysis. Will appear in: Proceedings of the 11th International IEEE EDOC Conference, Annapolis, USA (2007)