The document discusses the integration of enterprise architecture (EA) models with system dynamics (SD) models to better understand the dynamic behavior of enterprises. It outlines the key components of both modeling approaches, the need for a specialized SD metamodel, and the challenges involved in transforming EA models into SD models for simulation purposes. The authors emphasize the potential for context-based transformations but acknowledge limitations in validating larger models and the absence of immediate simulation semantics.

1. Toward Structured Simulation of
Enterprise Models
Suman Roychoudhury, Sagar Sunkle,
Hemant Rathod, and Vinay Kulkarni
Tata Research Development and Design Center,
Pune, India.

2. Motivation
• Enterprise Architecture (EA) Models-
– Holistic
– Descriptive; capture who in enterprise do what and how across
business, application, infrastructure layers
– Static; do not describe the dynamic behavior an enterprise exhibits
over time.
• System Dynamics (SD) Models-
– Useful for analysis of aggregates-
– Pertinent to EA models at higher level of abstraction than business
process models
• Use case- Business as usual improvement
– Simulation models derived from EA models could be used to study
dynamic behavior of modeled enterprise
– EA models are large; difficult to obtain simulation models by hand

3. EA (ArchiMate) MetaModels
Excerpt from Business Layer Metamodel
• Active, passive, and behavior elements are the key concepts
– Instantiated in each of business, application, and infrastructure layers
– Active elements are assigned to others- they control or contain other
elements
– Behavior elements write to or read from passive elements

4. System Dynamics Models
InFlow
OutFlow
Stock
Feedback
Adapted From:http://www.naturalthinker.net/
• Stocks, flows and converters [variables/feedback] are the
key concepts
– Flows add up to or remove from stocks
– Converters affect the flows
– Stocks, flows, and converters can be grouped into modules

5. EA and SD Concepts
EA Elements SD Elements Both Signify ArchiMate Examples
Behavior
Converters
Behavior BusinessProcess,
Elements
and Flows
ApplicationFunction
Passive
Structure
Elements
Stocks Passive nature; State; both
change based on [causal]
relations with other entities
BusinessDataObject,
ApplicationDataObject
Active
Structure
Elements
Modules Active nature; often contain
or control rest of the
entities
BusinessActor,
ApplicationComponent
• EA Behavior elements could be realized as SD converters or
flows
– Which is more apt? Converters cannot directly influence behavior of the stocks; esp. if EA
behavior element was related with a passive structure entity it must be flow rather than a
converter
– What if a EA behavior entity is related to both passive and active structure entities?
• Requires elaborating relations between SD elements

6. Need for SD Metamodel
• There is no SD metamodel that describes SD concepts by
specializing relations between SD elements
• Relations between SD elements are represented by generic
LINK concept- There are four different kinds of links
namely, a FlowLink, StockLink, ModuleLink and
ConverterLink
– Each sub-link type is categorized based on the source and target
model element it connects.

7. SD Metamodel

8. Specializing SD Element Links
• The sub-link types help in capturing EA element contexts
– E.g., when translating relation between a behavior and a active
structure entity in EA to corresponding SD representation; how the
behavior entity under consideration is (if at all) related with some
passive structure entities will determine whether it can be translated
as flow or converter.
– Depending on it, one of ModuleFlow, ModuleConverter,
FlowModule, or ConverterModule links captures the EA element
context pertaining to behavior and active structure entities.
ASE
BE uses
PSE
BE doesn’t
use PSE
ASE ASE BE is a Service
ModuleFlow ModuleConverter ConverterModule + FlowModule

9. Context-based Transformation
No. EA Element Context Transformed
SD
1A BE to ASE, BE uses a PSE
-ApplicationFunction to
ApplicationComponent
ModuleFlow
Link
4B BE to BE, both use PSE FlowFlow Link
8F BE to PSE, BE writes to
PSE
InFlow Link

10. Validation?
• Merits
– EA models of any size can be transformed-
• A large EA model in its entirety or selective elements alone
– Once SD model is available, simulation expert can discuss with
domain expert about changing quantities now represented as
stocks and flows
– Context-based transformation based on metamodel relations
enables traceability, but-

11. Yet to do- I
• Only small EA models structurally transformed to SD equivalents
– Need to validate with larger EA models
• No behavioral transformation
– It means that as is it, the SD models arrived at cannot be simulated
immediately!
– But SD models without any simulation semantics are better than no SD
models
– Early thoughts- Specify problem-specific variables etc. as attributes of EA
model entities and carry them over to SD model
• Currently mixed level of abstraction
– SD useful at aggregate level, but transformation will work for EA models
capturing any level of details
– Might require further steps in refining the transformed SD model, to frame
an aggregate problem

12. Yet to do- II
• Could SD models be built incrementally preserving both syntax
and semantics?
– Seems difficult since EA to SD transformation is context-based, once
transformation is complete EA context will be invisible
• Ongoing efforts within group- also using actor model of
computation
– Actor models can be built incrementally
– Causal relations between problem elements need not be known a-priori
– Enables instance based simulation- in EA and SD, a Developer can only be
at a higher level of abstraction like Role. Although possible, EA will
probably not contain instances of Developer Business Role (such as 10
developers with different programming language skills), SD does not
support type-based simulation anyway
– But instance based simulation means number of actors increases and
brings in difficulties in implementing simulation

13. Questions?
I can be reached at sagar.sunkle@tcs.com