A Risk-Based Approach Supporting Enterprise Architecture Evolution

Abstract

Enterprise architecture (EA) is a discipline driving change within organizations. The management of EA change is a challenging task for enterprise architects, due to the complex dependencies amongst EA models when evolving towards different alternatives (To-be models). In this paper, we present an approach supporting design decision during EA evolution. The idea is to reason on (To-be) models when evolving to a posterior state. To that end, we rationalize on a set of design decisions that are mapped on a non deterministic finite automaton, which is then evaluated by Markov decision processes. The idea consists of computing EA models valuations while integrating both alternatives rewards and risks metrics. In doing so, we consider risk as a correctness factor to choose the best alternative. Finally, we simulate our risk-based approach using a manufacturing scenario and discuss its usefulness and applicability.

1 Introduction

Enterprise architecture (EA) is a logical organization of a business and its supporting data, applications, and IT infrastructure [1]. EA clearly defines goals and objectives for the future success of the business. A typical architecture consists of models showing how aspects of your business relate. EA models have proven to be very useful for the management and governance of enterprises [2]. EA is composed of a multitude of EA models each being concurrently edited by different enterprise architects. Businesses should have an ‘As-is’ model that represents its current state, and planned models to show potential directions (To-be) of the business during EA evolution [3].

One of the many challenges an enterprise architect faces are risks when moving towards EA ‘To-be’ states. At every step in creating an enterprise design, architects need to analyze and evaluate risk. As definition, a risk is an unwanted event which can bring negative consequences to the organization. Risk management aims to identify and assess risks in order to define preventive controls to decrease the probability of occurrence of risk situations [4]. In most cases, risk assessment and treatment is done using the enterprises internal methodology or based on best practices known by the architect [5].

Current EA frameworks do not support risk appropriately due to inflexible EA models and missing guidance on risk identification and analysis [6, 7]. The integration of the different risk management processes at an enterprise level is a promising and still open research topic [4]. The Open Group Architecture Framework (TOGAF) associates specific risks to each of the nine identified phases of the architecture development method, however in the absence of a formal corporate methodology, architects are only limited to best practice [1, 8]. Moreover, risk management efforts operate in silos with narrowly focused, functionally driven, and disjointed activities. That fact leads to a fragmented view of risks including different models and metrics. The lack of interconnection and holistic view of risks limits an organization-wide perception of risks, where interdependent risks are not anticipated, controlled or managed [7].

In this paper, we propose a risk-based approach to support enterprise architecture evolution. The idea is to model a production/delivery process while analyzing risk factors when moving towards (To-be) models. This scenario models EA alternatives supporting outsourcing solutions. Outsourcing is an effective cost-saving solution when used properly. It can be adopted entirely or partly in the EA model. However, integrating outsourcing is not an easy task for architects. There are potential risks when dealing with outsourcing partners such as delays, privacy, and competency. In doing so, we present a reasoning method using Markov decision processes (MDP). MDP provides a mathematical framework for modeling decision making in situations where outcomes (i.e. risk factors) are partly random and partly under the control of a decision maker (i.e. enterprise architect). Our assumption consists of delivering valuations when the enterprise architect faces different EA model alternatives. These valuations are simulated using MDP and depend on both alternatives rewards and risks metrics. Based on these simulation results, enterprise architect will have the responsibility of taking a final decision whether the EA evolution should be committed to or reverted.

The remainder of this paper is structured as follows. Section 2 presents the research background. The motivating example is illustrated in Sect. 3 where we present three outsourcing options as alternatives in EA (To-be) models. Section 4 is dedicated to the approach including the reasoning method and its simulation tool. Related work are discussed in Sect. 5. Finally, Sect. 6 concludes and identifies future work to follow up this research effort.

2 Background

This section presents the background of our approach. Risk assessment is used to reason on computing best alternatives when modeling EA evolution. Further, the DEMO theory and methodology [9] are summarized, where DEMO is partially used to design risk scenarios in Sect. 3.

2.1 Risk Assessment

Today, risk management is mainly performed in a domain-specific manner. Different methods and approaches exist in the different risk-aware domains, e.g., information security, environment, project management, finance. Due to the huge number of references, it is not possible to provide an exhaustive list in this paper.

The most generally agreed upon definition of risk is the one found in ISO/IEC Guide 73 [10]. The risk is defined as a combination of the probability of an event and its consequence. Following this definition, risk management is defined as coordinated activities to direct and control an organization with regard to risk [10].

The scope of this paper is limited to risk assessment which is one the process in the risk management methodology [11]. Risk assessment is executed at discrete time points (e.g. once a year, on demand, etc.) and until the performance of the next assessment provides a temporary view of assessed risks. Risk assessment is often conducted in more than one iteration, the first being a high-level assessment to identify high risks, while the other iterations detail the analysis of the major risks and other risks. The process can be divided in the following steps:

• Risk analysis, further divided in:

  • Risk identification: the identification of risk comprises risk scenarios and risk factors.

  • Risk estimation: it assesses the risk impacts through the valuation of business assets.

• Risk evaluation: it compares each risk level against the risk acceptance criteria and prioritize the risk list with risk treatment indications.

Our approach defines a reasoning method based on risk assessment. In doing so, we need to identify risk scenarios and factors. Scenarios are identified in Fig. 2. Risk factors define risk criteria for evaluating risk. The risk criteria should reflect the objectives and context for the risk assessment. Adequate consideration should be given to the time and resources available, stakeholder views and risk perceptions, and the applicable legal and regulatory requirements [12].

2.2 DEMO Theory and Methodology

From the business processes point of view, DEMO (Design and Engineering Methodology for Organizations) theory and methodology [9] introduce capabilities to deal rigorously with the dynamic aspects of the process-based business transactions using an essential ontology that is compatible with the communication and production, acts and facts that occur between actors in the different layers of the organization. A DEMO business transaction model [13] encompasses two distinct worlds: (i) the transition space and (ii) the state space.

Fig. 1.

The DEMO standard pattern of a transaction between two actors with separation between communication and production acts (Adapted from [9])

On the one hand, the DEMO transition space is grounded in a theory named as $\varPsi$-theory (PSI), where the standard pattern of a transaction includes two distinct actor roles: the Initiator and the Executor. Figure 1 depicts this basic transaction pattern. The transactional pattern is performed by a sequence of coordination and production acts that leads to the production of the new fact. In detail, encompasses: (i) order phase that involves the acts of request, promise, decline and quit, (ii) execution phase that includes the production act of the new fact itself and (iii) result phase that includes the acts of state, reject, stop and accept. DEMO basic transaction pattern aims specifying the transition space of a system that is given by the set of allowable sequences of transitions. Every state transition is exclusively dependent from the current states of all surrounding transactions. There is no memory of previous states. This memoryless property holds with Markov theories.

On the other hand, the DEMO state space delivers the model for the business transactions facts, which are products or services, and are obtained by the business transaction successful execution. Throughout the business transaction execution more intermediate facts are required.

Integrating both the DEMO transition and state spaces, we obtain the inter restrictions of systems¹, which is composed by all the information links between actors and information banks (I-banks), and the mapping of all the responsibilities between actors.

3 Motivating Example

In the manufacturing sector one of the most important factors to increase profit margins is by optimizing the production process. Moreover, there is the delivery process which is closely related to production. Without an effective production/delivery strategy, deadlines can be missed and labour costs can eat into profits. Figure 2 describes the scenario from a business perspective using a non deterministic finite automaton. Each arrow defines the set of finite possible evolutions between models. Each model is represented by DEMO. The usage of a business transaction oriented methodology, such as DEMO, has the benefit of narrowing the domain of EA models to a single and self-contained set of models. As depicted in Fig. 2, each Model has many options to evolve, showing the non deterministic nature of a decision.

Fig. 2.

Mapping the set of possible evolutions ($\varphi _{1,2,3}$) from/to Models $M_{1,2,3,4}$: a non deterministic finite automaton representation.

The production/delivery process remains generic, but focuses on different models supporting four production/delivery strategies. After identifying client’s needs, we model four solutions to optimize their production scheduling and their delivery assignment. Basically, one key feature is about outsourcing both production and delivery. The main motivations which have led to outsourcing are the lack of expert-labor in some portions of the business process and the availability of cheaper labor whilst not comprising on the quality of output. Moreover, when outsourcing is introduced financial transactions become more complex and so an additional effort for information banks (I-banks) is required to synchronize financial auditing inter organizations.

Our concern in this paper is mainly about risk assessment with regards to the production/delivery strategy. It is always beneficial for an organization to consider the advantages and disadvantages before actually adopting one of these solutions (see Fig. 2). Risk can be a part of the outsourcing solution which has pros and cons to it. On the one hand, risk-sharing can be one of the advantages of outsourcing. Outsourcing certain components of your business process helps the organization to shift certain responsibilities to the outsourced distributor. Since the distributor is a specialist, they plan your risk-mitigating factors better. On the other hand, outsourcing disadvantages can be the risk of exposing confidential data or the delay in delivery time frames because of partner’s deficiency.

In our approach we prioritize the following criteria: regulatory compliance, cost, and project schedule. The first criterion deals with data security/integrity to comply with information banks (I-bank). The second criterion defines benefit-cost analysis to determine if it is a sound investment/decision. Benefits may be positive or negative when dealing with partners competencies. Finally, the project schedule criteria is a time-based risk which refers to delays, if it occurs, will impact the process.

4 Reasoning on Risk During EA Evolution

This section presents our reasoning approach integrating risk evaluation during EA evolution. In Sect. 4.1, we detail the foundations for obtaining the simulation results. Next, in Sect. 4.2, the motivating example is expressed in a mathematical form to allow its simulation. Subsequently, in Sect. 4.3, a Markov Decision Process (MDP) is used to simulate the production/delivery process and the achieved results are discussed. This simulation approach delivers a partial, yet valuable, valuation of the possible results obtained by the enterprise architect to decide upon a set of different EA models.

Fig. 3.

EA evolution process

4.1 Simulation Foundations

For simulation purposes, the reasoning approach for EA evolution is depicted in Fig. 3. Each step is enforced by the following:

• 1. (Figure 3 (1): Observation) the set of artifacts used at operation-time are observed and collected;

• 2. (Figure 3 (2): Intelligence) this step is equal to (1) if full observation is considered. However, if (i) uncertainty about the artifacts exists, or if (ii) due to manual task-based environments is not possible to automatically collect the data about the artifacts, or if (iii) different perceptions coexist within the organization in regard to the artifacts; then a partial observation solution should be considered. Partial observable Markov decision processes (POMDP) [14–16] solutions have potential to estimate the belief artifacts and could be used in these situations.

  In this motivating example, we merely consider that all the artifacts are observable and then a Markov decision processes (MDP) could be used in that situation. MDP valuates a given EA transformation process maximizing the expected value (V) after discounting the decay throughout time. A MDP is usually defined by the tuple $(S,A,P,R,\gamma )$ where:

  $S = \left\{ S_{1},...,S_{n} \right\}$ is a set of states, representing all the possible underlying states the process can be in (our motivating example represents S by the models M);

  $A= \left\{ A_{1},...,A_{n} \right\}$ is a set of actions, representing all the available control choices at each point in time (our motivating example represents A by the evolutions $\varphi$);

  

  is a transition matrix that contains the probability of a state transition, whereas i is the actual state and j is the final state if a given action a that is being used;

  $R = \left\{ R_{1},...,R_{n} \right\}$ is an immediate reward function, giving the immediate utility for performing an action that drives the system towards each state²;

  $\gamma$ is a discounted factor of future rewards, meaning the decay that a given achieved state suffers throughout time;

  $\rho = \left\{ \rho _{1},...,\rho _{n} \right\}$ is a risk function that is taken when an action that drives the system towards a state. A risk could be considered beneficial to the organization (positive) or prejudicial (negative). In this experimental set-up, for simplification, we consider $R = R + \rho$.

• 3. (Figure 3 (3): EA design) in regard to potential options, the enterprise architect need to design a new set of evolutions, e.g., designing a new set of rules or adding an information bank to coordinate actors. If partial observations are occurring, then the new artifacts will depend on the belief artifacts obtained in (2);

• 4. (Figure 3 (4): Choose best EA evolution) a qualitative and/or quantitative valuation of the best evolution to take. This step is the responsibility of enterprise architect. To support the architect the MDP is solved. There are many solutions available to solve a MDP. Our goal is to use MDP using a well-known solution with stable results. Therefore, to obtain the maximized V, we solve the MDP as specified by the following recursive Eq. 1:

  $$\begin{aligned} V(s) :=\sum \limits _{s'} P_{\pi (s)} (s,s') \left\lgroup R_{\pi (s)} (s,s') + \gamma V(s') \right\rgroup \end{aligned}$$

  (1)

  where: $\pi (s) := arg~\underset{a}{max} \left\{ \sum _{s'}^{} P_{a}(s,s') (R_{a}(s,s')+\gamma V(s')) \right\}$;

• 5. (Figure 3 (5): Enforce new EA model) equal to result of (4) if full actuation considered. Whether operational environment is not completely controllable then the evolution will be only partial enforced.

4.2 Motivating Example Set-Up

The example is herein presented by the following definitions: (i) models (M), (ii) evolutions ($\varphi$), (iii) transition matrix ($P_{ij}^{a}$), (iv) rewards matrix (R) and (v) risks matrix.

The conceptualization of M set is explained in Sect. 3, where: $M_{1}$ - Produce & deliver, $M_{2}$ - Produce & outsource deliver, $M_{3}$ - Outsource production but deliver, and, $M_{4}$ - Outsource production & deliver.

In regard $\varphi$, an EA model transformation is triggered whenever the enterprise architect decides to evolve the organization with a known purpose. In this context, the following set of evolutions ($\varphi$) decisions are considered: $\varphi _{1}$ - do not take any action, $\varphi _{2}$ - change boundary of the organization, and, $\varphi _{3}$ - change information bank (I-bank).

$P_{ij}^{a}$ is the probabilistic estimation between the evolutions ($\varphi$) required to transit from a model M to other M is presented cf. Table 1. Let p be the probability of $\varphi$ be successful. For simulation purposes, p is tested in the range [0.1, ..., 1.0] with small steps of 0.1 each. This approach offers more choice possibilities to the Enterprise Architect, including the non-success $\varphi$. In the top part of Table 1 ($\varphi _{1}$) it is assumed that the system will stay in the same state in the majority of the situations ($90\,\%$). In the middle part of Table 1 ($\varphi _{2}$) it is not allowed to transit to the same state. Moreover, more probability is given to the neighbor states as depicted in Fig. 2. Finally, the bottom part of Table 1 ($\varphi _{3}$), follows a similar approach of ($\varphi _{2}$) except that transitions between $M_{1}$ and $M_{2}$ are not allowed due to nonexistent I-banks.

Moreover, the reward matrix R is presented in Table 2. The sum of rewards for $\varphi _{2}$ and $\varphi _{3}$ are the same to challenge the MDP solver in identifying which is better the value possible for p. I-banks exist only in $M_{3}$ and $M_{4}$. Therefore, an higher reward is delivered when $\varphi _{3}$ is considered.

Exemplifying, the probability to be in state M3 at time $t+1$, being in state M3 and choosing $\varphi 1$ at time t, is $P(3,3,1) = 0.9$ and the associated reward is $R(3,1) = 1$. Translating for the scenario language, this denotes that keeping the model of outsourcing production but delivering in-house after doing no action has a probability 0.9 of occurring but offers a small reward (when compared with the other reward values).

In the end, the corrected rewards matrix is presented by Table 3. Two positive $\rho$ (risk) and two negative ($\rho$) are considered: $\rho _{1}$ ($-$) data inconsistency risk, $\rho _{2}$ ($-$) competence poor allocation, $\rho _{3}$ (+) data secured in-house, and, $\rho _{4}$ (+) better delivery time. Corrected rewards are presented with exaggerated values to overemphasize the impact of risk in the simulation. Again the need to risk estimation is broadly found in literature [12].

4.3 Simulation Results

The results shown below emphasize the rationale behind our approach to deliver valuation when the architect faces different EA model evolution options. This rationale is more important than the particular results obtained for the production/delivery process at hand. Moreover, this approach is used recursively: observing the reality, simulating different options, enforcing new models, and finally restarting the loop.

The MDP is computed by a $Matlab^{\copyright }$ toolbox³ using a linear programming algorithm. Figure 4 depicts the result from the MDP simulation. The intent of this motivating example is to show the benefits of using stochastic approaches to aid the EA architect decisions. This goal can be achieved if engineers are empowered with full pertinent information to forecast the impacts of their decisions in the near future of the organization. With this proposal, the architect is able to simulate different configurations (and evaluate them) before its implementation.

Table 1. Transition matrix ($P_{ij}^{a}$) containing the set of possible evolutions ($\varphi _{1,2,3}$) from/to Models $M_{1,2,3,4}$

Table 2. Reward matrix (R) containing the set of rewards when achieving a Model through each evolution ($\varphi _{1,2,3}$)

Table 3. Corrected rewards matrix containing the set of risks ($\rho _{1,2,3,4}$) that could occur when achieving a Model through each evolution ($\varphi _{1,2,3}$)

Fig. 4.

MDP simulation: $P_{ij}^{a}$ cf. Table 1; R cf. Table 2; $\rho$ cf. Table 3; $\gamma = 0.95$ and $p \in [0.1,...,1.0:0.1]$

In the top left corner, the value function is presented at each stage k, and each p value is separated. We observe that when $p \rightarrow 1$ then value function increases. In the top right corner, a value function is also delivered. However, the risks from Table 3 induce a correction to the Table 2. As shown, the results are the opposite from the former value function. In the bottom left corner, the elicited evolutions to fulfil the value function are depicted. For each p a different set of evolutions exist. Each set is represented by a different color. For $p \in [0.1,...,0.8]$ the optimal solution is given by the evolutions Change Boundary and then Change I-banks. But, for $p \in [0.8,...,1.0]$ the optimal solution is Change I-banks, then Change Boundary and finally back to Change I-banks. In the bottom right corner, for each p, we represent the percentage of time spent in each model. Here, we generally observe that changing p do not present a dramatic change in the percentage of usage of a model, except when $p \rightarrow 1$. This effect is mostly due to the balanced weights that are used in Tables 1 and 2.

Aggregating the previous results, the solution that maximizes the value function (without correction) is when $p=1$ and leading to a major use of $M_{3}$ (Outsource production but deliver in-house). Therefore, in this example, the probability (p) to succeed with an evolution ($\varphi$) seems to be a relevant variable to maximize the value function. Consequently, the enterprise Architect should take actions that maximize the chances of being successful. The remaining sub-optimal results are also useful, due to the occurrence of workarounds, it is not expected that any organizational operation will behave 100 % as prescribed [18, 19].

Conversely, considering that when $p \in [0.1,...,0.8]$ only 2 evolutions are demanded. But, for $p \in [0.8,...,1.0]$ there are 3 evolutions needed, then more changing costs could be incurred in this last interval of p.

Moreover, the differences between the MDP valuation graph (top left corner) and MDP valuation with risk-correction (top right corner) emphasize the great impact of risk in the EA evolution estimation process.

5 Related Work

Most of risk management methodologies are internal procedures for a company, e.g., the ones found in the guidelines of the Washington State Department of Transportation [20], that “provide information on how project risk management fits into the overall project management process” and “provide guidance on how to pro-actively respond to risks”. The main risk analysis is divided into a qualitative and quantitative approach: on the one hand, qualitative risk analysis assesses the impact and likelihood (high, medium, low) of the identified risks and develops prioritized lists of these risks for further analysis. On the other hand, in quantitative analysis a numerical estimation of the probability that a project will meet its cost and time objectives is made. In this paper, we integrate risks factors in the correction of design decision. Our evaluated risk values are computed with (To-be) models invariants and support different EA strategies.

ISO 31000 series of standards [4] defines the baseline for integrated risk management. Nevertheless, their guidance on risk identification and analysis is still informal and very few modeling and computing capabilities are offered. As stated in [12], the introduction of model-based approaches as support of risk management is motivated, first, by an efficiency improvement of the risk management process, and second by the enhancement of the product resulting from the performed process. Moreover, risk management methods usually provide list of common risks to consider, but do not provide capabilities to identify new risks or analyze them in depth. Regarding goal-oriented modeling frameworks, many of them provide risk management capabilities, mainly for dealing with information security risks: KAOS and its security extension [12, 21], Misuse cases [22], and Secure Tropos [23]. However, none of the aforementioned frameworks have addressed the EA evolution problem.

The Business Motivation Model (BMM) specification [24] suggests SWOT (Strength, Weakness, Opportunity, Threat) as an example of an approach for making assessments. In practice, enterprises can substitute different approaches, categorizing potential impacts as a risk which is a category of impact value that indicates the impact and probability of loss, and a potential reward which is a category of potential impact that indicates the probability of gain. BMM offers a solution for conducting a risk/benefit analysis; however BMM consideration remains static when dealing with evolution factors (i.e. risks) within enterprises.

6 Conclusions

This paper proposes an EA-driven organizational change process. One specific transformational change in EA is that of outsourcing. In this challenging context, we consider that a fully informed decision-making approach will empower the enterprise architects with tools to forecast the impacts of their decisions when outsourcing partly or entirely their processes. Subsequently, the enterprise architects will be able to decide upon which the best (or sub-optimal), and timely, action to be enacted is.

Our proposal is demonstrated by a stochastic simulation founded in the Markov decision processes theory, using a manufacturing scenario. On the one hand, four distinct EA models to optimize their production scheduling and their delivery assignment are available. Each model has its own risks. Some risks are positive and are beneficial to the organization, whereas other risks are negative and are prejudicial. On the other hand, three distinct evolutions are also available. The challenge posed to the enterprise architect is to choose the set of evolutions that maximize the value for the organization considering the associated risks. This solution shows the valuation throughout the intermediate EA evolution stages. Therefore, the organization is able to forecast not only the final valuation to be achieved, but also the correct value that will be chosen based on risk assessment.

As future work we identify the need to explore real world scenarios to enforce an informed decision-making approach that work, side-by-side, with practitioners. Moreover, a derived research problem is also identified where most of the operational environment observations are incomplete. Therefore, the alternatives that we are pretending to research will compulsory need to address the issue of environments that are usually called partially observable.