While a considerable amount of research on enterprise ontologies exists, work showing how to use ontologies for enterprise architecture (EA) analysis is scarce. We present our ongoing work on creating analyzable enterprise models using EA-based ontological representation. Our contributions are twofold: first, we show how an existing EA modeling language can be leveraged to create EA ontology and second, we show how EA analyses can be realized using this ontology. Initial results of basic EA change impact analysis suggest that ontology representation facilitates EA analysis prototyping due to right mix of representation and reasoning functionalities.
From our past experience in delivering 70+ large business-critical enterprise
applications using model-driven [
For this we create an EA ontology that is based on concepts and entities in
ArchiMate [
The rest of the paper is structured as follows. In Section 2, we elaborate our motivation and describe our EA ontology based on ArchiMate concepts and relations and how we model the case study using this ontology. In Section 3, we detail a basic change impact analysis with an implementation with ontology tools. We then discuss related work and conclude the paper in Section 4. 2
A model of enterprise is generally created based on the principles of what is known as enterprise architecture (EA). It is defined as the process of translating business vision and strategy into e ective enterprise change1. We wanted to create model of enterprise as a computational representation of business, IT, and infrastructure dimensions and capture aspects such as structure, behavior, and information etc. across these dimensions. This is illustrated on the left of Figure 1.
Business IT Infrastructure e r u tc u r t S r o i v a h e B n o i t a m Ifr o n r e h t O
M itrrseenpSuNfeficceiessnatrDyeatnadils lzyaanA liaaunp lEAnalysis Results leb leb aeR +
l
Consistency Concept Queries Rules
Checking Satisfiability
isu tEn
gn rep EA
nO irs -b
t
o
l
gyo eedoM saed
As a first step in creating such an enterprise model we looked into EA frameworks
which assist in the process of creating, maintaining, and leveraging architecture of
an enterprise [
In contrast, representing enterprise models using ontology provides both machineprocessability and a number of reasoning services including consistency checking. It is possible therefore to make application of EA frameworks and techniques more or less person-independent. These models could be used to conduct various analyses of the real enterprise that they capture and utilize the results by possibly making changes to and/or improving the real enterprise. This is shown on the right of Figure 1. 2.2
EA Ontology
To create our enterprise ontology, we refer to ArchiMate metamodels of business, IT,
and infrastructure dimensions [
Basic Elements of EA Ontology We retained the distinction made in ArchiMate
around business, application, and infrastructure layers as well as structural (active and
passive) and behavioral concepts in the EA ontology. Active structural concepts signify
actors, behavioral concepts signify tasks and passive structural concepts signify objects
acted upon. Relations are also distinguished as being structural and behavioral but the
same set of relations occur across all three layers as indicated by generic metamodel of
ArchiMate [
Case Study and Instantiated Model Archisurance is an enterprise architecture and
modeling case study referred to in [
Ontology Tools We used the open source ontology editor Protégé2 to build our EA ontology and to instantiate Archisurance model. We use Apache Jena3 semantic web application framework for API-based access to ontologies specified in web ontology language (OWL). To programmatically invoke reasoner services, we use Pellet4 API. 2 http://protege.stanford.edu/ Protégé Ontology Editor 3 http://jena.apache.org/ Apache Jena 4 http://clarkparsia.com/pellet/features Pellet Reasoner For querying as well as executing rules over Archisurance model, we rely on SPARQL5 which is a query language for resource description framework (RDF - Serialization format for OWL ontologies). 3
Change impact analysis for EA is concerned with computing the e ects of change in
any part of an enterprise on the rest of the enterprise [
The basic idea of change impact analysis in EA is centered around a set of
heuristic rules based on the nature of relations that connect concepts. Such heuristic rules
take the form of ‘If there is a relation of kind X between concepts A and B, then when
A is deleted/modified B needs to be deleted/modified/is going to be dangled.’, where
X is an ArchiMate relation [
Listing 1.1: INSERT Query Form for composedOf relation in SPARQL 1 INSERT 2 { ?b :Deleted true . } # Then b is deleted as well. 3 WHERE 4 { 5 # If a is composed of b 6 ?a :composedOf ?b . 7 # and a is deleted 8 ?a :Deleted true . 9 };
EA Change Impact Analysis with Ontology A rule can be specified in SPARQL using the CONSTRUCT query form. CONSTRUCT generates new facts based on existing facts that match patterns specified in the WHERE clause. The facts generated by CONSTRUCT are nevertheless not updated in the base ontology. For this we can use the INSERT query form.
Listing 1.1 shows that when a is composed of b and a is deleted, then so should be b. This SPARQL query is in Terp format which is a combination of Turtle and Manchester syntax for RDF serialization6. The WHERE clause specifies if part and CONSTRUCT 5 http://www.w3.org/TR/rdf-sparql-query/ SPARQL RDF Query Language 6 www.w3.org/2007/02/turtle/primer/ Turtle Syntax for SPARQL Relation X accesses assignedTo usedBy realises triggers composedOf clause specifies the then part of a rule. Unlike CONSTRUCT, INSERT actually updates the boolean data type property Deleted to true. Note that similar to INSERT there is a query form called DELETE, but we do not want to delete anything from the underlying ontology, only indicate using a boolean flag that a concept is deleted.
Executing such rules over an ontology is achieved by loading the ontology (.owl file created, say in Protégé) as an Apache Jena ontology model via Pellet reasoner factory. Then, a GraphStore is created with this model which acts as a container for graphs of triples to be updated in the underlying ontology. The INSERT rule for instance can then be executed over this ontology and the updated ontology is returned via updated GraphStore. When talking about updating ontology, we are referring only to individuals rather than classes. Only the model is updated, not the metamodel.
Implementation Results To see the e ect of executing such rules over the representation of entire enterprise, we refer the reader to Figure 2 which shows a snapshot of Archisurance with concepts that are related to the ApplicationComponent HomeNAwayPolicyAdministration. We wish to know what would happen if this concept is deleted. As shown in Table 1, deleting concepts leads to deleting concepts they are related to when relations are realises and composedOf . Deletion of a concept is treated as a trigger for a change ripple.
To actually a ect change ripples, we have to execute INSERT for all relations as enumerated in Table 1 in one iteration. The iterations continue, until no new nodes (concepts) in the GraphStore have their Deleted property updated to true. This is shown in Listing 1.2. All the *Update strings are essentially INSERT queries similar to Listing 1.1. Once the iterations stop, we get all nodes (concepts) that are deleted (i.e., need to be deleted) or have been dangled (i.e., are potentially dangling) due to deletion of HomeNAwayPolicyAdministration.
Listing 1.2: Ripple E ect Computation due to Deletion of a Concept 1 public void affectRipples(String startConcept) { 2 ... 3 while (rippleOut){ 4 UpdateAction.parseExecute(prefix + accessUpdate , graphStore) ; 5 UpdateAction.parseExecute(prefix + assignedToUpdate , graphStore) ; 6 UpdateAction.parseExecute(prefix + usedByUpdate , graphStore) ; 7 // also execute usedBy, realises, triggers, & composedOf over graphStore 8 ... 9 resultsNumNodes = com.clarkparsia.pellet.sparqldl.jena.
SparqlDLExecutionFactory. create(numNodesUpdated, model ).execSelect(); while (resultsNumNodes.hasNext()) {
QuerySolution row= resultsNumNodes.next(); RDFNode concept= row.get("updatedConcepts"); ... // Collect concepts that changed } ... // Continue until no new concepts change
Upon executing, we find that concepts that are deleted are {PolicyDataManagement, CustomerDataAccess, RiskAssessment, ClaimInformationService, PolicyCreationService}. Similarly concepts whose relations could now be potentially dangling are {FinancialApplication, CheckAndSignContract, WebPortal, CallCenterApplication, FormaliseRequest, CustomerDataMutationService}. Note that e ects of this deletion reach from the application layer to the business layer due to relations between a ected concepts. Deletion of HomeNAwayPolicyAdministration results in making the relations of all business layer concepts shown in Figure 2 to be potentially dangling. Only the accesses relations to concepts {CustomerFileData, InsurancePolicyData} and usedBy relation to {PremiumPaymentService} remain una ected.
It is possible in this way to represent e ects of any change specified in Table 1. Since we do not actually delete a concept in the ontology, we do not have to order the updates. For instance, RiskAssessment application component is both deleted (because HomeNAwayPolicyAdministration is deleted) and dangled (because CustomerDataAccess is usedBy RiskAssessment and CustomerDataAccess is deleted because HomeNAwayPolicyAdministration is deleted). We simply indicate that both deletion and dangling is possible for the concept RiskAssessment.
With this implementation infrastructure, it is easily possible to see which concepts of a given kind in a given layer are most important and any change to these should be treated with care. It is also possible to go from a coarser level of changes (i.e., deletion or modification or concepts) to finer levels where value of a specific property changes for a given concept leading to similar changes in properties of other concepts. The point we want to stress is that with the ontological representation and rule execution, variants of change can be easily conceptualized and tested for impact analysis in EA. 4
Previous ontology approaches targeted specific aspects of enterprises rather than taking
a holistic view of them, for instance activities and resources [
EA frameworks provide holistic treatment of enterprise systems but lack machineprocessability, modeling assessment, and analyzability. Ontologies help in addressing these issues in general and we showed in this paper how current ontology tools can be utilized in concert to create machine-processable enterprise models based on ArchiMate EA framework. We also showed that various existing EA analyses that are based on the nature of concepts and relations can be readily prototyped with this infrastructure. The same advantages can be obtained if EA ontology was based on any other EA framework. Transferring the results of EA analysis to actual enterprise still requires human intervention and automating this to the maximum extent possible constitutes part of our ongoing work. Yet we believe that using ontologies to address these issues as shown in this paper takes a small step in that direction.