This document discusses the development of a visual modeling editor and ontology API to support decision making in enterprises. It describes three iterations of a solution to integrate enterprise architecture and intentional modeling approaches. The final proposed solution extends existing modeling tools with a metamodel, visual modeling capabilities, scripting support, and database integration to enable multi-user modeling and analysis of enterprise problems and strategic alternatives. This is aimed to better engage domain experts in the modeling process to define problems and potential solutions.
Visual Modeling and Ontology API for Enterprise Decision Making
1. Visual Modeling Editor and Ontology API-based
Analysis for Decision Making in
Enterprises- Experience and Way Ahead
Sagar Sunkle and Hemant Rathod
Tata Research Development and Design Center,
Pune, India.
8. Solution Iteration 1
ArchiMate motivation extensions provide goal modeling
constructs
– At a very high level- Goals, Assessment, Drivers- but no goal
modeling specific syntax or semantics
– i* provides well constructed goal/intention modeling syntax and
semantics
ArchiMate
+
Intentional
Models
9. Reflection 1
Archi OpenOME
Enterprise
AS-IS
Strategic
Alternatives
Enterprise
TO-BE
Enterprise
Entities
Problem-specific
Models
Actors and tasks for TO-BE
operationalization
Two Problems !!
Difficult to keep Archi[ArchiMate] and OpenOME[i*] models in sync
Each purposive model needs specific tool
Change Drivers Internal External
10. Extended Archi
with requisite
concepts for
Visual Models +
Ontology with
ArchiMate + i*
concepts for
analyzable models
From Visual Models
to analyzable
Export
Import
models .csv .xlsx .owl
Protégé editor, Jena OWL
ontology API, Pellet Reasoner API,
SPARQL query language
Solution Iteration 2
11. Extended Archi
with requisite
concepts for
Visual Models +
Ontology with
ArchiMate + i*
concepts for
analyzable models
Reflection 2
Possible to model “Why + What + How”
Ontological representation for constructing enterprise and intentional
analyses
− EA Change Impact Analysis- Change ripples computed based on semantics
attributed to ArchiMate relations
− EA Landscape Mapping- Retrieving specific pairs of EA elements from EA
model- set of business processes, application services they use, and
business services that expose the functionality in business processes
− Intentional Analyses- Label propagation for computing relative strengths
of alternatives, aggregate analyses such as ability, workability, and
viability of a course of action
Combined EA + Intentional analyses
− How to execute best strategic alternative on top of AS-IS EA
Idea validated, but scalability and modeling facility remain an issue
12. Future Solution Iteration 3
Extended
Enterprise
Metamodel
Model
Conforms To
Visual
Modeling
Analysis
Extended Archi
Extended
Enterprise
Metamodel
Model
Visual
Modeling
Analysis
ADEX
Conforms To
Ontology
Symbol Designer OMGen
13. Features of Solution Iteration 3
Modeling/Analysis
Feature
Archi (Eclipse
EMF)
Adex Required For
Metamodeling Yes Yes Purpose-specific modeling extensions e.g.
simulation of enterprise models
Visual Modeling Yes Yes Representing visual syntax agreed upon by
community
Scripting No [EMFScript
and other]
Yes [OMGen] For programming purpose-specific analyses
Database Support XML, CSV File, in memory,
MySQL, Oracle etc. Supporting modeling and analysis lifecycle
including role-based access to modeling
artifacts, and versioning
Multi-user/Role
Support
Versioning NO Yes
Diff-Merge
14. (Pre) Reflections on Solution Iteration 3
Scoping EA models
− Modeling enterprise without a clear problem definition is futile- intentional models help
define the problem and possible solutions
Adjusting syntax of purpose-specific modeling languages
− Enterprise and related models should focus mainly on analysis and lead to decision
execution
− Accordingly, standard syntax of modeling languages may need tweaking
Enabling domain experts
− So far, interaction was team of modelers who knew modeling languages + domain experts-very
difficult to make domain experts spare time
− Could domain experts model on their own as a matter of practice?
− Then they have to learn at least the domain-specific language syntax but this should
be OK
• Could domain vocabularies + rules help?
− Not only to enable different modeling languages talk with each other
− But also toward creating models of domain which could then be analyzed purposively