Management of the Interfaces during their Life Cycle in a System Landscape

Lama Balloul, Department of Computer Science, Chair of Business Information Systems/ VLBA

Carl von Ossietzky Universität Oldenburg Oldenburg, Germany

lama.balloul@uni-oldenburg.de

Abstract—Software systems tend to grow larger with time, become less structured with changes and less understandable with stuff turnover. These systems are not isolated in their landscape, rather connected to several other systems with heterogeneous architectures supported by wide diverse of communications. These systems are applied to maintenance efforts from the moment they are delivered. Within the maintenance and changes in the system, consequence changes are noticed on the interfaces level. Both maintenance of the interfaces and the implementation have nontrivial percentage costs of the IT-budget. The management of the interfaces during their life time starting with defining them or retrieving them and ending with deactivation phase is explained within its steps in this paper of progress. A reduction in the costs for maintaining the interfaces is expected as one of the results in this work.

Keywords-interface life cycle; interface management; system landscape; graph.

I. MOTIVATION IT systems and their communication are an essential

part in modern companies. Most of the time, not a single integrated ERP system is used, but heterogeneous architectures. The actual application landscape nowadays is a mixture of services and legacy systems [1] and between these connected systems there is a wide diversity in the communication methodologies and techniques. In order to be in control of these communications, a comprehensive knowledge and documentation of the connected systems’ landscape is required in addition to the methods, which these use to call each others’ services. As well, the dependency and its degree for each business process are quite important for several reasons: Applying changes on the system applications, maintaining activities, implementing integration and reducing complexity, all depend on first understanding interdependencies between interfaces. More important than understanding the interdependencies is managing these interdependencies because system interfaces are critical juncture points where information can be lost or distorted [3].

Companies have their own solutions to maintain their interfaces and to integrate them but normally IT applications are integrated only as the need arose, and creating custom interfaces between individual IT applications is both expensive and time consuming [1]. A survey by the Gartner Group shows that about 40% of IT budgets are spent on implementing and maintaining interfaces [2]. This leads to artificially high costs for performing a business process because buyers pay for redundant interfaces, business logic, access architecture

and so on [2]. The reason for redundant interfaces can be accounted to the fact that when new standard software packages are implemented, many already existing functionalities are reimplemented, not integrated [2].

Within the time, the software architecture becomes less structured and more complicated with changes emerging from development and maintenance but they must be continually changed and updated otherwise they become progressively less satisfactory [7].

II. PROBLEM DEFINITION Legacy systems as well as modern systems need to be

managed at their interfaces during their life time. The complexity of a system increases when the system's life time is long; as a result the costs for maintenance increase as well. These two factors can affect the management of the interfaces, becoming increasingly difficult over time. However, this does not necessarily mean that management is easier with modern systems. Interfaces change for several reasons; they need to be changed due to new regulations required by law or when the business process changes. They could be also reimplemented or upgraded.

There are, on the other hand, existing interfaces which are no longer in use for the following reasons (according to my interview with a company in Detmold- Germany):

• when the receiving/sending partner (system or application) doesn't exist anymore and the interfaces are no longer necessary

• when the partner has been replaced by a different system with new and different interfaces

• even when the partner system still exists, but the process has been changed and the exchanged information is no longer necessary or will be supplied by another system.

These interfaces may remain unused in the system requiring regular maintenance and costs which can be saved when we follow appropriate methodologies in order to decide which interfaces can be deactivated and which not.

Each change on the system interface could have consequences and changes on other interfaces resulting from the interdependencies between them. The degree of the coupling increases the effort which needs to be done when a change occurs. Underestimating these dependencies endangers the system because it leaves it vulnerable when an interface should be deactivated, but instead stays open to communicate.

III. STATE OF THE ART Stroulia et al. [4] tried to understand the information

and the process logic that a legacy system embodies by

2011 15th European Conference on Software Maintenance and Reengineering

1534-5351/11 $26.00 © 2011 IEEE

DOI 10.1109/CSMR.2011.59

383

2011 15th European Conference on Software Maintenance and Reengineering

1534-5351/11 $26.00 © 2011 IEEE

DOI 10.1109/CSMR.2011.59

385

reverse engineering the system interface. They construct a map of system interfaces (screens) during the interaction with the user and show the transition from one screen to another. This interaction-based understanding of legacy systems can be helpful in detecting the interfaces which are in use as screens to be later wrapped but not to make any changes on the system. On the other hand, the analysis, which they have done on the interfaces (screens) in the system, was only syntax analysis to determine if a screen is instance of other screens in the map and we can’t determine the priority of interface on another or understand its importance while this will be considered in our work.

In [8] the authors proposed an interface complexity metric aimed at measuring complexity of a software component. They defined the characterization of an interface as we are doing in this work but they were dedicated to the components and they did it for the sake of the components and not for the interfaces in general.

We try in this work to define the interfaces with their characteristics so we can help later for the next stage in the life cycle of an interface and manage them during their life time.

IV. WORK OBJECTIVE As the system and product are managed during their

life time, a new approach will be presented here to manage the life time of interfaces starting from the requirements (in the case they are not already existing) going through the design to the configuration till they are in the run time phase. In parallel to the run time, a monitoring stage takes place. Before the interface moves to the deactivation phase a several routes back to the configuration or the design phase can also happen. In the case of existing interfaces initiated and in work, the start point will be in one phase of the irritation circle between design and run time.

In this work all interfaces with their parameters and characteristics will be retrieved / collected to be represented and visualized in a form of graph. This graph is a directed graph will be constructed to reflect the changes of the business processes on the communications between the systems and the interfaces in turn. All the nodes in a graph will be notated with their attributes. For each time a change occurs on a node, all affected nodes will be marked in order to consider the related required changes.

This approach can be applied at modern systems as

well as legacy systems. The output of this work will be represented in a graph which depicts the structure of the enterprise systems on the interface level. In addition, the deactivated and changed interfaces will be mentioned with the reason for such an action. A mapping of the business process to the interfaces which are included in this process will be as well delivered, so each later change in business process can be under control.

In order to check the efficiency of this approach, I will apply this approach on a landscape of connected systems including one legacy system (or more if it is provided) and the result will be mentioned at the end of my thesis. This result will be discussed and evaluated from the consulters of the company since they are the benefiter or this study. Their discussions will be mentioned as well.

V. MANAGEMENT OF INTERFACE LIFE CYCLE When we first read the term ‘life cycle’, we think about

product lifecycle or system lifecycle. Actually, the life cycle of an interface is not far away from the definition or steps in a product lifecycle or system lifecycle. It starts with defining the requirements such as source, destination, type of transferred data, etc., tell if this interface is external or internal, what are data requirements, interface precedence and criticality, directionality if it is unidirectional or bi-directional and the functional requirements. Then we move to design the interface, in which we answer the question (what). What are the connected partners and what is the structure of the input and output data and so on. The third phase in the life cycle is the configuration, in which we answer the question (how). How the data should be transferred, how the connection should be implemented. Then the interface moves to the run time phase, where in parallel a monitoring takes place. From this phase we can go back to the configuration phase when small changes or maintenance happen on the interface, or we can go back to the design phase when greater changes should be applied, for example changing the communication partner. During the whole life time, time is invested and costs are paid that is why it should move to the last phase which is deactivation when this interface is out of use. A replacement decision is considered as deactivation an old, already in use interface and the definition and creation of new interface with the new requirements.

These five stages for an interface life cycle are depicted in “Fig. 1”.

Figure 1. Life cycle stages of an interface

After defining the life cycle of the interface, the management of it will be discussed here. Actually, through my research I have not found any definition for Management of interface life cycle. However, the term of interface management has been mentioned in several articles [5] [6]. A definition of it is given in [5] “Interface Management which includes identification, definition and control of interfaces, is an element of software engineering that helps to ensure that all pieces of system work together to achieve the system’s goals and continue to operate together as changes are made during the system’s life cycle.”

According to the area and goals of this paper the interface life cycle management is defined as following

Interface Life Cycle Management is a systematic analysis of the life cycle stages of the interfaces and their

384386

characteristics in order to understand their dependencies, estimate risk rating and apply required changes.

The phases of ILCM is displayed in “Fig 2”. This

process is continuous if it is done after a period of time where new changes have been done to the system, otherwise it is repeated from the second step (the analysis) until the fifth step (the evaluation). The five major phases are: • Define/Retrieve the interfaces: depending on the state,

in which the interface takes place, the analysis method will change to adopt the Bottom-up approach or the top down one. However, the start will be in collecting information about the interfaces in the existing/for the new system and detecting all the interfaces which are in the system or required for the system.

• Model and analyze the interfaces: a diagram of the interfaces will be depicted in a form of directed graph with notation about the characteristics of the interfaces and then the effectives of these characteristics on the complexity and the total costs of the system will be analyzed.

• Estimate the risk rating: according to the output of the analyzing phase, the probability of the risk will be revealed for deactivating interfaces which are not in use for a long time or have a low number of connections or have high costs, as well as the consequences of excluding these irrelevant interfaces.

• Decision making and implement the changes: according to the priority of the interface and its importance a decision will be made. The priority can be described with reference to the business value of an interface and the cost consequences in the case of problem occurrence in this interface. The risk will be measured in reference also to the number of connections this interface has with other interfaces and the dependency measure.

• Evaluation of the cycle: by using a system of metrics to assess and compare the quality of the new architecture. This can be done e.g. by measuring maintenance cost, number of interfaces, or the complexity of the system.

A. Define/ Retrieve the Interfaces When we work in Top-Bottom form, we start

collecting the Meta data and the requirements for building interfaces with their specific location between the systems.

The Meta data includes • the communication endpoints • the direction of the interaction • the kind of transferred data • the functionality being invoked

In more specific determination the location of the interface should be defined, which can be between • software components • software modules • functional areas • software applications • software layers.

Figure 2. This figure shows the five basic phases of ILCM.

The technique which will be used for the interface, for example: • SOAP in web services communications • RPC (Remote Procedure Calls) • RFC (Remote Function Calls) • RMI (Remote Method Invocation)

In the Bottom-Up approach, this information should be collected and retrieved from the available documentation and the source code and the experts in the area.

These data can be collected; according to Giachetti [12] by: • examining the processes inputs and outputs to see

where data come from and what their destination. • examining the data flow charts and other models which

identify the interfaces. In the case of unavailable documentations or such

models, a dependence on the network analyzers would be the helpful method still available. Examples about Network analyzer tools could be Ethereal, Ettercap. After collecting these data, they should be filtered before storing them.

B. Model and Analyze the Interfaces After defining the interfaces, we have to define the

characteristics of these interfaces. They are included in: • On technical layer

• Dependencies • Weightiness • Directionally • Frequency of Usage • If it is fixed or ad-hoc

• On the business layer • Initiation costs • Maintenance costs • Precedence • Business value • Criticality

385387

This collected information will be stored in a graph database. My decision about using graph database was for the benefits it provides over using matrix or relational database.

Graph database does not need rigid schema like the relational database and is faster than matrix for searching. As well, queries which can be applied on a graph can be also answered by graph database. Moreover, there are algorithms which can be applied on graph database and give an answer in a time of milliseconds. I chose in my study Neo4J™ as an open source database graph.

One of the algorithms which I use here is Graph Indexing based on Pre- and Postorder numbering (GRIPP) [9]. This approach is a generic approach and suitable for large directed graphs like in our case with the system landscape. GRIPP helps to find all the nodes which are connected to a node’s “answer reachability” and it gives the degree of a node which is the number of the incoming and outgoing edges of a node’s “weightiness”.

Further on, complexity factors of the interfaces affected by some factors of system’s complexity. In [11] the project’s complexity is defined by the number of pieces or activities that can interact in a project system. This means that the larger the number of activities is, the more interactions there are. Due to this, the complexity factors of interfaces are implied in the dependencies and the control signals (interrupts) which come from other functional processes.

Additional analysis will be considered in the future.

VI. FUTURE WORK We see the next three phases in our work engaged in

estimating the priority and risk rating of keeping an interface or deactivating it or continuing using it with regular maintenance activities. Deactivating an interface on one hand saves maintenance costs but the interface should be well understood to prevent dropping in inconsistence call chain. A prototype will be then created with the new changes. After achieving this point we need a tool to determine the changes which occurred on the system, this tool being Enterprise Tomography [10]. This new approach is very efficient in making the comparison and able to tell in a short time all places of change and other sequence changes. At the end of the study, the

evaluation for the new concept should be done e.g. by using a system of metrics to assess and compare the quality of the new architecture. This can be done e.g. by measuring maintenance cost, number of interfaces, or the complexity of the system.

This work is promising to be helpful for the consulters in taking a decision as well as the company itself by reducing its costs.

REFERENCES [1] R. de Boer, "What did SOA actually bring us?" December 2009

Url: http://robertusdeboer.wordpress.com/2009/12/18/what-did-soa-actually-bring-us/ (last visit 12.11.2010)

[2] W. Lam, V. Shankararaman, "Enterprise Architecture and Integration: Methods, Implementation and Technologies.", IGI Global, 2007

[3] Institute, I. G. "Managing Enterprise Information Integrity: Security, Control and Audit Issues", Isaca, 2004.

[4] E. Stroulia, M. El-ramly, L. Kong, P. Sorenson, B. Matichuk, "Reverse Engineering Legacy Interfaces: An Interaction-Driven Approach", IEEE, 1999

[5] National Airspace System "System Engineering Manual", Version 3.1, 06/06/06, section 4.7.

[6] Program Management Professional (PGMP), "A Certification Study Guide With Best Practices for Maximizing Business Results" 2007

[7] M. M. Lehman, J.F. Ramil, "Rules and Tools for Software Evolution Planning and Management" in Annals of Software Engineering 11, Springer 2001, Number 1, 15-44, DOI: 10.1023/A:1012535017876

[8] C. Suematsu, M. Makabenta-Ikeda, "Interface from Transaction Cost Approach", 2007

[9] S. Trißl, U. Leser, "Fast and Practical Indexing and Querying of Very Large Graphs" in Proceedings of the 2007 ACM SIGMOD international conference on Management of data, 200, doi:10.1145/1247480.1247573

[10] J. Aalmink, L. Balloul, J. Glagau, J. Marx Gómez: "Enterprise Tomography driven Governance of Federated ERP in a Cloud." in Proceedings of the ICT Innovations Conference 2009, Springer 2009

[11] Q. Chen, G. Reichard, Y. Beliveau, "Interface Management- a Facilitator of Lean Construction and Agile Project Management." in IGLC 15 - Lean Construction - A New Paradigm for Managing Construction. Michigan, USA. 2000

[12] R. E. Giachetti, “Design of Enterprise Systems: Theory, Architecture, and methods, 2010.

386388