DESC:FORM 2
THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENT RULES, 2003

COMPLETE SPECIFICATION
(See Section 10 and Rule 13)

Title of invention:
SYSTEM AND METHOD FOR ANALYZING AN ENTERPRISE ARCHITECTURE



APPLICANT:
Tata Consultancy Services Limited
A company Incorporated in India under the Companies Act, 1956
Having address:
Nirmal Building, 9th floor,
Nariman point, Mumbai 400021,
Maharashtra, India


The following specification particularly describes the invention and the manner in which it is to be performed.

CROSS REFERENCE TO RELATED APPLICATIONS
[001] The present application claims priority to an Indian Provisional Patent Application No.1269/MUM/2014, filed on May 11, 2014, the entirety of which is hereby incorporated by reference.

TECHNICAL FIELD
[002] The present disclosure in general relates to a field of modelling an enterprise architecture. More particularly, the present disclosure relates to a system and a method for analyzing an enterprise architecture.

BACKGROUND
[003] Generally, enterprises have to respond to changes in business requirements due to multiple change drivers,such as evolving market conditions, technology obsolescence and advance, regulatory compliances, competitive pressures, and so on. Formulating strategies to face such imminent changes may be one of vital activities for the enterprises to carry out. Typically, the enterprises rely on human experts for deciding strategies to address the changes. In one example, the strategies are decided by the human experts based on documents with visual/textual notation. The strategies are neither machine-processable nor programmatically analyzable, and therefore lack capturing a holistic view of relevant aspects of the enterprises.
[004] With time, Enterprise Architecture (EA) based modelling approach has been used for strategic decisions to overcome challenges associated with the changes in the enterprise. The EA based modelling approach tends to focus more on strategy making instead ofstrategy operationalization. Other modelling approaches have also been used that focuses on the strategy operationalization from a perspective of either business or Information Technology (IT). The aforementioned approaches are cost intensive, time intensive, and are cumbersome.
[005] Further, there have been attempts made to analyze the enterprise architecture. However, the analysis lacked practical aspect of considering all factors in the enterprise. Typically, alternative strategies are developed and strategy decisions are made by choosing an optimum alternative. If any of the alternatives is found to be optimum in “what-if” analysis, an overall structure of the EA remains constant with addition/modification of intentional elements based on the analysis. Further, sub-analyses are carried out manually to generate more alternatives.

SUMMARY
[006] This summary is provided to introduce concepts related to systems and methods for analyzing an enterprise architecture and the concepts are further described below in the detailed description. This summary is not intended to identify essential features of the claimed subject matter nor is it intended for use in determining or limiting the scope of the claimed subject matter.
[007] In one implementation, a method for analyzing an enterprise architecture is disclosed. The method comprises receiving, by a processor, an Enterprise Architecture (EA) model and an Intention and Motivation (IM) model of an enterprise. The EA model comprises units performing at least one task to achieve at least one goal of the enterprise. The IM model indicates the at least one goal of the enterprise. The method further comprises integrating, by the processor, the EA model and the IM model to obtain one or more expected IM model alternatives. Each IM model alternative indicates an ability of the unit to perform the at least one task. The EA model and the IM model are integrated by mapping elements of the EA model and the IM model using an ontology technique. The method further comprises evaluating, by the processor, the IM model alternatives to obtain routines of the units performing at least one task. The method further comprises performing, by the processor, an aggregate analysis for the IM model alternatives based on the routines of the units in the enterprise.
[008] In one implementation, a system for analyzing an enterprise architecture is disclosed. The system comprises a memory and a processor coupled to the memory. The processor executes program instructions stored in the memory to receive an Enterprise Architecture (EA) model and an Intention and Motivation (IM) model of an enterprise. The EA model comprises units performing at least one task to achieve at least one goal of the enterprise. The IM model indicates at least one goal of the enterprise. The processor further executes the program instructions stored in the memory to integrate the EA model and the IM model to obtain one or more expected IM model alternatives. Each IM model alternative indicates an ability of the unit to perform at least one task. The EA model and the IM model are integrated by mapping elements of the EA model and the IM model using an ontology technique. The processor further executes the program instructions stored in the memory to evaluate the IM model alternatives to obtain routines of the units performing the at least one task. The processor further executes the program instructions stored in the memory to perform an aggregate analysis for the IM model alternatives based on the routines of the units in the enterprise.
[009] In one implementation, a non-transitory computer readable medium embodying a program executable in a computing device for analyzing an enterprise architecture is disclosed. The program comprises a program code for receiving an Enterprise Architecture (EA) model and an Intention and Motivation (IM) model of an enterprise. The EA model comprises units performing at least one Task to achieve at least one goal of the enterprise. The IM model indicates the at least one goal of the enterprise. The program further comprises a program code for integrating the EA model and the IM model to obtain one or more expected IM model alternatives. Each IM model alternative indicates an ability of the unit to perform at least one task. The EA model and the IM model are integrated by mapping elements of the EA model and the IM model using an ontology technique. The program further comprises a program code for evaluating the IM model alternatives to obtain routines of the units performing the at least one task. The program further comprises a program code for performing an aggregate analysis for the IM model alternatives based on the routines of the units in the enterprise.

BRIEF DESCRIPTION OF DRAWINGS
[010] 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/similar features and components.
[011] FIG. 1 illustrates a network implementation of a system for analyzing an enterprise architecture, in accordance with an embodiment of the present disclosure.
[012] FIG. 2 illustrates the system, in accordance with an embodiment of the present disclosure.
[013] FIG. 3 shows a flowchart for analyzing an enterprise architecture, in accordance with an embodiment of the present disclosure.

DETAILED DESCRIPTION
[014] The present disclosure relates to a system and a method for analyzing an enterprise architecture. At first, an Enterprise Architecture (EA) model and an Intention and Motivation (IM) model of an enterprise may be received. The EA model may comprise units performing at least one task to achieve at least one goal of the enterprise. The IM model may indicate the at least one goal of the enterprise. Upon receiving, the EA model and the IM model may be integrated to obtain one or more expected IM model alternatives. Each IM model Alternative may indicate an ability of the unit to perform at least one task. The EA model and the IM model may be integrated by mapping elements of the EA model and the IM model using an ontology technique. After obtaining, the IM model alternatives may be evaluated to obtain routines of the units performing at least one task. Subsequently, an aggregate analysis for the IM model alternatives may be performed based on the routines of the units in the enterprise.
[015] While aspects of described system and method for analyzing an enterprise architecturemay be implemented in any number of different computing systems, environments, and/or configurations, the embodiments are described in the context of the following exemplary system.
[016] Referring now to FIG. 1, a network implementation 100 of a system 102 for analyzing an enterprise architecture is illustrated, in accordance with an embodiment of the present disclosure. The system 102 may receive an Enterprise Architecture (EA) model and an Intention and Motivation (IM) model of an enterprise. The EA model comprises units performing at least one task to achieve at least one goal of the enterprise. The IM model indicates at least one goal of the enterprise. The system 102 may integrate the EA model and the IM model to obtain one or more expected IM model alternatives. Each IM model alternative indicates an ability of the unit to perform at least one task. The EA model and the IM model are integrated by mapping elements of the EA model and the IM model using an ontology technique. The system 102 may evaluate the IM model alternatives to obtain routines of the units performing at least one task. The system 102 may perform an aggregate analysis for the IM model alternatives based on the routines of the units in the enterprise.
[017] Although the present disclosure is explained by considering that the system 102 is implemented on a server, it may be understood that the system 102 may also be implemented in a variety of computing systems, such as a laptop computer, a desktop computer, a notebook, a workstation, a mainframe computer, a server, a network server, cloud, and the like. It will be understood that the system 102 may be accessed by multiple users through one or more user devices 104-1, 104-2…104-N, collectively referred to as user devices 104 hereinafter, or applications residing on the user devices 104. Examples of the user devices 104 may include, but are not limited to, a portable computer, a personal digital assistant, a handheld device, and a workstation. The user devices 104 are communicatively coupled to the system 102 through a network 106.
[018] 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.
[019] Referring now to FIG. 2, the system 102 is illustrated in accordance with an embodiment of the present disclosure. In one embodiment, the system 102 may include at least one processor 202, an input/output (I/O) interface 204, and a memory 206. The at least one processor 202 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the at least one processor 202 is configured to fetch and execute computer-readable instructions stored in the memory 206.
[020] 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 a 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 may 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.
[021] The memory 206 may include any computer-readable medium 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.
[022] In one implementation, at first, the user may use the client device 104 to access the system 102 via the I/O interface 204. The working of the system 102 may be explained in detail using FIG. 2. The system 102 may be usedfor analyzing an enterprise architecture. In order to analyze the enterprise architecture, the system 102 may receive an Enterprise Architecture (EA) model of an enterprise. In one example, the enterprise may include, but not limited to, an educational institution, data centre, an Information Technology (IT) firm, and so on. The EA model may comprises a plurality of units performing at least one task to achieve at least one goal of the enterprise. In one example, the plurality of units may comprise one of an organizational unit, people, and an infrastructure unit. The people may indicate personnel available in the enterprise. The organizational unit may indicate essential business functions in the enterprise that are divided to maximize efficiency. In other words, the people in the enterprise may be divided to create separate departments, such as for marketing, sales, accounting, information technology, and so on. In one example, the people may be divided or classified in a hierarchy such as a Manager, an Assistant Manager, an executive, and so on. In another example, the people may be divided based on a project team, groups, and departments. The infrastructure unit may indicate resources that are available in the enterprise. The resources may include, but not limited to, computers, servers, data centres, and so on. The resources may be associated with policies and strategies pre-defined for the enterprise.
[023] The system 102 may receive data corresponding to each unit of the plurality of units based on a structure of the enterprise. In one example, the structure of the enterprise may include multiple departments with limited people in each department. In another example, the structure of the enterprise may include manufacturing unit, management, human resource department, and so on.
[024] As presented above, a unit in the plurality of units may perform at least one task to achieve at least one goal of the enterprise. In one example, the at least one task may comprise performing a function by the unit, e.g., an actor. In one example, the actor may include a Chief Financial Officer (CFO), a Research Head (RH), and a Chief Information Officer (CIO), and Business Unit Heads (BU Heads), a manager, an assistant, and so on.
[025] Further, the system 102 may receive an Intention and Motivation (IM) model for the enterprise. The IM model may indicatefactors to be considered to achieve at least one goal of the enterprise. In other words, the IM model may be received for the enterprise or for each unit in the enterprise. In one example, the goal for the enterprise may include increase revenue of the enterprise by 20 percent. In another example, the goal for the enterprise may include maximize productivity of the actors or the units in the enterprise. In order to achieve the goals of the units or the enterprise, there may be internal drivers and/or external drivers. The internal drivers may include factors such as internal policies. The external drivers may include statutory policies. It is to be understood that the internal and external drivers may include other factors that are not disclosed and may be obvious to a person skilled in context of the enterprise.
[026] In order to explain goals of the units or the actors in the enterprise, few examples may be used. For example, a goal for the manager may include completing a project on time with available people. Similarly, a goal for the enterprise may include completing the project without additional cost within a specified time and with the people available. In order to explain the unit performing a task, an example may be used. Consider the hierarchy of the organizational unit as manager, assistant manager and executive. Consider, the manager allots a project to two assistant managers and each assistant manager has ten executives to work on the project. The manager may divide the people in the enterprise. For example, the manager may divide the people between project teams, groups, or departments based on a task. In one example, the executive may be assigned a task to write a software code for an application. Similarly, the assistant manager may be assigned a task to review the software code. Similarly, each unit in the plurality of units performs at least one task to achieve the goals of units and the enterprise.
[027] The IM model may further comprise soft goals, and dependency participants at every stage of the IM model. The soft goals may indicate smaller goals, e.g., margin be improved, new product mix be sold better, IT cost of operations be optimized and so on.The contribution of various alternatives to the corresponding soft goals may be captured in terms of a scale from break (most negative) to make (most positive). The soft goals are qualitative aspects of desired solution i.e., the expected EA. The models with the activities that various actor are performing may be created in return.
[028] The IM model may comprise the strategic dependency (SD) and the strategic rationale (SR) models. The system 102 may use the SD model and SR model to capture the strategic dependencies between the actors or the units. Further, the SD model and SR model may be captured to model intentions of the actor in performing the appointed tasks respectively. In context of the enterprise, the SD model may describe the enterprise in terms of the strategic dependencies that the actors in the enterprise have on each other in accomplishing the actor’s tasks. The SR model may describe reasoning that the actors employ to determine merit in organizing the tasks.
[029] After receiving the intentions of the units in the IM model, the EA model may be integrated with the IM model. Specifically, the EA model and the IM model may be integrated to obtain one or more IM model alternatives. Each IM model alternative may indicate an ability of the unit to perform the at least one task. The EA model and the IM model may be integrated by mapping elements of the EA model and the IM model using an ontology technique. Mapping of the elements in the EA model and the IM model is explained using an example. In one example, the EA model may be mapped with IM model using ArchiMate®. As known, ArchiMate® is an open and independent modelling language for enterprise architecture. The EA model comprising the business, application, and infrastructure may be mapped with the IM model. Mapping of the EA model and the IM model enables to specify that enterprise active structure entities use or create passive structure entities while performing behaviour (entities) as means to end that are goal(s) or soft goal(s).
[030] The ArchiMate® may define Active Structure Elements (ASEs) and Passive Structure Elements (PSEs) as entities that are capable of performing behaviour. The ASEs may be assigned to the behaviour element indicating units or measure of an activity. The PSEs may be objects upon which the behaviour is performed. The relationship may be represented using three layers, such as business, application, and technology layers. The service may be an externally visible behaviour of the model, which is made accessible through the interfaces, and constitutes the external view on the active structural element. The business layer may offer the products and the services to external customers. The products and the services may be realized in the enterprise by the business processes performed by the actor or the unit. The resources may be used or created by the actor while performing the tasks. The actors may depend on each other to perform the task and/or to use or create the resource to achieve the goal or the soft goal.
[031] The ontology technique may be used to map the EA model and the IM model. The ontological representation of the IM model may lead the enterprise to consider the goal. To achieve the goal, the enterprise may have to come up with a course of action. The internal and external driver may influence the elements in the IM model. For example, a stakeholder may be interested in assessment of the internal driver and the assessment may lead to formulation of the goal.
[032] The ontological representation may be used to conduct change impact and landscape mapping analysis. In order to conduct the change impact, the EA ontology may be mapped with IM concepts. The ArchiMate® enables obtaining EA element type and name of both source and target nodes along with relation and documentation. After obtaining, the EA element type may be read into ontology model by constructing a dictionary, leveraging the type information of an instance and then constructing the data in terms of relations. In other words, the IM model concepts may be captured under IntentionalEntity class. Specifically, the IM elements may be captured with the EA model, comprising elements internal to the actor (comprising strategic rationalemodel) and external to the actors (strategic dependency model). Based on the ontological representation, the relations in the IM modelare represented as means-end, task decomposition, contribution,and strategic dependency relations, benefit from being represented as verified relations. For example, a contribution link may indicate an element that contributes to a soft goal and the contribution made. The contribution link in the IM model may be captured as an ontological class CTLink, instead of representing it as a relation. The source and target of contributions may be captured via hasCTSourceand hasCTTarget object properties and the contribution may be captured via hasCTValue.Similarly, the Means-ends links (MELink), task decomposition links (TDLink) and strategic dependency links (SDLink) may be represented.
[033] After integrating the EA model and the IM model, based on the context, one or more IM alternatives may be obtained. After obtaining, the one or more IM alternatives may be evaluated to obtain routines of the units or the actors. In order to explain obtaining routines of the units, an example may be considered.
[034] Consider two large wealth management banks, WM1 and WM2, with multi-billion dollars involved in a Merger and Acquisition (M&A) activity. Consider both WM1 and WM2 are in retail brokerage business with 10000 Financial Advisors across 700 locations in a Country X. The objective of the M&A is to form a WM3 with the expressed strategic goal of triplingWM1’s revenue and gross margin in 5 years with a strategic growth viewpoint. Consider the context or the problems identified for forming WM3 are products and services rationalization, branch consolidation, workforce integration, application rationalization, data migration, and capacity enhancement. In order to explain obtaining and operationalizingan optimal enterprise architecture, consider the context of products and services rationalization of over a 1500 entities and more than 2500relations.
[035] At first, the EA model for the products and services rationalization context may be received. The context of the product and services problem may be traced back to the key external driver which may lead WM1 toengage into M&A with WM2. For the purpose of the context, market conditionmay be interpreted by WM1 as ripe for M&A for extending WM1’s productportfolio with WM2’s. The market conditions may be captured for the product and services. Specifically, the external and internal drivers of the market conditions may be captured. Furthermore, product portfolios of WM1 and WM2, which aresimilar,may be considered.
[036] After capturing the factors based on the context, an assessment of the InternalMDriver instance for the similar products may be carried out such that products and services of the merged entity may be rationalized. The strategic goal of revenue increment i.e., IHardGoal instance Revenue to be Increasedwith Doubled Product Mix should be satisfied when rationalizing the product mix thatshares many products of WM1 and WM2 with common features. A hard goal may indicate a goal that the enterprise aims to achieve in the long time. The Chief Financial Officer (CFO) may be the stakeholder with responsibility of overseeing the activities that will be constructed via means-end analysis of the hard goal. The CFO may have two options, prefer the product mix of WM1 which is the majority stakeholder of the M&A or rationalize the product mix. For the first choice, IntentionalITask instance Prefer the Majority Stake, task decomposition may suggest that when preferring the majority stake, margin should be improved still captured in ISoftGoal instance Margin be improved. Means-ends decomposition of IHardGoal instanceMajority Stake be Preferred may suggest that either all of WM1 products are retainedwhile WM2’s are decommissioned or WM1 products are retained and enhanced with additional features from similar products of WM2.
[037] For IntentionalITask instance Product Mix to be rationalized, similar task and means ends decomposition may be carried out. When product mix rationalization choices are coined, dependencies of the CFO on others such as, Research Head (RH), and Chief Information Officer (CIO), and Business Unit Heads (BU Heads) may become apparent. Either specialized product mixmodels may be used for product rationalization for which the CFO may depend on the RH, or the rationalization ranking could be based purely on projected IT and sales costs of integration and operationalization of the new product mix, for which the CFO could getthe cost inputs from the CIO and the BU Heads respectively. A third alternative may include cost inputs of the CIO and the CFO that may be integrated into product mix models by considering both customer and product profitability.
[038] Upon completion of the IM modelling activity for a given problem or a context, IntegrationITask instances may be assigned to satisfaction levels. Assigning satisfaction values to IntegrationITask instances may be similar to making selection in means to all the ends in all actors or units that are part of the IM model. Entry points for evaluation of IM model alternatives may become root goals in each actor of the IM model of the problem. The ontological representation of the EA model and IM model may be stored as graphs. Further, A SPARQL query may be provided to obtain immediate tasks that are means to a specific IHardGoal instance. Queries that are similar for other ILink subclasses enable accessing children nodes of each intentional element. Using a label of the children node, a Parent’s label may be computed.
[039] After evaluating the IM model alternatives, routines of the actor may be obtained. A routine may indicate a collection of intentional elements used by an actor to achieve a goal. In one example, the routine may be a graph comprising a root goal of the actor as the root in the graph. In the graph, vertices ends at one or more IntegrationITask instances may be computed. A routine may be recursively built by starting at the root goal(s) of an actor and traversing till IntegrationITask instances are reached. From the IntegrationITask instances, flow of control may go back to parent nodes which are instances of IntentionalITask type connected via reified TDLinkinstances. This is because; task decomposition links have AND semantics, i.e., in order to do a task, and all of its decomposed elements are required.
[040] Achieving the tasks may lead to achieving the root goals. In order to achieve root goals, the tasks corresponding to the goals may be operationalized. For operationalizing, all behaviour elements in the EA model are considered. Each IntegrationITask instance may be realized/considered by one or more behaviour elements. Further, the behaviour elements and Integration Task(s) may be mapped using ArchiMate. The mapping captures operationalization of instances of IntegrationITask using any behaviour elements such as instances of BusinessProcess, BusinessService, BusinessFunction, ApplicationFunction, and ApplicationService.
[041] The behaviour elements may be used on the application layer. In order to model the operationalization elements for IntegrationITask instances, the behaviour elements may be implemented as applications such as for instance, IntegrationITask instances. For the behaviour elements existing, new EA elements may be added. While modelling the operationalization elements of all IntegrationITask instances, it may be necessary to keep the new EA elements added for specific IntegrationITask instances. In order to add the new EA elements to the existing elements, the new EA elements may be tagged with IntegrationITask instance name. Further, the new EA elements may be represented using an object property called as OperationalizationElementOf in the ontological representation. Similarly, all the elements that are participating in operationalizing an IntegrationITask instance may be tagged with the name of that instance. By tagging, the EA elements that were added newly may be identified. Further, new EA elements constitute the operationalization of aspecific IntegrationITask instance is made explicit. The specific set of elements comprising an operationalization model of a specific strategy may be computed in at least two ways. Expected EA model capturing all possible IM model alternatives may consist of the IM model, the operationalization model of all alternatives and the EA model. First, the operationalization model may be computed by ontologically subtracting EA model and IM model from IM alternatives model may give operationalization model of all IM alternatives. Second, creating an extended Archi viewpoint comprising operationalization models of all IM alternatives and export the extended Archi viewpoint as a single model to import into ontological representation. Using the two ways, the set of operationalization elements of IntegrationITask instances in a specific strategy may be separated using a SPARQL query. Execution of the SPARQL query, the corresponding operational EA elements may be retrieved.
[042] After evaluating the IM alternatives, operationalization of selected IM alternative may be computed to show their application. In order to compute the operationalization, an aggregate analysis may be performed for the IM model alternatives. Specifically, the aggregate analysis may be performed based on the routines of the units in the enterprise. The aggregate analysis may comprise at least one of an ability analysis, a workability analysis, and a viability analysis.
[043] In intentional modelling, the ability of the actor may imply a notion of process which does not require full reduction to minor details of primitive actions. In other words, the actor having the ability to perform a task if the actor has a routine. Further, if there is a dependency link between one or more elements of the actor’s routine on other actor’s intentional elements, then that actor should havea routine for the elements. In other words, computation of the ability analysis results in computation of the actor routine depending on or be depended on the other actors routines. All the routines that are relevant may need to be computed to indicate the actor’s ability over an intentional element.
[044] For performing the aggregate analysis, questions may be asked regarding the ability of the actor corresponding to an aspect of solution of a problem-context. For the example of WM1 and WM2, a question may be asked as to whether CFO of the merged entity has the ability to increase revenue by managing product mix that now contains similar products that might have to be rationalized. The question may correspond to CFO’s root goal in the IM model of products and services rationalization. For the strategy considered, a set of routines of the CFO, the CIO, BU head and RH may provide solutions to the question.
[045] In the workability analysis, a routine is workable if all the elements in the routine are workable. Further, an element in a routine is workable if the elements in all of its subroutine are workable. Workability of the routine stops when the actor boundary ends where a dependency or at an element which the actor considers to be primitively workable. The element at which the actor is confident at execution time, the actor is able to carry out the reasoning and actions requiredto achieve a result. At an actor boundary, an open element i.e., dependent is workable if there is another actor offering the element. A committed element is workable if there is anotheractor committed to producing the element as dependent to the first actor.
[046] The workability analysis may be performed by asking questions or by raising workability as an issue. From operationalization perspective, the workability of a routine of the actor may be asked when the corresponding IntegrationITask instance is part of the operational strategy. A routine of an actor is workable if all primitively workable elements of that routine recognized by IntegrationITask instances are realized in the operationalization model. For example, the question may include- whether merged entity’s CFO’s goal of increasing revenue by managing product mix that now contains similar products is workable. For the question, an answer may be the strategy that is obtained by operationalization. In the workability analysis comprising raising workability as an issue, an element is workable if the actor believes at process design time that the actor can successfully carry it out or achieve it at runtime. In other words, raising workability of the element may imply that the actor believes that an aspect of element may not work as intended. For example, if the CIO doubts the workability of BusinessProcess instance Enhance Product Applications, then the businessprocess should be further decomposed, and the CIO needs to be convinced of decomposed elements’ workability which in turn results in the business process being workable.
[047] In the viability analysis, a routine is viable if all of its softgoals are satisfied. When the softgoals pertinent to a routine are not satisfied, then the routine is not viable. The viability analysis is performed to take the right actions toimprove quality requirements of each routine and the strategy. As explained in the intentional modelling, the tasks may be decomposed such that the softgoals are satisfied. After defining the softgoals, the viability analysis may be performed by linking operations identified with the softgoals. For example, consider that the CIO believes that although IntegrationITask instance Enhance Product Application helps the ISoftGoalinstance of IT Cost of Operations be Optimized, there iseffort involved in enhancing product applications with features before they are used for merged entity operations and that viability of enhancing product applications needs to be raised as an issue. ISoftGoal instance of IT Cost of operations be optimized needs to be decomposed to separate identified concerns. Identification of the concerns may lead to softgoals such as properand faster product application enhancement, leading to quicker roll out, which helps IT cost of operations. Correspondingly, IntegrationITask instance Enhance Product Application needs to be decomposed into tasks that capture product application enhancement effort and task which signifies that enhanced applications are being used for operations. After decomposing, trade-off contribution links may be modelled and satisfaction of softgoals may be recomputed.
[048] From operationalization perspective, the decomposition of the operational EA elements may be carried out in workability analysis to reflect quality requirements of the viability analysis. Further, high-level non-functional requirements on business processes may be captured using operating condition and control case concepts. The operating condition serves as a classification or grouping of constraints. The operating condition signifies an applicable constraint and is an associated artifact to a business activity.
[049] Referring now to FIG. 3, a method 300 foranalyzing an enterprise architecture is shown, in accordance with an embodiment of the present disclosure. The method 300 may be described in the general context of computer executable instructions. Generally, computer executable instructions can include routines, programs, objects, components, data structures, procedures, modules, functions, etc., that perform particular functions or implement particular abstract data types. The method 300 may also be practiced in a distributed computing environment where functions are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, computer executable instructions may be located in both local and remote computer storage media, including memory storage devices.
[050] The order in which the method 300 is described and 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 300 or alternate methods. Additionally, individual blocks may be deleted from the method 300 without departing from the spirit and scope of the disclosure described herein. Furthermore, the method may be implemented in any suitable hardware, software, firmware, or combination thereof. However, for ease of explanation, in the embodiments described below, the method 300 may be implemented in the above-described system 102.
[051] At step/block 302, an Enterprise Architecture (EA) model and an Intention and Motivation (IM) model of an enterprise may be received. The EA model may comprises units performing at least one task to achieve at least one goal of the enterprise. The IM model indicates at least one goal of the enterprise.
[052] At step/block 304, the EA model and the IM model may be integrated to obtain one or more IM model alternatives. Each IM model alternative indicates an ability of the unit to perform the at least one task. The EA model and the IM model may be integrated by mapping elements of the EA model and the IM model using an ontology technique.
[053] At step/block306, the IM model alternatives may be evaluated to obtain routines of the units performing at least one task.
[054] At step/block 308, an aggregate analysis for the IM model alternatives may be performed based on the routines of the units in the enterprise.
[055] Although implementations of system and method for analyzing an enterprise architecture have been described in language specific to structural features and/or methods, it is to be understood that the appended claims are not necessarily limited to the specific features or methods described. Rather, the specific features and methods are disclosed as examples of implementations for analyzing an enterprise architecture.
,CLAIMS:WE CLAIM:

1. A method for analyzing an enterprise architecture, the method comprising:
receiving, by a processor, an Enterprise Architecture (EA) model and an Intention and Motivation (IM) model of an enterprise, wherein the EA model comprises units performing at least one task to achieve at least one goal of the enterprise, and wherein the IM model indicates the at least one goal of the enterprise;
integrating, by the processor, the EA model and the IM model to obtain one or more expected IM model alternatives, wherein each IM model alternative indicates an ability of the unit to perform the at least one task, and wherein the EA model and the IM model are integrated by mapping elements of the EA model and the IM model using an ontology technique;
evaluating, by the processor, the IM model alternatives to obtain routines of the units performing at least one task; and
performing, by the processor, an aggregate analysis for the IM model alternatives based on the routines of the units in the enterprise.
2. The method of claim 1, wherein the units comprises one of an application, an infrastructure layer, and people.
3. The method of claim 1, further comprising capturing Strategic Dependencies (SD) among the units to model intentions of the units performing at least one task.
4. The method of claim 1, wherein the aggregate analysis comprises at least one of: an ability analysis, a workability analysis, and a viability analysis.
5. A system for analyzing an enterprise architecture, the system comprising:
a memory; and
a processor coupled to the memory, wherein the processor executes program instructions stored in the memory, to:
receive an Enterprise Architecture (EA) model and an Intention and Motivation (IM) model of an enterprise, wherein the EA model comprises units performing at least one task to achieve at least one goal of the enterprise, and wherein the IM model indicates at least one goal of the enterprise;
integrate the EA model and the IM model to obtain one or more expected IM model alternatives, wherein each IM model alternative indicates an ability of the unit to perform the at least one task, and wherein the EA model and the IM model are integrated by mapping elements of the EA model and the IM model using an ontology technique;
evaluate the IM model alternatives to obtain routines of the units performing at least one task; and
perform an aggregate analysis for the IM model alternatives based on the routines of the units in the enterprise.
6. The system of claim 5, wherein the units comprises one of an application, an infrastructure layer, and people.
7. The system of claim 5, further the processor further executes the program instructions to capture Strategic Dependencies (SD) among the units to model intentions of the units performing at least one task.
8. The system of claim 5, wherein the aggregate analysis comprises at least one of: an ability analysis, a workability analysis, and aviability analysis.
9. A non-transitory computer readable medium embodying a program executable in a computing device for analyzing an enterprise architecture, the program comprising:
a program code for receiving an Enterprise Architecture (EA) model and an Intention and Motivation (IM) model of an enterprise, wherein the EA model comprises units performing at least one task to achieve at least one goal of the enterprise, and wherein the IM model indicates at least one goal of the enterprise;
a program code for integrating the EA model and the IM model to obtain one or more expected IM model alternatives, wherein each IM model alternative indicates an ability of the unit to perform at least one task, and wherein the EA model and the IM model are integrated by mapping elements of the EA model and the IM model using an ontology technique;
a program code for evaluating the IM model alternatives to obtain routines of the units performing at least one task; and
a program code for performing an aggregate analysis for the IM model alternatives based on the routines of the units in the enterprise.