Enterprise Modeling Based Application Development for Interoperability Problem Solving

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 architec-ture framework needs to support various forms of analysis. Creation of enter-prise architecture models is costly and without intrinsic value, therefore it is de-sirable 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 ex-ample 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, interoperabili-ty 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. Sup-pose that scenario A features services with high availability affecting the interopera-bility positively but has several service descriptions which are not complete, affecting the interoperability negatively. However, scenario B is built up on service orchestra-tion descriptions of high compatibility with respect to the available services, promot-ing 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 de-scription compatibility. The kind of information contained in a model is given by its metamodel, so it is important that enterprise architecture metamodels are properly de-signed.

In order to determine if a metamodel is amenable to the analysis of a certain quali-ty 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 analy-sis 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 en-terprise architecture models amenable to service interoperability analysis. Also intro-duced 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 interopera-bility 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 sec-tion 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-


ly specify enterprise architecture analysis [1]. The diagrams are an extension of influ-ence 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 ex-ample 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 likelih-ood 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 de-cision 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, en-terprise 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 in-teroperability, 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 ser-vice 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 orchestra-tion 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 compa-tibility with respect to service. The second, behavioral semantic compatibility with re-spect to service, is the subject of the orchestration description’s ability to act in con-formity 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 descrip-tion 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 re-lationship to each other. Design-time interoperability is, as in the case of run-time in-teroperability, 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 interopera-bility as well as the previously mentioned quality of service pair interaction and quali-ty 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 de-scription is syntactic correct with respect to the actual operations of the service. Beha-vioral 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 per-forms.

4 Enterprise Architecture Frameworks for Analysis

With the requirement on enterprise architecture models to support enterprise architec-ture analysis follows a specific requirement on enterprise architecture metamodels. Specifically, all entities and attributes that are required for a complete analysis as spe-cified 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 Fig-ure 4.

A substantial number of enterprise architecture frameworks have been proposed in recent years, including the Zachman Framework [19], the Department of Defense Ar-chitecture Framework (DoDAF) [20] the Open Group Architecture Framework (TOGAF) [21], the Federal Enterprise Architecture (FEA) [22], the General Enter-prise Reference Architecture and Methodology (GERAM) [23], Architektur integrier-ter 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 inter-ested in information such as for instance the complexity of a service. This is informa-tion 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 re-quired.

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 interopera-bility analysis. The metamodel is constructed to satisfy the requirements of the pre-ceding section, containing all of the entities and attributes necessary to conduct analy-sis of interoperability.

5.1 Entities in the Metamodel

Services are independent building blocks that collectively represent an application en-vironment, 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 li-mited in their scope to support a specific business function or a group of related func-tions [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 descrip-tion 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 ser-vice 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 enti-ties, 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 ser-vice 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 ser-vice 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 de-rived from the metamodel. These are the denotational and behavioral semantic com-patibility and correctness nodes. It is well known that it is both practically and philo-sophically 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 imple-mentation 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 com-pany 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 meta-model 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. devel-opers and architects, to find the availability of the service is less credible and also de-pendent 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 fig-ure, 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 de-tailed in this paper, the method allows for analysis of subcomponents and it is there-fore possible to discover that scenario 3 has decent run-time interoperability but al-most 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 in-teroperability 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 interope-rability and an enterprise architecture metamodel supporting the analysis. The meta-model consists of entities with accompanying attributes that can be used to create en-terprise 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 in-fluence 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, Insti-tute 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)


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: En-terprise Interoperability II – New Challenges and Approaches, pp. 599-602, Springer, Lon-don (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 Servic-es. 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 Oppor-tunities. 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 In-

stitute 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 en-

terprise 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 Engineer-ing (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)

Enterprise Modeling Based Application Development for Interoperability Problem Solving

Documents

Transcript of Enterprise Modeling Based Application Development for Interoperability Problem Solving