Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Toward Structured Simulation of Enterprise Models

339 Aufrufe

Veröffentlicht am

Today's Enterprises exist in highly dynamic environment. While enterprise-architecture (EA) based models help in holistic treatment of enterprise aspects, they are static in nature and do not represent the complex dynamic behavior of enterprise as it evolves over time. Instead of relying on guideline for simulating EA models as in other approaches, we propose a comprehensive metamodel of system dynamics and provide relation-based mapping to EA metamodel. Ongoing explorations suggest that while several challenges of simulating enterprise aspects remain unaddressed, in the least we take a step toward making simulation of EA models more structured.

Veröffentlicht in: Software
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Toward Structured Simulation of Enterprise Models

  1. 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. 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. 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. 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. 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. 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. 7. SD Metamodel
  8. 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. 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. 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. 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. 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. 13. Questions? I can be reached at sagar.sunkle@tcs.com