Framework for Creating and Executing Automated
Analysis Chains on Enterprise Models
David Bermeo, Juan Pablo S´aenz, Mario S´anchez, Jorge Villalobos
{da.bermeo529, jp.saenz79, mar-san1, jvillalo}@uniandes.edu.co
Systems and Computing Engineering Department, Universidad de los Andes, Bogot´a, Colombia
Enterprise Architecture (EA) provides companies with tools for documenting,
managing and analyzing the state of their business and IT. Among these tools
we find that Automated Analysis Functions help the architect to extract
valu-able information from complex enterprise models. The definition and
char-acterization of analysis functions in a universal catalog is a laborious work
and it’s impossible that this catalog is exhaustive enough. Each architect, with
his own expertise, may require particular analysis that can only be achieved
through executing an ordered sequence of different functions. We call this
se-quence an Analysis Chain. This paper proposes a language for defining Chains
and presents ArchiChain, a framework where these Chains can be created and
executed on enterprise models.
1
Introduction
Each day more and more companies are using Enterprise Architecture (EA) to understand their own organization and to provide valuable information for decision making. The basic tools
that Architects use to represent and then understand the state of the company are the Enterprise Models. Enterprise Models refers to the use of a modeling language to coherently specify and describe components of an organization along with their relationships [1].
After the Architects model the company the next task is passed to theanalyst. The analyst is responsible of extracting every piece of information that can affect the company’s decision process. This extraction is generally a human-made process and it becomes harder to do as the models keep growing. In order to assist analysts in their job the use of Automated Analysis Functions is being implemented. By automating the procedures to analyze the models and extract information from them it should be possible to work with larger models, in a more repeatable way. [2].
Despite the enormous help that Automated Analysis functions provide there are still con-siderable limitations. This functions usually serve a specific purpose and cannot be applied to every model. There has been a great effort in characterizing and cataloging as many functions as possible so its clear what they can do and what are the prerequisites of the model that each function needs to execute properly [3]. It is clear that cataloging every single function is im-possible and that each analyst would need particular and complex analysis that only they need. How can analysts define more functions without the obligation to create them from scratch? The answer is to use Analysis Chains.
This paper continues the work of [4] by presenting a framework where the chains can be defined and executed. The framework consists in the language for defining the chains and a tool capable of creating, editing and executing the defined chains on Enterprise Models.
The paper is organized as follows: In Section 2, we characterize Analysis Chains based on [4] and we list the requirements that a framework needs in order to define chains. In tion 3 we present ArchiChain’s language and how it fulfills the requirements proposed in Sec-tion 2. Next, in SecSec-tion 4, we present the tool developed for ArchiChain and we apply it on
ArchiSurance. Finally we discuss related and future work.
2
Analysis Chains
The concept of Analysis Chains arises because we noticed that some sets of analysis functions were frequently used together. Also, there were sequences of analysis methods that were re-peated several times, using slightly different parameters. Based on this situation we decided to study these sequences in order to offer architects better tools to support the processes that they were naturally doing. An Analysis Chains was defined as: configurable sequences of analysis methods with a common analysis goal, assembled and configured to guarantee consistency in their inputs and outputs.
In order to create a Chain we must assemble together different Analysis Functions. This generates an issue because functions are not designed to fit naturally when they are put one after another, the outputs of one may not be the required inputs of the other. The strategy to address this issue consisted in three ideas. The first idea was to include transformation functions in the chain to eliminate the inconsistencies. The second idea was to use that a basic metamodel as a canonical language along the entire analysis chain and then the transformation functions will take the model and transform it to a coherent one for each step. The third idea was managing the artifacts each step produced as models, by means of transformations, so they could be used naturally for the next step.
Following this strategies we solved the compatibility issue but still there were times that some steps needed additional information, besides the outputs of previous steps, in order to start. This extra information was meant to be provided by the analyst. The analyst can intervene in the execution of the chain in two ways: the first is to tweak the chain by providing the extra information to continue to the next step (this is generally a simple parameter that needs to be defined) and the second is to be directly involved in one of the steps by taking the previous
outputs and with his expertise produce his own output that will continue with the Chain. This is fundamental in the Chains because there are situations where the expertise of the analyst can’t be coded in a function so the analyst must intervene to complete the Chain.
Figure 1: Analysis Chain, step by step
In Figure 1 we can see an Analysis Chain step by step: First the analyst picks the EA Model to analyze. Then he starts the execution of the chain. Each step is supported on either an Analysis function or in the analyst expertise. The result of each step and some additional information are used as inputs for the next step. The Analysis Chain concludes just like an
Analysis Function, with findings, recommendations, assessments and also artifacts that can be used for another chain.
If we are going to define a language that fully characterizes the Analysis Chains and that is flexible enough so analysts can use it in a real world context, we have to make sure the language fulfills the following requirements:
R1: Congruence between coding and chaining. The purpose of this requirement is to assure there is no difference between creating a new analysis function by coding it from zero or by defining it as a Chain. The language must be sufficiently expressive to define anything we could code, this includes taking decisions while executing and looping parts of the chain (See
R2andR3).
This requirement is essential to our approach because it guarantees that there is no limit in what the framework can create. Also, analyst won’t be forced to learn to code plugins for Archi but instead they’ll only need to build the chains from existing analysis functions.
R2: Conditional decision making. In order to increase the expressiveness of the language there has to be conditional reasoning inside the chain, this means the chain can decide what to do next given the results of its previous steps. This requirement significantly increases the expressiveness of the language because it extends the length of the chains to a maximum before needing the analyst to intercede.
UnlikeR5, where we are interested in analyst intervention during the execution of the Chain, conditionals delegate the chain to make the proper decisions to keep on going. Without this requirement the language would be limited to linear chains that only work for specific scenarios and that don’t comply with what we described before.
R3: Iterative executionFollowing the line of thought of R1and R2this requirement in-tends to expand the language capabilities. Analysis chains need to be capable of repeating certain steps until some criteria is met, it could be a simple count or a condition over the result
of a certain step. This requirement gives the analyst the option to execute multiple times the same part of the chain until he gets a desired result. For example an analyst wishes to execute a particular analysis over every component in the model. Instead of executing one by one the analysis he can delegate this repetitions to the chain and thus go over every component of the model and execute it.
R4: Chains can use existing chains as links. The purpose of this requirement is to extend
R1. Just as we can reuse code its only logical that we can reuse chains as well. This is why the definition of chains must include re-usability mechanisms.
R5: Analyst interaction. As we previously discussed in the Section there is a point in the Chain where the analyst must introduce information into the chain. This requirement makes explicit that the chains can pause mid execution and ask the analyst for extra information so the next steps can be properly executed.
R6: Simple data as inputs. Chains need to be capable of receive simple data, like strings and numbers, as part any step’s input. Taking into account that analyst can introduce infor-mation during the execution of the chain R5 we can’t expect that they manually create and introduce an artifact as additional information for the Chain. Simple data is the natural way in which chains receive the necessary information to continue their execution.
3
ArchiChain Language
As part of the framework we created a language to define Analysis Chains, this language is XML-based. We decided to do a XML-based language because it facilitated the reading process either by an analyst or by the tool. Also the hierarchy that XML provides a clear visualization of the execution order. Figure 2 shows the structure of the language as a hierarchy tree.
The starting and principal node is: chain. This node must have the following descriptive attributes:
Figure 2: ArchiChain language structure
• name: The name of the Chain. This name will identify the Chain for future executions and uses.
• description: A brief description of the purpose of the Chain. It should include a descrip-tion of each of the necessary inputs and the resulting outputs.
• inputNames: A list with the names of the required inputs for the Chain. This list must include the minimum inputs that the Chain needs to start executing.
After these attributes are defined the chain node contains function,if, and while nodes that will be executed sequentially. The most relevant node is the function node.
A function node represents an Analysis Function as a link of the chain. This node needs a class attribute to specify which Analysis Function is being used. Additional to the class the respective inputs and outputs must be inside the function node. The inputs can be defined in three ways:
• value: The input is a constant value specified inside the chain.
• referencedId: The input is taken from the resulting output of a previous function.
• userInput: If the chain requires analyst intervention during the execution this node will stop the execution and ask the analyst for the corresponding input (SeeR5).
The output nodes are contained inside the outputs node. These nodes give each of the function’s results a referenceId that can be referenced by an input of an incoming function. If certain result is not needed any more in the Chain the node can be empty so that the result is not saved to increase the efficiency of the Chain.
To fulfillR2it was imperative to introduce an ”if” statement in the Chain definition. An if node is structured as follows: first the condition is what the Chain will check for truthfulness. If the condition is true the Chain proceeds to execute the consequent. On the other hand if the condition is false the Chain proceeds to execute the alternative. This structure is congruent with coding:
if(condition) {consequent} else {alternative}
The congruence between coding and Chaining is a support forR1.
The condition of the if is defined as an equation. He have a Right Hand Side (rhs) and a Left Hand Side (lhs) and a relation. The relation can be binary (<,≤, >,≥,==,! =, ...) or unitary
(IS NULL, IS NOT NULL,...). Just as the inputs the rhs and lhs can be given as a value or as a referencedId. There is no point in receiving a userInput in the rhs or lhs because the purpose of the if is to give the chain autonomous decision capabilities (R3). The consequent and the alternative nodes contain a sequence of instructions that are going to be executed depending on the whether the condition is true or false. These instructions can be functions,whiles and ifs. By letting additional ifs to be part of the consequent and the alternative we extend the language’s expressiveness because we can build stronger conditions and also we can define situations like an elseif.
The while node is composed by a condition and the statements. The condition is defined exactly as it is defined in the if node. The statements node, just like the consequent and alter-natives node, contains a sequence of instructions that can include functions, ifs and whiles. If the condition is fulfilled the instructions in the statements are executed. After the execution of the statements the condition is checked again. If the condition is still true the statements will be executed again until the condition is no longer fulfilled. It’s very important that the statements node contain an instruction that can modify the truthfulness of the condition, if not the Chain will never end.
4
ArchiChain Tool Exemplified in ArchiSurance
ArchiChain’s language is fairly easy to read but, being a XML-based language, its very labo-rious to write and its prone to several syntactic mistakes. In order to enhance ArchiChain we developed a tool to create, edit and run Chains in a relatively easy manner. The tool is built over Archi: an open source ArchiMate Modelling Tool. The best way to present the tool is with a working example of a Chain being executed over a common knowledge model.
The model we are using is an Application Usage View taken from the ArchiSurance Case Study (See Figure 3). This model was selected because it’s clear to understand and its big
enough to present a challenge to analyst to extract relevant information. We added two proper-ties to the model in order to fit the requirements of our Chain:
• Core: An Application Service attribute set in ”true” in the core services (Customer Ad-ministration, Claims AdAd-ministration, and Payment) and ”false” in the support services (Scanning and Payment).
• TPH: An Used By Relation attribute that shows how many transactions per hour are sent from the process to the service.
Figure 3: Archisurance: Application Usage View
In this particular model, or in any Application Usage View, an analyst would be interested in knowing which Applications Components are being overworked by core services used by the Business Process. In order to get this information we will create a Chain with our tool (See figure 4). ArchiChain Tool lets the analyst browse the current Chainable functions and build, block by block, the desired Chain. Table 1 fully describes the analysis chain we want to obtain.
ID:CHQ001 Dimension:Quantitative Type:Capacity Planning
Name:Application Component Core Overuse Layer:Application and Business
DescriptionThe Application Component Core Overuse Chain detects and documents which Application components are being used over a threshold defined by the analyst. The Chain takes the model and the defined threshold and produces a catalog with the overused compo-nents along with their Transactions per hour (TPH)
Entities and relationsApplication components/services are Used By Business Processes.
Structural Attributes
-Application Service:[Core: (true, false)] -Used By Relationship:[TPH]
Input metamodelArchiMate model.
Algorithm
1. The analyst defines a threshold
2. We identify the Application Components in the model
(a) For each component we get the Application Services related to them
(a) For each Service we determine if it is a core service based on the attribute (b) If it is a core service we get the total TPH using the chainCHQ002
i. For each Relation we extract the TPH and we add them together (c) We add the TPH of the services
3. If the joint TPH is greater than the threshold the result is stored
Output metamodel Catalog. In particular for this function it is a catalog of Application Components with the Transactions Per Hour that their core services are being used.
Figure 4: Create Chain in Tool
• CHB001 Addition:This function receives two values adds them together and returns the result.
• CHB002 Get Children: This function returns a catalog of the children elements of a specified element. The input for this function is the id of the parent element.
• CHB003 Relationships from Element: This function returns a catalog of the relation-ship elements with a specified source element. The input for this function is the id of the source element.
• CHB004 Catalog: This function returns a catalog of the elements of a specific class in the model.
specified index.
• CHB006 Get Property in Element: This function returns property of the specified ele-ment.
• CHB007 Get Property in Relation: This function returns property of the specified rela-tionship.
Besides the basic functions we will chain the already defined chain described in Table 2. Its easy to notice that by building this chain we are complying with all the requirements established for the framework. We have conditional decision making when we consider only the core services; we iterate over all application components and all of their services; we include an existing chain as a link of the new chain and finally we let the analyst intervene by defining the threshold as a simple value.
After the Chain is created we can execute it in the tool. The results are displayed as a catalog and are saved for future reference. With a threshold of 1500 the results are the following:
Component TPH
Home & Away Policy Administration 16000 General CRM System 2000
5
Future and Related Work
While developing the framework we noticed that the more basic functions we had, the more creative we could be with the chains’ definitions. This is why we consider that the natural way to extend the framework is to define and document a robust set of base functions. But it is not enough to have the basic functions be the only foundations of the framework, by building a repository with the chains that each analyst creates the framework becomes fully functional tool that exceeds particular needs.
ID:CHQ002 Dimension:Quantitative Type:Capacity Planning
Name:Application Service Use Layer: Application and Business
DescriptionThis function calculates the total transactions per hour the service that is been used
Entities and relationsApplication services are Used By Business Processes.
Structural Attributes
-Used By Relationship:[TPH]
Input metamodelArchimate model and id of an Application Service in the model
Algorithm
1. For each Service we determine if it is a core service based on the attribute 2. If it is a core service we get all the Used By Relations coming from the service
(a) For each Relation we extract the TPH and we add them together If the joint TCH is greater than the threshold the result is stored
Output metamodel Catalog. In particular for this function it is a catalog of Application Components with the Transactions Per Hour that their core services are being used.
References
[1] H. Jonkers, M. M. Lankhorst, R. van Buuren, S. Hoppenbrouwers, M. M. Bon-sangue, and L. van der Torre, “Concepts for modeling enterprise architectures,” International Journal of Cooperative Information Systems, vol. 13, pp. 257–287, 2004.
[2] H. Florez, M. S´anchez, and J. Villalobos, “Extensible model-based approach for supporting automatic enterprise analysis,”
[3] A. Ramos, P. Gomez, M. S´anchez, and J. Villalobos, “Automated enterprise-level analysis of archimate models,”
[4] A. Ramos, J. P. S´aenz, M. S´anchez, and J. Villalobos, “On the support of automated analysis chains on enterprise models,” 2015.