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.
%in Benoni+277-882-255-28 abortion pills for sale in Benoni
Visual Modeling Editor and Ontology API-based Analysis for Decision Making in Enterprises- Experience and Way Ahead
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