The present application claims priority to Indian Provisional Patent Application No. 2731/MUM/2014, filed on Aug. 31, 2014, the entirety of which is hereby incorporated by reference.
The present disclosure described herein, relates to enterprise modeling and simulation, and more specifically, the present disclosure relates to systems and methods for simulating enterprise architecture.
Enterprise architecture (EA) modeling is a well-defined practice for conducting an enterprise analysis, design, planning, and implementation, using a holistic approach, for successful development and execution of new strategies in an enterprise. Enterprise Architecture (EA) modeling techniques support business process reengineering of the EA by capturing existing processes and based on perceived outputs, support design of future process models capable of meeting the enterprise requirements. One of such enterprise modeling technique is System Dynamics (SD) modeling. The System Dynamics modeling tools are used extensively for policy analysis and modeling of dynamic aspects of the enterprise. The SD tools are also used for understanding behavior of complex systems of the enterprise over time. The SD tools also provide fundamental contributions to framing, understanding, and discussing complex issues and problems associated with the enterprise, however the SD tools do not provide any implication on how elements of the system should be reconfigured to yield a desired behavior.
Though the EA based models help in holistic treatment of the enterprise aspects; the EA based models are essentially static or visual in nature and cannot be typically processed by a machine. Human interpretation of such visual models of the EA is error prone and inconsistent due to varied understanding of the enterprise by each individual. Further, due to the vast nature of the models, manual analysis of the EA models is often impossible. To overcome these limitations, machine process-able simulation based techniques may be used by which human understanding of the enterprise is encoded in the form of simulation models that enables analysis of the enterprise for Business As Usual (BAU) improvement. However, manually building such simulation models from the static EA based models is time and effort consuming. Moreover, as there is no standard technique available, any manual translation mechanism is itself error prone.
Before the present systems and methods, are described, it is to be understood that this application is not limited to the particular systems, and methodologies described, as there can be multiple possible embodiments which are not expressly illustrated in the present disclosures. It is also to be understood that the terminology used in the description is for the purpose of describing the particular versions or embodiments only, and is not intended to limit the scope of the present application. This summary is provided to introduce concepts related to a method and system for structured simulation of enterprise architecture and the concepts are further described below in the detailed description. This summary is not intended to limit the scope of the disclosure.
In one embodiment, a system for generating a system dynamics model of an enterprise is illustrated. The system including a memory and a processor coupled to the memory, wherein the processor is configured to execute instructions stored in the memory for maintaining a mapping table in a repository, wherein the mapping table is configured to store a master set of enterprise architecture relations and a master set of system dynamics meta-model links, wherein each enterprise architecture relation, of the master set of enterprise architecture relations, is mapped with at least one system dynamics meta-model link of the master set of system dynamics meta-model links, and wherein each enterprise architecture relation is captured from historically analyzed enterprise meta-models. Further, the processor is configured to receive an enterprise model that conforms to an enterprise meta-model. In the next step, the processor identifies a set of enterprise architecture relations from the enterprise meta-model. Further, the processor is configured to receive a reference system dynamics meta-model, wherein the reference system dynamics meta-model corresponds to a system dynamics model to be developed for the enterprise. Furthermore, the processor compares the set of enterprise architecture relations with the master set of enterprise architecture relations based on the reference system dynamics meta-model to identify a sub-set of system dynamics meta-model links corresponding to the enterprise meta-model. Based on the sub-set of system dynamics meta-model links, the processor is configured to generate the system dynamics model.
In one embodiment, a method for generating a system dynamics model of an enterprise is illustrated. The method includes maintaining a mapping table in a repository by a processor, wherein the mapping table is configured to store a master set of enterprise architecture relations and a master set of system dynamics meta-model links, wherein each enterprise architecture relation, of the master set of enterprise architecture relations, is mapped with at least one system dynamics meta-model link of the master set of system dynamics meta-model links, and wherein each enterprise architecture relation is captured from historically analyzed enterprise meta-models. Once the mapping table is generated, in the next step, an enterprise model corresponding to an enterprise is received, wherein the enterprise model is in conformance with an enterprise meta-model of the enterprise. Further, the processor identifies a set of enterprise architecture relations from the enterprise meta-model. Further, the processor is configured to receive a reference system dynamics meta-model, wherein the reference system dynamics meta-model corresponds to a system dynamics model to be developed for the enterprise. In the next step, the processor compares the set of enterprise architecture relations with the master set of enterprise architecture relations based on the reference system dynamics meta-model to identify a sub-set of system dynamics meta-model links corresponding to the enterprise. Based on the sub-set of system dynamics meta-model links, the processor is configured to generate the system dynamics model corresponding to the enterprise.
In one embodiment, a computer program product having embodied thereon a computer program for generating a system dynamics model of an enterprise is disclosed. The computer program product includes a program code for maintaining a mapping table in a repository, wherein the mapping table is configured to store a master set of enterprise architecture relations and a master set of system dynamics meta-model links, wherein each enterprise architecture relation, of the master set of enterprise architecture relations, is mapped with at least one system dynamics meta-model link of the master set of system dynamics meta-model links, and wherein each enterprise architecture relation is captured from historically analyzed enterprise meta-models. Further, the computer program product includes a program code for receiving an enterprise model corresponding to an enterprise. Further, the computer program product includes a program code for conformance of the enterprise model with respect to an enterprise meta-model and identifying a set of enterprise architecture relations from the enterprise meta-model. Further, the computer program product includes a program code for receiving a reference system dynamics meta-model, wherein the reference system dynamics meta-model corresponds to a system dynamics model to be developed for the enterprise. Furthermore, the computer program product includes a program code for comparing the set of enterprise architecture relations with the master set of enterprise architecture relations based on the reference system dynamics meta-model to identify a sub-set of system dynamics meta-model links corresponding to the enterprise. Further, the computer program product includes a program code for generating the system dynamics model based on the set of system dynamics meta-model link.
The foregoing summary as well as detailed description of embodiments of the present disclosure is better understood when read in conjunction with the appended drawings. For the purpose of illustrating the disclosure, there is shown in the present document example constructions of the disclosure; however, the disclosure is not limited to the specific methods and apparatus disclosed in the document and the drawings.
The detailed description is described with reference to the accompanying figures. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The same numbers are used throughout the drawings to refer like features and components.
Some embodiments of this disclosure, illustrating all its features, will now be discussed in detail. The words “comprising,” “having,” “containing,” and “including,” and other forms thereof, are intended to be equivalent in meaning and be open ended in that an item or items following any one of these words is not meant to be an exhaustive listing of such item or items, or meant to be limited to only the listed item or items. It must also be noted that the singular forms “a,” “an,” and “the” include plural references unless the context clearly dictates otherwise. Although any systems and methods similar or equivalent to those described herein can be used in the practice or testing of embodiments of the present disclosure, the exemplary, systems and methods are now described. The disclosed embodiments are merely exemplary of the disclosure, which may be embodied in various forms.
Various modifications to the embodiment will be readily apparent to those skilled in the art and the generic principles herein may be applied to other embodiments. However, one of ordinary skill in the art will readily recognize that the present disclosure is not intended to be limited to the embodiments illustrated, but is to be accorded the widest scope consistent with the principles and features described herein.
In one embodiment, the present disclosure discloses a method and system for structured simulation of enterprise model using system dynamics modeling. More specifically the method and system describes a model-based translation approach by which elements of enterprise model may be translated to corresponding System Dynamic (SD) elements to enable generation of a system dynamics model corresponding to the enterprise. The enterprise model may be an Enterprise architecture (EA) model or an Intentional modeling (IM) model. In one embodiment, a mapping table may be used for translating the EA and the IM to the SD model, wherein the mapping table is configured to store a master set of enterprise architecture relations and a master set of system dynamics meta-model links, wherein each enterprise architecture relation, of the master set of enterprise architecture relations, is mapped with at least one system dynamics meta-model link of the master set of system dynamics meta-model links, and wherein each enterprise architecture relation is captured from historically analyzed enterprise meta-models. The method and system may further be enabled to conduct ontology based translation for transforming the EA and the IM to the SD model.
In one implementation, the method and system may enable a reference system dynamics meta-model for mapping of core elements in the EA or the IM with the SD elements. Furthermore, the method and system may be enabled to perform detailed mapping of EA elements to equivalent SD elements based on underlying EA relations. In another implementation, the method and system may be enabled to perform detailed mapping of the IM elements to equivalent SD elements based on underlying IM relations. The mapping of the EA or the IM elements with the SD elements is performed using the mapping table. The method and system may further be enabled to obtain feedback from the enterprise simulation to choose optimal elements from the EM and the IM like best alternative path, depending on underlying problem context or goal of the enterprise.
Referring now to
In one implementation, the network 106 may be a wireless network, a wired network or a combination thereof. The network 106 can be implemented as one of the different types of networks, such as intranet, local area network (LAN), wide area network (WAN), the internet, and the like. The network 106 may either be a dedicated network or a shared network. The shared network represents an association of the different types of networks that use a variety of protocols, for example, Hypertext Transfer Protocol (HTTP), Transmission Control Protocol/Internet Protocol (TCP/IP), Wireless Application Protocol (WAP), and the like, to communicate with one another. Further the network 106 may include a variety of network devices, including routers, bridges, servers, computing devices, storage devices, and the like.
Referring now to
The I/O interface 204 may include a variety of software and hardware interfaces, for example, a web interface, a graphical user interface, and the like. The I/O interface 204 may allow the system 102 to interact with the user directly or through the user devices 104. Further, the I/O interface 204 may enable the system 102 to communicate with other computing devices, such as web servers and external data servers (not shown). The I/O interface 204 can facilitate multiple communications within a wide variety of networks and protocol types, including wired networks, for example, LAN, cable, etc., and wireless networks, such as WLAN, cellular, or satellite. The I/O interface 204 may include one or more ports for connecting a number of devices to one another or to another server.
The memory 206 may include any computer-readable medium and computer program product known in the art including, for example, volatile memory, such as static random access memory (SRAM) and dynamic random access memory (DRAM), and/or non-volatile memory, such as read only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes. The memory 206 may include modules 208, and data 210. The data 210, amongst other things, serves as a repository for storing data processed, received, and generated by execution of the modules 208.
The modules 208 include routines, programs, objects, components, data structures, etc., which perform particular tasks or implement particular abstract data types. In one implementation, the modules 208 may include a mapping module 212, a reception module 214, a meta-mode analysis module 216, a comparison module 218, a system dynamics model generation module 220, and other modules 222. The other modules 222 may include programs or coded instructions that supplement applications and functions of the system 102.
The data 210, amongst other things, serves as a database for storing data processed, received, and generated by one or more of the modules 208. The data 210 may also include a repository 232 and other data 234. The other data 234 may include data generated as a result of the execution of one or more modules in the other modules 222. Further, the repository 232 is configured to maintain, a mapping table. In one embodiment, the mapping table is generated by the mapping module 212. The mapping module 212 is configured to maintaining a mapping table in a repository 232. The mapping table is configured to store a master set of enterprise architecture relations and a master set of system dynamics meta-model links, wherein each enterprise architecture relation, of the master set of enterprise architecture relations, is mapped with at least one system dynamics meta-model link of the master set of system dynamics meta-model links. In order to generate the master set of enterprise architecture relations, a set of historically analyzed enterprise meta-models are analyzed to identify the different elements and relationship between the elements in the enterprise meta-models. These relations are then stored in the form of the master set of enterprise architecture relations. Further, the mapping module is configured to identify at least one system dynamics meta-model link corresponding to each enterprise architecture relation.
In one embodiment, once the mapping table is generated, in the next step, an enterprise model corresponding to an enterprise is accepted by the reception module 214. In one embodiment, the enterprise model can be a Enterprise Architecture (EA) model or an Intentional Modeling (IM) model. The reception module 214 is configured to convert the enterprise model into an enterprise meta-model. Further, the meta-mode analysis module 216 is configured to identify a set of enterprise architecture relations from the enterprise meta-model. In one example if the enterprise model is in the form of an Enterprise Architecture (EA) model conforming to ArchiMate, then the EA model and EA meta-model are analyzed to identify different elements in the EA meta-model such as active structure entities (ASEs), behavior entities (BEs), and passive structure entities (PSEs). Further, in case of an Intentional Modeling (IM) model, the IM model is analyzed to determine whether the Intentional model is in conformity with an IM meta-model of the enterprise and accordingly, the IM meta-model is analyzed to identify elements such as actors, tasks, resources, (soft) goals and the like are identified. The enterprise meta-model is further analyzed to identify relations between elements using standard model analysis tools by the meta-mode analysis module 216 and capture the set of set of enterprise architecture relations.
In the next step, the reception module 214 is configured to receive a reference system dynamics meta-model. The reference system dynamics meta-model corresponds to a system dynamics model to be developed for the enterprise. The reference system dynamics meta-model corresponds stores links between different elements in between the system dynamics model to be developed. Once the reference system dynamics meta-model is accepted, in the next step, the comparison module is configured to compare the set of enterprise architecture relations with the master set of enterprise architecture relations based on the reference system dynamics meta-model to identify a sub-set of system dynamics meta-model links corresponding to the enterprise. Based in the identified sub-set of system dynamics meta-model links, the system dynamics model generation module 220 is configured to generate the system dynamics (SD) model. In an embodiment, steps performed for translating the EA models into the SD models are now explained referring to
As illustrated in the
In one embodiment, the translation may further depend upon mapping of elements of EA meta-model with the SD meta-model which may be carried out using the reference meta-model prepared for the SD model, and an ontological representation of the EA model. The metamodel of the SD may further be explained in
Referring to the
The stock may represent a central entity that may change or transform with passage of time as determined by inflow and outflow from the stock. The flow may control the behavior of the stock and the flow is the only way to control or alter magnitude of the stock. The flow may be of three types namely, inflow, outflow, and in-out flow. The inflow is a flow that has target as the stock and source as cloud, wherein the cloud represents beginning or end of the flow, whereas the outflow represents a flow that has the target as the cloud and source as the stock. Similarly the in-out flow has both the source and the target as the stock. In addition to the stocks, the flows may also influence other flows or the converters via flow-flow links or flow-converter links. Furthermore, the converters may influence the variables that control the inflow, the outflow or other converters and in general the dynamic behavior of the EA model. However, the converter may not directly influence the behavior of the stocks; the converter may only do so indirectly via the flow. The converters might be either the variables or constants. Links or connectors may form key model elements that connect or establish linkages among other primitive elements like the stocks, the flows, the converters and the module as shown in the
Additionally, the
Furthermore, there might be four different kinds of links namely a FlowLink, StockLink, ModuleLink and ConverterLink that may be derived from base concept Link. Each link type may further be categorized based on the source and the target model element. For example, the link that connects the converter with another converter may be called a converter-converter link. The link that connects the converter to the flow and vice versa may be called a converter-flow link and a flow-converter link respectively. Similarly, the link that may have its source element as the stock and the target element as either a low or the converter may be called a stock-flow or a stock-converter link. The metamodel of the SD as shown in the
Table 1 below illustrates the mapping of the relation between elements of the EA to the equivalent SD meta-model links, based on the reference SD meta-model links created as shown in the
Table 1 shows variety of the enterprise architecture relations between elements of the EA model and the corresponding link types in the SD metamodel that may be used to represent the SD equivalent of the EA element contexts. Referring to the table 1, entries 1 to 11 capture all possible variations of relations between the BEs, the ASEs, and the PSEs. For example, entry 1 shows that if the BE is assigned to the PSE and furthermore the BE is assigned accesses or uses the PSE, then a ModuleFlow link may be used to represent the context in the mapping.
In an embodiment, table 2 shows a visual representation of the SD links of each relation between elements of the EA model, as shown in the Table 1, along with the semantic interpretation.
The table 2 further illustrates which arguments may become available for expressing behavior in the SD representation resulting from different EA element relations. Together, the tables 1 and 2 represent various ways in which the relation between different EA elements may be translated to equivalent SD links.
Furthermore, functionality may be provided to specify which elements in the EA model need to be considered for translation to the SD model and which should not be, by a first set of tags in the ontological representation. Therefore, this first set of tags restricts the scope of the EA model. Further a second set of tags may be used to specify which equation or the function needs to be made available to the translator so that the equation or the function may be included at a specific SD element. Therefore, the second set of tags enriches the functionality of the SD model. The tags may essentially be object properties and the data properties of the elements in the ontological representation.
In an embodiment, the translation of an Intentional Model (IM) to the SD model may be explained referring tables 3 and 4. Further, an intentional meta-model of the IM may distinguish between elements internal to an actor and external to the actor. The relations in the IM namely, means-end (MELink), task decomposition (TDLink), contribution (CTLink), and strategic dependency (SDLink) relations, as reified relations in the ontology representation may be explained through the table 3. For an example, a contribution link (CTLink) may indicate not only which element contributes (hasCTSource) to a soft goal but also what that contribution is (ICTValue) as shown in
While other aspects of the present subject matter, the system and method for the analysis of enterprise using model-based approach may be implemented in any number of different computing systems, environments, and/or configurations, the embodiments may be described in the context of the following exemplary system.
According to the exemplary embodiment, a merger and acquisition (M&A) of two wealth management WM1 and WM2 banks is considered. Presuming that the M&A has already taken place, the merged entity (WM3), an outcome of the M&A of the WM1 and WM2, ponders over how to rationalize products and services portfolio that now contains many similar products as a result of the M&A. The mapping table as represented in the Tables 1 and 2 are used to obtain the corresponding SD model over which simulation may be run. The new product mix arising out of the M&A, WM1 products and WM2 products, may need to be optimized for better sales opportunities i.e. revenue growth and better profitability such as the M&A goal of tripling profit margins over a period of 5 years.
Now referring to
For a given set of products within the product line, value of the CM of a particular product may be used to compare with other competitive products within same market segment to take decisions such as whether to continue with the same product because of higher CM, or enhance the product to reduce the variable costs associated with the product, and/or increase price because of better demand, or decommission the product altogether because of negative or relatively less CM. In order to simulate the future market conditions/scenarios with respect to products mix rationalization context, it may be essential to consider demand from wealth management client perspective. Two kinds of variable costs, which are of importance, were considered for the simulation in the present exemplary embodiment; namely sales cost and IT or Operations cost. The Chief Information Officer's (CIO) or Chief Operation Officer's (COO) inputs may be considered to incorporate on-ground inputs on the IT or Operations cost component of the variable cost. Similarly, the inputs of BU Heads may also be considered for the revenue/price/demand i.e. sales potential per month in terms of number of units sold to number of customers, components along with the sales cost component. Based on the above, set of enterprise architecture relations present in the EA meta-model are identified. This set of enterprise architecture relations is compared with the master set of enterprise architecture relations in order to identify the sub-set of system dynamics meta-model links corresponding to the enterprise. Further, the SD model may be prepared based on the sub-set of system dynamics meta-model links corresponding to the enterprise as shown in the
Furthermore,
According to the present subject matter the steps in which the method 900 is described is not intended to be construed as a limitation, and any number of the described method blocks can be combined in any order to implement the method 900 or alternate methods. Additionally, individual blocks may be deleted from the method 900 without departing from the spirit and scope of the disclosure described herein. Furthermore, the method can be implemented in any suitable hardware, software, firmware, or combination thereof. However, for ease of explanation, in the embodiments described below, the method 900 may be considered to be implemented in the above described in the system 102.
At block 902, an Enterprise Architecture (EA) model of an enterprise may be received in the form of Archi in .csv format by the reception module 214. After receiving the EA model, the .csv files are converted into .xlsx file format by the for easy integration with .owl based tool editors like Protéǵe®. In one embodiment the ontological representation of the IM model corresponding to the enterprise may be imported. The ArchiMate® and the i*(Intentional) meta-model in form of ontology of the IM is imported in .owl format using tools like the Protégé editor, Jena OWL® ontology API, Pellet Reasoner API, and SPARQL query language for further processing by the reception module 214.
At block 904, a reference system dynamics meta-model is received by the reception module 214. The reference system dynamics meta-model and the ontological representation of the EA model or IM model may then be imported in .owl format.
At block 906, a set of enterprise architecture relations is identified from the EA meta-model or the IM meta-model.
At block 908, using the mapping table generated by the mapping module 212, the comparison module 218 may implement appropriate search strategy to convert the set of enterprise architecture relations to corresponding sub-set of SD links and thereafter the sub-set of SD links may used to generate the SD model. The SD model may be translated into .owl format by the system dynamics model generation module 220. For easy integration with other SD tools like iThink®, Simantics®, the translated SD models in .owl file format may be converted to .xml format by the system dynamics model generation module 220.
At block 910, simulation of the SD model generated by the system dynamics model generation module 220 may be executed over a simulation tool.
At block 912, feedback from the end user may be obtained over the simulation of the SD to choose optimal elements from the EA or the IM elements such as best alternative path, depending on underlying problem context/goal of the enterprise.
Although implementations for method(s) and system(s) for structured simulation of enterprise data have been described in language specific to structural features and/or methods, it is to be understood that the implementations and/or embodiments are not necessarily limited to the specific features or methods described. Rather, the specific features and methods are disclosed as examples of implementations for the structured simulation of the enterprise data.
Exemplary embodiments discussed above may provide certain advantages. Though not required to practice aspects of the disclosure, these advantages may include those provided by the following features.
Some embodiments enable a system and a method allows mapping that uses existing EA models and Intentional models (IM) to generate corresponding SD models, thus one need not create the elements of the SD model from scratch.
Some embodiments enable a system and a method that allows comprehensive SD metamodel that may be used for translating other or newer enterprise modeling concepts to the SD that may provide execution semantics.
Number | Date | Country | Kind |
---|---|---|---|
2731/MUM/2014 | Aug 2014 | IN | national |