Volume 4
Issue 2

Managing Risks Using Software Maps

By Sabine Buckl and Christian M. Schweda

For centuries, engineers from many different disciplines have had to deal with the topic of risk. No architect, for example, can design any building without taking into consideration various risks arising from a multitude of sources, ranging from the possibility of material fatigue to fire or other natural hazards.

While some of these risks may be inherently and inevitably connected to the engineering process or task, others can be avoided or at least reduced. Where this is not an option, methods for a timely discovery of a nearing incident as well as strategies for mitigating the effect of the risk occurrences are often developed. So as of today, we seem well prepared, e.g., via the reports of storm spotters or the regular fire practices.

Nevertheless, when considering enterprise risk management, especially the critical factor IT, companies typically employed medieval methods, if any methods at all had been established. The situation has changed over the last few years in response to several external influences. This has led to more developed and holistic risk management practices, also targeting the enterprise IT support—namely, regulations as from Section 404 in the Sarbanes-Oxley Act (SOX). Additionally, many private bodies have begun to scrutinize the overall risk awareness of a company by rulings, as e.g., the NYSE corporate government rules or the Standard & Poor’s ratings.

As a consequence, notably, but not singly arising from the existing juristic implications of SOX, the enterprise-wide IT landscape and its constituents have gained significant attention on different levels of management. Especially, CIOs see themselves faced with questions like the following, which they should be able to answer, but aren’t always capable of doing so:

Do current application systems meet the different regulatory standards?
Which application systems provide support for which critical business processes?
What is the impact if a specific application system fails?

Besides the need for knowing the answers to these questions, the CIO is further confronted with the challenging situation that he or she should: on one hand, maintain and raise the flexibility of the company’s IT to allow the timely introduction of new products and services; and on the other hand, start or continue the reduction of costs for maintaining and developing the application landscape. At this point, an integrated management approach is needed for pursuing these complementary targets, keeping the balance between flexible business support and cost reduction, while further ensuring the fulfillment of external regulations and providing adequate methods for business continuity management. An essential part of this management endeavor is the documentation of the application landscape, in order to provide guidance for its evolution.

In the research project software, cartography methods and models for documenting, evaluating, and planning complex application landscapes, consisting of hundreds or even thousands of applications, are developed. Thereby, notations as well as visualizations utilizing concepts originating from the field of cartography are used. This article introduces the basic elements of software cartography that are subsequently applied as a means to support the enterprise-wide management of IT-related risks.

Software Cartography

Application landscapes are complex systems, which consist of hundreds or even thousands of applications as well as their dense web of interdependencies. Therefore, they represent a major investment of modern enterprises. Emerging from the support of strategic adjustment of the enterprise, on the one hand, and the ad hoc realization of new IT solutions, on the other hand, technological islands arise from the landscapes. This leads to selective optimizations in contrast to targeting the overall IT architecture. The integrated management of the application landscape together with the related business processes, the organizational framework, and the basic technical infrastructure constitutes a major challenge for today’s enterprises.

This challenge is commonly attributed as enterprise architecture (EA) management, where a holistic and integrated view of the enterprise is used for driving and guiding the overall evolution of the application landscape to ensure and leverage business alignment. In an extensive survey we conducted on EA management tools, the multifaceted aspects of EA management are subsumed as follows: “EA management is a continuous and iterative process, controlling and improving the existing and planned IT support for an organization. The process not only considers the information technology of the enterprise, but also business processes, business strategies, etc.”

Intuitive visualizations, which document the EA and especially the application landscape, provide a valuable contribution to EA management. In the software cartography project, we are developing such visualizations in cooperation with several industry partners (including Allianz, AXA, BMW Group Systems, HVB Information Services, Munich Re, O2 Germany, and Siemens). Therein, not only static aspects of architecture, but also the evolutional stages of the constituents of EA are taken into consideration as well as the actual drivers of the evolution, e.g., the projects and programs executed within the enterprise. Having a powerful means for describing EA in general, we subsequently provide information on how these documentations can be used for facilitating enterprise risk management with special focus on IT-related risks.

Software Cartography for Risk Management

Facing the challenge of enterprise-wide risk management is geared to the collection of a large amount of data about the EA to gain greater transparency. Nevertheless, simply gathering data does not provide insights into the business and the supporting IT infrastructure. Value for the enterprise is only created if methods for processing of data in order to deliver insights into risk aspects are applied. Thereby, different stakeholders (project managers, business process owners, risk managers) need to be integrated into the risk-management process. Typically, the risk-management process can be divided into the following tasks: risk identification, risk assessment, and risk handling.

Each of these tasks needs the involvement of different stakeholders to be successfully conducted. As a result of the diverse stakeholders involved in the enterprise risk-management tasks, communication and understanding problems arise, caused by the different backgrounds and terminologies. Software cartography provides a solution to this challenge, as it provides intuitive visualizations that can be used as a basis for communication and discussion. Furthermore, these visualizations, called software maps, can be used to illustrate complex contexts and visualize gathered information in a condensed and audience specific way, e.g., for top-level management.

Getting back to one of the questions CIOs are faced with today, we subsequently provide detail on how software maps can be used to support the different tasks related to risk management. Trying to answer the question, “What is the impact, if a specific application system fails?”, the software map shown in figure 1 will be utilized. It illustrates which application systems rely on the support of which infrastructure elements. Further, it displays which business process steps need the support of which application systems during their execution.

Figure 1

Concerning the first step in risk management, a risk can be identified by analyzing the business support provided by the application systems and the infrastructure elements that host them. Taking a closer look at the application system App3, it must be noted that this application system provides a mandatory support for the conduction of the business process BP2. Additionally, the software map reveals that the infrastructure element Server2, which hosts the application system App3, endues only a low availability 1. Therefore, the breakdown of application system App3 should be considered to be a potential risk for the conduction of the business process BP2.

Following the risk identification task, a risk assessment should be conducted. Using the software map provided in figure 1, the business impact of the failure of application system App3 can be identified to be classified as a medium one. Finally, a risk-handling procedure should be created. In the described scenario, the replacement of the infrastructure element Server2 could be a possible solution as well as a redundant installation of the application system App3 on a second server could help lower the possibility of a breakdown thus reducing the expected business impact. The decision, which risk-handling procedure should be realized, depends on several aspects—such as the costs for purchasing and operating a new server or the amount of unused capacities on existing servers not displayed in the software map in figure 1. Additionally, evolutionary aspects of the EA have to be taken into consideration, i.e., the planned business support for the next planning periods should be analyzed prior to making a decision on the appropriate risk-handling procedure. For example, a project may exist that changes BP2 by outsourcing parts of it in a way that App3 is no longer needed for execution. In such a case, it might not be reasonable at all to introduce another server. Instead, keeping the old infrastructure and defining procedures for quick restart after the server breakdown could be more valuable for risk mitigation.

The simple example above does not attempt to capture the complexity of risk management in a large enterprise or explain the details behind availability and business impact metrics. Nevertheless, it is illustrative of how software maps can be used to visualize complex relationships and effectively communicate to the stakeholder community.

Conclusion

Enterprise risk-management procedures have to be integrated, holistic EA management endeavors that target all aspects of a company’s architecture from IT infrastructure elements to business level concepts, both from a static and an evolutionary perspective. To address this complex and all-embracing challenge, many stakeholders throughout the whole enterprise have to contribute their knowledge about the structural makeup of the EA in general and the application landscape in special, therefore, connecting formerly disconnected islands of information. In facilitating this, software cartography can provide a valuable means for communicating and exchanging this knowledge in order to support the different phases of enterprise-wide risk management endeavors. Here, we see the potentials for tool support, leveraging software maps in providing the information necessary for risk and business continuity management in a condensed and intuitively perceivable manner.

SABINE BUCKL and CHRISTIAN M. SCHWEDA are research assistants at the chair for software engineering for business information systems at the Technische Universität München (TUM—Munich University of Technology). Their research interests cover the field of software cartography, EA management, and related domains.