Generally, the invention relates to application development. More specifically, the invention relates to method and system of on-demand application development.
Background
[002] The application architecture and technologies used in an application may have some interconnections. Also, it may have connection with the business requirement. As the business priority changes, the behaviour of the application is also expected to change. Further, at different times and instances, one or more of scalability, performance, security, stability, or availability may be of priority. The success of any business would be to deliver the application based on the current priority.
[003] The architecture and technologies selection of the application is also driven by these priorities. However, due to various requirements of demand, and various architecture/technology combinations available, since the selection is of static nature currently, optimal technology and architecture may not be selected. This may lead to a compromise on the businesses front.
SUMMARY OF INVENTION
[004] In one embodiment, a method of on-demand application development is disclosed. The method may include identifying one or more business logics from a data repository based on functionalities associated with an application to be developed and one or more business contexts associated with the application. The method may further include performing a multi-dimensional analysis on the one or more business logics and the one or more business contexts. The multi-dimensional analysis may include a business logic level analysis, a business context level analysis, an
Docket No: IIP-HCL-P0142
-3-
architecture and technology level analysis, and an application-level analysis. The method may further include identifying a technology from a set of technologies and an architecture from a set of architectures for each of the one or more business logics based on the multi-dimensional analysis. The method may further include identifying at least one template from a code template repository, based on the technology and the architecture identified for each of the one or more business logics. The method may further include generating a code based on the at least one template and based on the technology and the architecture identified for each of the one or more business logics. The method may further include deploying the code based on the one or more business contexts on the technology and the architecture identified for each of the one or more business logics.
[005] In another embodiment, a system of on-demand application development is disclosed. The system may include an application development device comprising a processor and a memory communicatively coupled to the processor. The memory may store processor-executable instructions, which, on execution, may causes the processor to identify one or more business logics from a data repository based on functionalities associated with an application to be developed and one or more business contexts associated with the application. The processor-executable instructions, on execution, may further cause the processor to perform a multi-dimensional analysis on the one or more business logics and the one or more business contexts. The multi-dimensional analysis may include a business logic level analysis, a business context level analysis, an architecture and technology level analysis, and an application-level analysis. The processor-executable instructions, on execution, may further cause the processor to identify a technology from a set of technologies and an architecture from a set of architectures for each of the one or more business logics based on the multi-dimensional analysis. The processor-executable instructions, on execution, may further cause the processor to identify at least one template from a code template repository, based on the technology and the architecture identified for each of the one or more business logics. The processor-executable instructions, on execution, may further cause the processor to generate a code based on the at least one template and based on the technology and the architecture identified for each of the one or more business logics. The processor-executable instructions, on execution, may further cause the processor to deploy the
Docket No: IIP-HCL-P0142
-4-
code based on the one or more business contexts on the technology and the architecture identified for each of the one or more business logics.
[006] It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed.
BRIEF DESCRIPTION OF THE DRAWINGS
[007] The present application can be best understood by reference to the following description taken in conjunction with the accompanying drawing figures, in which like parts may be referred to by like numerals.
[008] FIG. 1 is a block diagram illustrating a system for on-demand application development, in accordance with an embodiment.
[009] FIG. 2 is a block diagram illustrating various modules within an application development device configured to develop an on-demand application, in accordance with an embodiment.
[010] FIG. 3 illustrates a flowchart of a method for on-demand application development, in accordance with an embodiment.
[011] FIG. 4 illustrates a flowchart of a method for performing the multi-dimensional analysis on business logics and business contexts, in accordance with an embodiment.
[012] FIG. 5 illustrates a flowchart of a method for identifying a subset of architecture and technology combinations based on fitment value, in accordance with an embodiment.
[013] FIG. 6 illustrates a flowchart of a method for performing an application-level analysis on a subset of architecture and technology combinations, in accordance with an embodiment.
[014] FIG. 7A illustrates implementation of one or more business logics on the identified architecture and technology combination for on-demand application development, in accordance with an embodiment.
[015] FIG. 7B is a functional block diagram for implementation of one or more business logics on the identified architecture and technology for on-demand application development, in accordance with an embodiment.
[016] FIG. 8 is a detailed block diagram of a system for on-demand application development, in accordance with an embodiment.
Docket No: IIP-HCL-P0142
-5-
[017] FIG. 9 is an exemplary table illustrating one or more business logics associated with an application, in accordance with an exemplary embodiment.
[018] FIG. 10 is an exemplary table illustrating architecture affinity of various architectures with one or more business logics, in accordance with an exemplary embodiment.
[019] FIG. 11 is an exemplary table illustrating technology affinity for various technologies with one or more business logics, in accordance with an exemplary embodiment.
[020] FIG. 12 is an exemplary table illustrating impact of non-functional parameters associated with one or more business contexts, in accordance with an exemplary embodiment.
[021] FIG. 13 is an exemplary table illustrating architecture affinity for various architectures with one or more business contexts, in accordance with an exemplary embodiment.
[022] FIG. 14A is an exemplary table illustrating architecture affinity of various architectures for a banking application with respect to the one or more business logics, in accordance with an exemplary embodiment.
[023] FIG. 14B is an exemplary table illustrating architecture affinity of various architectures for an E-commerce application with respect to the one or more business logics, in accordance with an exemplary embodiment.
[024] FIG. 15 is an exemplary table illustrating impacted parameters for the technology affinity with respect to the one or more business contexts, in accordance with an exemplary embodiment.
[025] FIG. 16 is an exemplary table illustrating technology affinity for the one or more business contexts, in accordance with an exemplary embodiment.
[026] FIG. 17 is an exemplary table illustrating technology affinity for the banking application with respect to the one or more business logics, in accordance with an exemplary embodiment.
[027] FIG. 18 is an exemplary table illustrating technology affinity for an e-commerce application with respect to the one or more business logics, in accordance with an exemplary embodiment.
[028] FIG. 19 is an exemplary table illustrating interdependencies between one or more business logics for a banking application, in accordance with an exemplary embodiment.
Docket No: IIP-HCL-P0142
-6-
[029] FIG. 20 is an exemplary table illustrating interdependencies between one or more business logics for e-commerce applications, in accordance with an exemplary embodiment.
[030] FIG. 21 is an exemplary table illustrating priority of one or more business logics with respect to a banking application, in accordance with an exemplary embodiment.
[031] FIG. 22 is an exemplary table illustrating priority of one or more business logics with respect to an e-commerce application, in accordance with an exemplary embodiment.
[032] FIG. 23 is an exemplary table illustrating architecture and technology relationship matrix, in accordance with an exemplary embodiment.
[033] FIG. 24 is an exemplary table illustrating architecture to architecture relationship matrix, in accordance with an exemplary embodiment.
[034] FIG. 25 is an exemplary table illustrating technology to technology relationship matrix, in accordance with an exemplary embodiment.
[035] FIG. 26 is an exemplary table illustrating architecture fitment score of business logic “transaction management” with respect to business context “banking application”, in accordance with an exemplary embodiment.
[036] FIG. 27 is an exemplary table illustrating technology fitment score of business logic “transaction management” with respect to business context “banking application”, in accordance with an exemplary embodiment.
DETAILED DESCRIPTION OF THE DRAWINGS
[037] The following description is presented to enable a person of ordinary skill in the art to make and use the invention and is provided in the context of particular applications and their requirements. Various modifications to the embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the invention. Moreover, in the following description, numerous details are set forth for the purpose of explanation. However, one of ordinary skill in the art will realize that the invention might be practiced without the use of these specific details. In other instances, well-known structures and devices are shown in block diagram form in order not to obscure the description of the invention with unnecessary
Docket No: IIP-HCL-P0142
-7-
detail. Thus, the invention is not intended to be limited to the embodiments shown but is to be accorded the widest scope consistent with the principles and features disclosed herein.
[038] While the invention is described in terms of particular examples and illustrative figures, those of ordinary skill in the art will recognize that the invention is not limited to the examples or figures described. Those skilled in the art will recognize that the operations of the various embodiments may be implemented using hardware, software, firmware, or combinations thereof, as appropriate. For example, some processes can be carried out using processors or other digital circuitry under the control of software, firmware, or hard-wired logic. (The term “logic” herein refers to fixed hardware, programmable logic and/or an appropriate combination thereof, as would be recognized by one skilled in the art to carry out the recited functions.) Software and firmware can be stored on computer-readable storage media. Some other processes can be implemented using analog circuitry, as is well known to one of ordinary skill in the art. Additionally, memory or other storage, as well as communication components, may be employed in embodiments of the invention.
[039] Referring now to FIG. 1, a block diagram of a system 100 for on-demand application development is illustrated, in accordance with an embodiment. The system 100 may include an application development device 102 that may be responsible for developing an on-demand application based on one or more business logics and one or more business contexts. Examples of the application development device 102 may include, but are not limited to, a server, a desktop, a laptop, a notebook, a tablet, a smartphone, a mobile phone, an application server, or the like.
[040] The application development device 102 may include various modules within a memory 106 that enable the application development device 102 to develop the on-demand application. These modules are explained in detail in conjunction with FIG. 2. In order to develop the on-demand application, initially, the application development device 102 may identify one or more business logics from a data repository based on functionalities associated with an application to be developed and one or more business contexts associated with the application.
[041] Once the one or more business logics and the one or more business contexts are identified, the application development device 102 may further perform a multi-dimensional analysis. The multi-dimensional analysis may include a business logic level analysis, a business context level analysis, an architecture and technology
Docket No: IIP-HCL-P0142
-8-
level analysis, and an application-level analysis. Methods of performing multi-dimensional analysis on the one or more business logics and the one or more business contexts has been explained in greater detail in conjunction with FIG. 4 and FIG. 6.
[042] Once the multi-dimensional analysis is performed, the application development device 102 may identify a technology from a set of technologies and an architecture from a set of architectures for each of the one or more business logics. Thereafter, at least one template from a code template repository may be identified, based on the technology and the architecture identified for each of the one or more business logics. Based on the at least one template and based on the technology and the architecture identified, the application development device 102 may generate a code. The application development device 102 may then deploy the code based on the one or more business contexts on the technology and the architecture identified for each of the one or more business logics. The complete process followed by the system 100 is further explained in detail in conjunction with FIG. 2 to FIG. 27.
[043] The application development device 102 may further include a processor 104 and a display 108. The display 108 may include a user interface 110. The end-user may interact with the application development device 102 and vice versa via the user interface 110 accessible via the display 108. By way of an example, the display 108 may be used to display results (i.e., the on-demand developed application) based on actions performed by the application development device 102, to the end-user (i.e., financial entities, banks, e-commerce organization, manufacturing industries, etc.,). It should be noted that, the application development is dynamic in nature and may be changed based on the one or more business logics and the one or more business contexts requirement.
[044] The memory 106 may store instructions that, when executed by the processor 104, may cause the processor 104 to develop the on-demand application. As will be described in greater detail in conjunction with FIG. 2 to FIG. 27, in order to develop the on-demand application, the processor 104 in conjunction with the memory 106 may perform various functions including identifying one or more business logics from a data repository and one or more business contexts associated with the application to be developed, performing a multi-dimensional analysis on the one or more business logics and the one or more business contexts, identifying a technology from a set of technologies and an architecture from a set of architectures for each of the one or more business logics, identifying at least one template from a code template
Docket No: IIP-HCL-P0142
-9-
repository, generating and then deploying a code for each of the one or more business logics.
[045] The memory 106 may also store various data (e.g., the one or more business logics, the one or more business contexts, the functionalities associated with the application to be developed, the set of technologies, the set of architectures, the code templates, etc.) that may be captured, processed, and/or required by the application development device 102. The memory 106 may be a non-volatile memory (e.g., flash memory, Read Only Memory (ROM), Programmable ROM (PROM), Erasable PROM (EPROM), Electrically EPROM (EEPROM) memory, etc.) or a volatile memory (e.g., Dynamic Random-Access Memory (DRAM), Static Random-Access memory (SRAM), etc.).
[046] The system 100 may also include one or more external devices 112. In some embodiments, the application development device 102 may interact with the one or more external devices 112 over a communication network 114 for sending or receiving various data. Examples of the external devices 112 may include, but are not limited to, computer, tablet, smartphone, and laptop. The communication network 114, for example, may be any wired or wireless network and the examples may include, but may be not limited to, the Internet, Wireless Local Area Network (WLAN), Wi-Fi, Long Term Evolution (LTE), Worldwide Interoperability for Microwave Access (WiMAX), and General Packet Radio Service (GPRS).
[047] Referring now to FIG. 2, a block diagram 200 of various modules within the application development device 102 that is configured to develop the on-demand application is illustrated, in accordance with an embodiment. Once the one or more business logics from the data repository (for example, a business logics repository 218a) and the one or more business contexts associated with the application to be developed are identified, the application development device 102 may perform a multi-dimensional analysis on the one or more business logics and the one or more business contexts through a multi-dimensional analysis module 202. The multi-dimensional analysis model 202 may further include a business logic analysis module 204, a business context analysis module 206, an architecture and technology analysis module 208, and an application analysis module 210.
[048] The business logic analysis module 204 may be configured to perform a business logic level analysis. In the business logic level analysis, a first affinity score relative to each of the set of technologies and each of the set of architectures may be
Docket No: IIP-HCL-P0142
-10-
determined for each of the one or more business logics based on a set of predefined business logic parameters. The first affinity score may correspond to ease of deploying a business logic from the one or more business logics in each of the set of technologies and each of the set of architectures. The set of predefined business logic parameters for a business logic from the one or more business logics may include at least one of input dependency of the business logic, usage pattern associated with the business logic, dependent business logics, influenced business logics, architecture affinity, technology affinity, and output generated by the business logic.
[049] Further, the business context analysis module 206 may be configured to perform a business context level analysis. In the business context level analysis, a second affinity score relative to each of the set of technologies and each of the set of architectures may be determined for each of the one or more business contexts based on a set of predefined business context parameters. The second affinity score for a business context from the one or more business contexts may correspond to ease of deploying the one or more business logics in each of the set of technologies and each of the set of architectures in the business context. In an embodiment, the set of predefined business context parameters for a business context from the one or more business contexts may include target audience for the business context, business priority of the business context, architecture affinity of the business context, technology affinity of the business context, constrains associated with the business context, business contexts influenced by the business context, and business contexts dependent on the business context.
[050] The architecture and technology analysis module 208 may be configured to perform an architecture and technology level analysis. In the architecture and technology level analysis, a third affinity score for each of the set of technologies relative to each of the set of architectures is determined.
[051] In some embodiments, based on the first affinity scores, the second affinity scores, and the third affinity scores, the multi-dimensional analysis module 202 may further identify a set of architecture and technology combinations for the one or more business logics and the one or more business contexts. Further, the multi-dimensional analysis module 202 may determine a fitment value for each of the set of architecture and technology combinations. The multi-dimensional analysis module 202 may further compare the fitment value determined for each of set of architecture and technology combinations with a predefined threshold. Once the fitment value is
Docket No: IIP-HCL-P0142
-11-
compared, the multi-dimensional analysis module 202 may identify a subset of architecture and technology combinations. It may be noted that the fitment value of each of the subset of architecture and technology combinations is greater than the predefined threshold.
[052] In an embodiment, the application analysis module 210 may perform the application-level analysis on the subset of architecture and technology combinations. In the application-level analysis, the technology and the architecture for each of the one or more business logics is identified from the subset of architecture and technology combinations based on application-level configurations. In some embodiments, based on the multi-dimensional analysis, a technology from a set of technologies and an architecture from a set of architectures is identified for each of the one or more business logics.
[053] Once the technology and the architecture are identified for each of the one or more business logics, the application development device 102 may further include a template identification module 212 that is configured to identify at least one template from a code template repository 218b within a database 218, based on the technology and the architecture identified for each of the one or more business logics.
[054] Further, the application development device 102 may include a code generation module 214. Based on the at least one template and based on the technology and the architecture identified, the code generation module 214 may further generate a code for each of the one or more business logics.
[055] The application development device 102 may further include a code deployment module 216. The code deployment module 216 may deploy the code based on the one or more business contexts on the technology and the architecture identified for each of the one or more business logics. This is further explained in greater detail in subsequent embodiments of the present disclosure.
[056] It should be noted that all such aforementioned modules 202 – 216 may be represented as a single module or a combination of different modules. Further, as will be appreciated by those skilled in the art, each of the modules 202 – 216 may reside, in whole or in parts, on one device or multiple devices in communication with each other. In some embodiments, each of the modules 202 – 216 may be implemented as dedicated hardware circuit comprising custom application-specific integrated circuit (ASIC) or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. Each of the modules 202 – 216 may
Docket No: IIP-HCL-P0142
-12-
also be implemented in a programmable hardware device such as a field programmable gate array (FPGA), programmable array logic, programmable logic device, and so forth. Alternatively, each of the modules 202 – 216 may be implemented in software for execution by various types of processors (e.g., processor 104). An identified module of executable code may, for instance, include one or more physical or logical blocks of computer instructions, which may, for instance, be organized as an object, procedure, function, or other construct. Nevertheless, the executables of an identified module or component need not be physically located together but may include disparate instructions stored in different locations which, when joined logically together, include the module, and achieve the stated purpose of the module. Indeed, a module of executable code could be a single instruction, or many instructions, and may even be distributed over several different code segments, among different applications, and across several memory devices.
[057] As will be appreciated by one skilled in the art, a variety of processes may be employed for on-demand application development. For example, the system 100 and the associated application development device 102 may develop on-demand application by the processes discussed herein. In particular, as will be appreciated by those of ordinary skill in the art, control logic and/or automated routines for performing the techniques and steps described herein may be implemented by the system 100 and the associated application development device 102 either by hardware, software, or combinations of hardware and software. For example, suitable code may be accessed and executed by the one or more processors on the system 100 to perform some or all of the techniques described herein. Similarly, application specific integrated circuits (ASICs) configured to perform some, or all of the processes described herein may be included in the one or more processors on the system 100.
[058] Referring now to FIG. 3, a flowchart of a method for on-demand application development is illustrated, in accordance with an embodiment. At step 302, one or more business logics from a data repository (for example, the business logic repository 218a) based on functionalities associated with an application to be developed and one or more business contexts associated with the application are identified. In an embodiment, the one or more business logics stored in the business logic repository 218a may be in a technology and an architecture agnostic format. The agnostic format may be, for example, a format of specification (such as, open API format). Further, each of the more or more business logics stored in the business logic
Docket No: IIP-HCL-P0142
-13-
repository 218a may include a set of predefined characteristics/functionalities based on which the application may be developed.
[059] Once the one or more business logics and one or more business contexts are identified, at step 304, a multi-dimensional analysis may be performed on the one or more business logics and the one or more business contexts. The multi-dimensional analysis may include a business logic level analysis, a business context level analysis, an architecture and technology level analysis, and an application-level analysis. The method of performing a multi-dimensional analysis is explained in detail in conjunction with FIGs. 4-6.
[060] Based on the multi-dimensional analysis, at step 306, a technology from a set of technologies and an architecture from a set of architectures for each of the one or more business logics is identified. Further, based on the technology and the architecture identified, at step 308, at least one template may be identified for each of the one or more business logics, for example, from the code template repository 218b.
[061] Based on the at least one template, and based on the technology and the architecture identified, at step 310, a code for each of the one or more business logics may be generated. Further, at step 312, the code may be deployed on the technology and the architecture identified for each of the one or more business logics based on the one or more business contexts.
[062] Referring now to FIG. 4, a flowchart of a method for performing the multi-dimensional analysis on business logics and business contexts is illustrated, in accordance with an embodiment. With reference to step 304 in FIG. 3, in order to perform the multi-dimensional analysis on the one or more business logics and the one or more business contexts, a business logic level analysis may be performed at step 402. In some embodiments, the business logic level analysis may be performed via the business logic analysis module 204. The step 402 includes a sub-step 402a.
[063] At sub-step 402a, a first affinity score relative to each of the set of technologies and each of the set of architectures may be determined for each of the one or more business logics based on a set of predefined business logic parameters. The set of predefined business logic parameters for a business logic from the one or more business logics may include at least one of input dependency of the business logic, usage pattern associated with the business logic, dependent business logics, influenced business logics, architecture affinity, technology affinity, and output generated by the business logic.
Docket No: IIP-HCL-P0142
-14-
[064] In other words, the first affinity score may be determined based on various inputs required for the processing of the business logic, process elements of the business logic, how the business logic is used, outputs generated by the business logic, dependency of the business logic with any other existing business logics, influence of the business logic with any other upcoming business logic, affinity of the business logic with any architecture patterns (i.e., for example, financial transaction processing must be near real time, even though it cannot be done using request-response model, so preferred way is to implement pub-sub architecture), and affinity of the business logic with any technologies (i.e., for example, master data management must be setup before any transaction takes place, and it must be structured to make relation with other day to day data. Therefore, it makes sense to use Relational Database Management system (RDMS) to setup such types of data. But data like blog and website content are unstructured and must be placed in NoSQL data stores).
[065] It may be noted that, the first affinity score determined may correspond to ease of deploying a business logic from the one or more business logics in each of the set of technologies and each of the set of architectures. Once the first affinity score is determined, then at step 404, a business context level analysis may be performed. In some embodiments, the business context level analysis may be performed via the business context analysis module 206. The step 404 includes a sub-step 404a.
[066] At sub-step 404a, for each of the one or more business contexts, a second affinity score relative to each of the set of technologies and each of the set of architectures may be determined based on a set of predefined business context parameters. The predefined business context parameters for a business context from the one or more business contexts may include target audience for the business context, business priority of the business context, architecture affinity of the business context, technology affinity of the business context, constrains associated with the business context, business contexts influenced by the business context, and business contexts dependent on the business context. It may be noted that, the second affinity score may correspond to ease of deploying the one or more business logics in each of the set of technologies and each of the set of architectures in the business context.
[067] Once the second affinity score is determined, then at step 406, an architecture and technology level analysis may be performed. In some embodiments,
Docket No: IIP-HCL-P0142
-15-
the architecture and technology level analysis may be performed via the architecture and technology level analysis module 208. The step 406 includes a sub-step 406a.
[068] At sub-step 406a, a third affinity score for each of the set of technologies relative to each of the set of architectures may be determined. As an example, the architecture and technology level analysis may be performed to identify a relationship between each of the set of technologies and each of the set of architectures. The third affinity score may correspond to the identified relationship. In some embodiments, the architecture and technology level analysis may be performed to identify technology to technology relationship from each of the set of technologies and architecture to architecture relationship from each of the set of architectures. This is further explained in conjunction with FIG. 8.
[069] Referring now to FIG. 5, a flowchart of a method for identifying a subset of architecture and technology combinations based on fitment value, in accordance with an embodiment. With reference to FIG. 4, based on the first affinity scores, the second affinity scores, and the third affinity scores, at step 502, a set of architecture and technology combinations may be identified for the one or more business logics and the one or more business contexts.
[070] At step 504, a fitment value for each of the set of architecture and technology combinations may be determined. It may be noted that, the fitment value may indicate a suitability of each of the set of architecture and technology combinations with respect to the business context. This is further explained in greater detail in conjunction with FIG. 7b.
[071] At step 506, the fitment value determined for each of set of architecture and technology combinations may be compared with a predefined threshold. Thereafter, at step 508, a subset of architecture and technology combinations may be identified. It may be noted that, the fitment value of each of the subset of architecture and technology combinations is greater than the predefined threshold. Referring now to FIG. 6, a flowchart of a method for performing an application-level analysis on a subset of architecture and technology combinations is illustrated, in accordance with an embodiment. With reference to FIG. 5, the application-level analysis may be performed on the subset of architecture and technology combinations. In some embodiments, the application-level analysis may be performed via the application-level analysis module 210. The step 602 includes a sub-step 602a.
Docket No: IIP-HCL-P0142
-16-
[072] At step 602a, the technology and the architecture for each of the one or more business logics may be identified from the subset of architecture and technology combinations based on application-level configurations.
[073] In some embodiments, once the technology and the architecture from the subset of architecture and technology combinations for each of the one or more business logics are identified, then a corresponding at least one template from a code template repository may be identified. Further, based on the at least one template, and based on the technology and the architecture identified a code may be generated for each of the one or more business logics. Moreover, the code may be deployed based on the one or more business contexts on the technology and the architecture identified for each of the one or more business logics. This is further explained in greater detail in conjunction with FIG. 8.
[074] Referring now to FIG. 7A, implementation of one or more business logics on the identified architecture and technology combination for on-demand application development is illustrated, in accordance with an exemplary embodiment. In an embodiment, the one or more business logics (for example, business logic 1, business logic 2, and business logic n) may be stored in the business logic repository 702 (analogues to the business logic repository 208a).
[075] The business logic may focus on functionalities requirement associated with an application 704 to be developed. As an example, logically the business logic may be purely independent of any technology or architecture environment. However, physically when it comes to the application development, the one or more business logics may be customized and implemented on suitable application and architecture.
[076] The one or more business logics may be combined to develop the on-demand application 704. Each of the business logic may have individual technology and architecture (for example, a business logic 1 may have a technology 704a and an architecture 704b, and a business logic 2 may have a technology 704c and an architecture 704d), or may have a common technology and architecture combination (for example, a business logic k and a business logic m may have a common technology 704e and a common architecture 704f) depending on nature of the business logic and business context. The process of implementing one or more business logics on the identified architecture and technology is explained in greater detail in conjunction with FIG. 7B.
Docket No: IIP-HCL-P0142
-17-
[077] Referring now to FIG. 7B, a functional block diagram for implementation of one or more business logics on the identified architecture and technology for on-demand application development is illustrated, in accordance with an exemplary embodiment. The block diagram may include a business logic repository 702, a public domain data storage 710, a business context data repository 712, architecture framework 714, technology templates 716, and architecture and technology mapping 718. The one or more business logics, the one or more business contexts, the set of architectures, and the set of technologies may be prestored in the corresponding business logic repository 702, the context data repository 712, the architecture framework 714, and the technology templates 716. Each set of architecture and each set of technology may be mapped for the one or more business logics and one or more business contexts through the architecture and technology mapping unit 718.
[078] As mentioned earlier, the one or more business logics may be stored in the business logic repository 702. Further, the one or more business logics from the business logic repository 702 based on functionalities associated with an application to be developed and one or more business contexts associated with the application are identified. Once, the one or more business logics and the one or more business contexts are identified, a business context prioritization analysis may be performed to determine a weightage and a priority of the business context (for example, a banking application business context) with respect to each of the one or more business logics. The highly important and priority business context may be considered first in the order for technology and architecture selection. This is further explained in conjunction with FIG. 8.
[079] Once the priority of the business context with respect to the one or more business logics are determined, a set of architecture and technology combinations may be identified. It may be noted that, the set of architecture and technology combinations may be identified based on the first affinity scores, the second affinity scores, and the third affinity scores. The determination of the first affinity scores, the second affinity scores, and the third affinity scores has already been explained in conjunction with FIGs. 4-6.
[080] Further, a fitment value for each of the set of architecture and technology combinations may be determined. The fitment value may be determined by performing the multi-dimensional analysis. In particular, the fitment value may be determined by performing a business logic level fitment analysis 706.
Docket No: IIP-HCL-P0142
-18-
[081] Further, the fitment value determined for each of set of architecture and technology combinations may be compared with a predefined threshold. By way of an example, the set of architecture and technology combinations whose fitment value is 9 may be compared with the set of architecture and technology combinations whose fitment value is other than 9. Based on the comparison, if the fitment value of one or more of the sets of architecture and technology combinations is found to be equal to or greater than 9, then that subset of architecture and technology combination may be identified. The subset of architecture and technology combinations may include only those architecture and technology combinations whose fitment value may be equal to or greater than 9. The complete process of determining the fitment value is further explained in greater detail in conjunction with FIG. 8.
[082] Further, an application-level fitment analysis 708 may be performed on the subset of architecture and technology combinations. In the application-level fitment analysis 804, the technology and the architecture for each of the one or more business logics may be identified from the subset of architecture and technology combinations based on application-level configurations.
[083] Referring now to FIG. 8, a detailed block diagram of a system for on-demand application development is illustrated, in accordance with an embodiment. As already discussed in conjunction with FIG. 3, once the one or more business logics and the one or more business contexts from the corresponding repository (for example, from the business logic repository 702 and the business context data repository 712) are identified, then a multi-dimensional analysis 802 may be performed on the one or more business logics and the one or more business contexts. The multi-dimensional analysis 802 may include a business logic level analysis 802a, a business context level analysis 802b, an architecture and technology level analysis 802c, and an application-level analysis 802d.
[084] The business logic level analysis 802a may be performed for each of the one or more business logics to determine a first affinity score relative to each of the set of technologies and each of the set of architectures based on a set of predefined business logic parameters. The business logic may focus on the functional side of the application requirements that is to be developed, for example, referring to an exemplary table 900 given in FIG. 9. The table 900 may include one or more business logics 902 (for example, login 902a, authentication 902b, entitlement management
Docket No: IIP-HCL-P0142
-19-
902c, transaction management 902d, and audit and log requirement 902e) and corresponding characteristics 904.
[085] To this end, architecture affinity of various architectures with each of the one or more business logics 902 may be created. This is depicted by an exemplary table 1000 given in FIG. 10. The table 1000 may depict architecture affinity 1002 for the one or more business logics 902 (for example, the login 902a, the authentication 902b, the entitlement management 902c, the transaction management 902d, and the audit and log requirement 902e). Various architectures for which the architecture affinity 1002 is depicted in the table 100 may include a monolith 1002a, a micro service 1002b, a request response model 1002c, a subscription and publishing model 1002d, a cloud deployment 1002e, and an on-premises deployment 1002f. The architecture affinity is depicted by affinity scores given in the table 1000.
[086] In a similar manner, technology affinity 1102 of various technologies with each of the one or more business logics 902 may depicted by way of an exemplary table 1100 given in FIG. 11. The table 1100 may include technology affinity 1102 of the login 902a, the authentication 902b, the entitlement management 902c, the transaction management 902d, and the audit and log requirement 902e with respect to various technologies, that may include a UI-Angular 1102a, a UI-React 1002b, java 1102c, .NET 1102d, Postgres SQL 1102e, DB- SQL Server 1102f, NSQL-Mongo 1102g, NSQL-Casandra 1102h, Cloud AWS 1102i, Cloud GCP 1102j, and Cloud Azure 1102k. The technology affinity is depicted by affinity scores given in the table 1100.
[087] In an embodiment, the affinity scores may be calculated for the architecture affinity 1002 and the technology affinity 1102 with respect to the one or more business logics 902 from a scale of 0 to 10. The “0” affinity score implies that the architecture and technology is not applicable for deployment, the affinity scores from 1-3 implies a low affinity for the architecture and technology deployment, the affinity scores from 4-6 implies a medium affinity for the architecture and technology deployment, and the affinity scores from 7-10 implies a good affinity for the architecture and technology deployment. For example, for a business logic “Login 902a” any one of the UI technologies like angular or react may be suitable and no database is required, as the affinity score maps to the good affinity category. Further, for the business logic “Transaction Management 902d,” the microservice architecture 1002b (having an affinity score of 9) may be more suitable as compared to the monolith
Docket No: IIP-HCL-P0142
-20-
architecture 1002a (having an affinity score of 6). Further, the business logic “Transaction Management 902d” may be developed in the java 1102c (having an affinity score of 8) or the .Net 1102d technology (having an affinity score of 8 8). For the business logic “Transaction Management 902d,” a relational database like PostgreSQL 1102e or SQL server 1102f (having an affinity score of 8) may be more suitable as compared to the unstructured DBs like Casandra 1102g (having an affinity score of 2).
[088] Once the first affinity score is determined, the business context level analysis 802b may be performed for each of the one or more business contexts to identify a second affinity score relative to each of the set of technologies and each of the set of architectures based on a set of predefined business context parameters.
[089] By way of an example, as the business logic focus on the functional side of the application requirements, the business context may focus on the usage type and non-functional side of the application requirements, such as but not limited to, scalability, security, performance, data size, or data type of the application. The main objective of the business context analysis is to identify a business priority for each of the one or more business logics and how such business priority may influence in identifying the architecture and the technology for one or more the business logics. The one or more business contexts may be, for example, a banking application or an ecommerce application.
[090] In order to calculate affinity scores to determine architecture affinity, consider, by way of an example, that the one or more business logics 902 need to be implemented for two business contexts. A first business context, i.e., to develop these business logics as part of finance application (banking application) and a second business context, i.e., to develop these business logics as part of an e-commerce application. Various non-functional parameters, for example, the security, performance, scaling, data management requirements for these two business contexts may be different. This may further have an impact on the architecture affinity with respect to each of these business contexts. The impact of these non-functional parameters associated the one or more business contexts is depicted in an exemplary table 1200 of FIG. 12. The exemplary table 1200 depicts the one or more business logics 1202 and the impacted parameters 1204 (for example, security 1204a, performance 1204b, scaling 1204c, rate of changes 1204d, data size 1204e, and data
Docket No: IIP-HCL-P0142
-21-
type 1204f). The one or more business contexts may include a banking application 1202a and an e-commerce application 1202b.
[091] Based on the impacted parameters 1204, the architecture affinity of various architectures with the one or more business contexts 1202 may be created, as shown in an exemplary table 1300 of FIG. 13. The exemplary table 1300 may include an architecture affinity 1402 that is computed by way of affinity scores for a set of architectures, i.e., the monolith 1002a, the micro service 1002b, the request response model 1002c, the subscription and publishing model 1002d, the cloud deployment 1002e, and the on-premises deployment 1002f, with respect to the business contexts 1202, i.e., the banking application 1202a and the e-commerce application 1202b. The affinity scores as determined under the architecture affinity 1402 corresponding to the banking application 1202a may be in the order “8”, “7”, “5”, “8”, “7”, and “8” respectively for the set of architectures. The affinity scores as determined under the architecture affinity 1402 corresponding to the e-commerce application 1202b may be in the order “7”, “8”, “8”, “8”, “8”, and “6” respectively for the set of architectures.
[092] Further, the architectural affinity of the set of architectures with the one or more business logics 902 for each of the one or more business contexts 1202 may be determined. To this end, affinity scores given in the architecture affinity 1002 for the one or more business logics 902 and affinity scores given in the architectural affinity 1302 for the one or more business contexts 1202 may be multiplied. For the business context of the banking application 1202a, the architectural affinity 1302a depicts affinity scores of various architectures with respect to the one or more business logics 902, as depicted in an exemplary table 1400A of FIG. 14A. Based on the affinity scores given under the architecture affinity 1402a in the FIG. 14A, it is apparent that in the banking application 1202a context, the micro service architecture1002a may be preferred for the business logic of “transaction management 902d,” while other business logics may be suitable for both the monolith 1002a and the microservice 1002b architectures.
[093] In a similar manner, for the e-commerce application business context 1302b, an architectural affinity 1402b that includes affinity scores of various architectures with respect to the one or more business logics 902, is depicted in an exemplary table 1400B of FIG. 14B. With reference to the present FIG. 14B, based on the affinity scores mentioned therein, the request response model architecture 1002c
Docket No: IIP-HCL-P0142
-22-
or the microservice architecture 1002b may be most preferred for the business context of e-commerce application in its entirety. However, while the micro service architecture 1002b may be most suitable and preferred for the transaction management 902d business logic, the request and response model architecture 1002c may be most suitable for the audit and log requirement 902e business logic.
[094] In an embodiment, the business context level analysis may further be performed to determine technology affinity, by way of affinity scores, for each of the set of technologies. In a manner similar to the affinity scores determined for each of the set of architectures affinity scores for each of the set of technologies may be determined with respect to the one or more business logics 902 based on the relevant business context 1202. For example, consider an exemplary table 1500 of FIG. 15 that depicts impacted parameters 1502 for technology selection with respect to the one or more business contexts 1202. Based on the impacted parameters 1502, technology affinity matrix may be created that includes a technology affinity 1702 for the one or more business contexts 1202 (for example, the banking application 1202a, and the e-commerce application 1202b), as depicted in an exemplary table 1600 of FIG. 16. The affinity scores for various technologies are given within the technology affinity 1602 for the banking application 1202a. Various technologies as given in the table 1600 may include a UI-angular 1602a, UI-react 1602b, backend-java 1602c, backend-.net 1602d, MS SQL 1602e, DB-MS SQL 1602f, NoSQL-Mongo 1602g, and NoSQL-casendra 1602h. The affinity scores for each of these technologies for the banking application 1202amay be in the order “7”, “7”, “8”, “8”, “9”, “9”, “4”, and “4” respectively. In a similar manner, the affinity scores for each of these technologies for the e-commerce application 1202b may be in the order “8, “8”, “8”, “8”, “7”, “7”, “8”, and “8” respectively.
[095] Further, the technology affinity of the one or more business logics 902 with various technologies for each of the one or more business contexts 1202 may be created by multiplying affinity scores given under the technology affinity 1102 for the one or more business logics 902 and the technology affinity 1602 of the one or more business contexts 1302. For example, a technology affinity 1702 that include affinity scores for the one or more business logics 902 within the business context of the banking application 1202a is shown in depicted in an exemplary table 1700 of FIG. 17. In a similar manner, a technology affinity 1802 that include affinity scores for the one or more business logics 902 within the business context of the e-commerce application
Docket No: IIP-HCL-P0142
-23-
1202b as depicted an exemplary table 1800 of FIG. 18. With reference to the FIG. 17 and FIG. 18, based on affinity scores, the e-commerce application 1302b may be more suitable on the cloud deployment technology (for example, cloud AWS, cloud Azure, or cloud GCP) as compared to the banking application 1302a, which may be more suitable on Java or .Net. By way of an example, for an API driven application, a spring boot rest may be a preferred choice. By way of another example, for autonomous applications, sending data to remote services may be orchestrated through event broker like RabitMQ or Kafka.
[096] In an embodiment, the business context level analysis 802b may further perform a business context inter-dependency analysis to determine interdependencies between the one or more business logics with respect to the one or more business contexts. The business context inter-dependency analysis may also help in identifying the technology and the architecture for the one or more business logics. For example, if cloud technology is selected and a particular cloud provider is identified or selected, then the same cloud provider selection may be more advantageous for another related business contexts.
[097] The interdependencies between the one or more business logics 902 corresponding to a banking application 1902a and a banking application 1902b is shown in exemplary table 1900 of FIG. 19. Similarly, the interdependencies between the one or more business logics 902 with respect to thee-commerce application 2002a and the e-commerce application 2002b is shown in an exemplary table 2000 of FIG. 20. It may be noted that, each of the business context may be compared against all other business contexts for determining the affinity scores.
[098] For example, it will be apparent based on the affinity scores given in the tables 1900 and 2000 that for the banking application 1902a and the banking application 1902b the authentication and entitlement management business logics are more dependent to the transaction management business logic. In contrast, for the e-commerce application 2002a and the e-commerce application 2002b, the authentication and entitlement management business logics are not so dependent on the transaction management business logic. It may be noted that the e-commerce applications may accept even the social media authentications (for example, google ID, Facebook ID, etc.).
[099] In an embodiment, the business context level analysis 802b may further perform a business context prioritization analysis. In the business context prioritization
Docket No: IIP-HCL-P0142
-24-
analysis, weightage and priority of each of the one or more business logics 902 may be calculated to decide the order for consideration of each of the one or more business logics 902. The highly important and priority business logics may be considered first in the order for technology and architecture identification. The decision on dependent business logics may be influenced by the top order business logic.
[0100] For example, the priority of the one or more business logics 902 with respect to the banking application 1202a is illustrated in an exemplary table 2100 of FIG. 21. The exemplary table 2100 may include the one or more business logics 902 (i.e., the login 902a, the authentication 902b, the entitlement management 902c, the transaction management 902d, and the audit and log requirement 902e) and the corresponding priority 2102 with respect to the business application 1202a. The table 2100 shows that the transaction management 902d (having a priority of 5) is the most important, when compared to other business logics.
[0101] Further, priority of the one or more business logics 902 with respect to the e-commerce application 1302b is illustrated in an exemplary table 2200 depicted in FIG. 22. The exemplary table 2200 shows that the transaction management 902d is the most important (having a priority of 5), when compared to other business logics. Also, the other business logics may not be as important as that in the case of the banking application 1202a. Hence, the technology and the architecture combination of transaction management 902d business logic may get more weightage. This may have an influence on the technology and architecture selection for other dependent business logics.
[0102] In an embodiment, the business context level analysis 802b may further perform a business context constraints analysis. The constraints of the one or more business contexts may also impact selection of the architecture and technology. For example, the business context may be very critical, but it may need to be executed in a specific timeline. In some embodiments, the constraint value of the business context with respect to the architecture and technology may be calculated.
[0103] By way of an example, consider the business context of a banking application. In the banking application, the constraints may be, the customer data security is very critical, and it cannot be saved in a public cloud. In that case, even if the most suitable architecture and technology combination suggested for deployment on cloud, the application may be required to be deployed on-premises due to very critical data security constraint.
Docket No: IIP-HCL-P0142
-25-
[0104] Once the business context level analysis 802b is performed, the multi-dimensional model 202 may further perform an architecture and technology level analysis 802c. In the architecture and technology level analysis 802c, another set of affinity scores is determined for each of the set of technologies relative to each of the set of architectures. The affinity scores may be determined based on the relationship between each of the set of technologies relative to each of the set of architectures.
[0105] An architecture and technology relationship matrix is illustrated in an exemplary table 2300 depicted in FIG. 23. The architecture and technology relationship matrix of the exemplary table 2300 may include a set of architectures 2304 (for example, the monolith 1002a, the micro service 1002b, the request response model 1002c, the subscription and publishing model 1002d, the cloud deployment 1002e, and the on-premises deployment 1002f) and a set of technologies 2302 (for example, the UI-Angular 1102a, the UI-React 1002b, the java 1102c, the .NET 1102d, the DB-Postgres SQL 1102e, the DB- MSSQL Server 1102f, the NSQL-Mongo 1102g, the NSQL-Casandra 1102h, the Cloud AWS 1102i, the Cloud GCP 1102j, and the Cloud Azure 1102k). The table 2300 shows that some of the technologies from the set of technologies may be more advantageously deployed on the microservice architecture 1002b and some on the monolith architecture 1002a. Similarly, some technologies may be neutral for both i.e., for the microservice architecture 1002b and for the monolith architecture 1002a.
[0106] In a similar manner, technology to technology and architecture to architecture relationship may also be determined. For example, an exemplary table 2400 of FIG. 24, illustrates architecture 2402 to architecture 2404 relationship matrix. The exemplary table 2400 shows that some architectures may be mutually exclusives (for example, the monolith 1002a and the microservice 1002b). Whereas some architectures may be more associated (for example, the microservice 1002b and the cloud deployment 1002e).
[0107] Further, an exemplary table 2500 of FIG. 25 illustrates technology to technology relationship matrix. The exemplary table 2500 shows that some technologies may be mutually exclusives (for example, the Java 1102c and the .Net 1102d). Whereas some technologies may be more associated (for example, the .net 1102d and the DB-MSSQL 1102f). On selection of some architecture, adoption of specific technologies may be advantageous. For example, on-premises subscription and publication application may be implemented using Active MQ and deployed using
Docket No: IIP-HCL-P0142
-26-
Jar on VMs. But for microservices, it may be recommended to package it using containers and deployed on orchestrator like Kubernetes for cloud portability.
[0108] In some embodiments, the multi-dimensions analysis may be performed for deciding the right technology and architecture combination for a business logic in the selected context. For example, there may be multiple business logic – architecture – technology combinations for a business context. A fitment value, which indicates the suitability of the combination with the business context may be derived based on the affinity scores determined in the above-mentioned business-logic level multidimensional analysis.
[0109] By way of an example, consider a case where the business context is the banking application 1202a, and the prioritized business logic is the transaction management 902d. Based on the architecture affinity as determined above with respect to the the banking application 1202a, the suitable architecture for the transaction management 902d, may be selected as the micro service 1002a, the subscription and publishing model 1002d, and the cloud deployment 1002e. Further, based on the technology affinity determined with respect to the banking application 1202a, the suitable technologies for the transaction management 902d are the Java 1102c, the .net 1102d, the Postgres SQL 1102e, the MSSQL 1102f, the Cloud-AWS 1102i, the Cloud-Azure 1002i, and the Cloud GCP 1102j.
[0110] Further, the technology and architecture relationship matrix, as depicted in the exemplary table 2300, is applied to group the architectures and technologies. In response to the application, multiple values may be determined. One of these values may be an architecture combination relationship value, which can be derived by multiplying the associated relationship value in between Architectures. For example, the relations ship value between the micro service 1002b and the subscription and publishing model 1002c, and the cloud deployment 1002e may be 64. This is depicted in a table 2600 in the FIG. 26.
[0111] These values may further include technology combination relationship value, which may be derived by multiplying the associated relationship value in between technologies. For example, the relationship value between the Java 1102c, PostgresSQL 1102e, and Cloud-AWS 1102i may be determined as 81, between the Java 1102c, the PostgresSQL 1102e, the Cloud-Azure 1102k may be determined as 72, between the Java 1102c, the PostgresSQL 1102e, the Cloud GCP 1102j may be determined as 81, between the .Net 1102d, the MSSQL 1102f, and the Cloud-AWS
Docket No: IIP-HCL-P0142
-27-
1102i may be determined as 63, between the .Net 1102d, the MSSQL 1102f, and the Cloud-Azure 1102k may be determined as 81, and between the .Net 1102d, the MSSQL 1102f, and the Cloud GCP 1102j may be determined as 63. This is depicted in an exemplary table 2700 in the FIG. 27.
[0112] Further, the fitment score (or fitment value as interchangeably used) may be calculated as the average of the relationship value and affinity score of a given business logic with respect to the business context. For example, the architecture fitment score of the transaction management 902d (business logic) with respect to the banking application 1202a (business context) is illustrated in the exemplary table 2600 of FIG. 26. In a similar manner, technology fitment score of the transaction management 902d (business logic) with respect to the banking application 1202a (business context) is illustrated in the exemplary table 2700 of FIG. 27.
[0113] Therefore, from FIGs. 26-27, the identified technology and architecture combination of the transaction management 902d (business logic) with respect to the banking application 1202a (business context) may include the following architectures: the micro service 1002b, the subscription and publishing model 1002d, and the cloud deployment 1002e and the following technologies: the Java 1102c, the PostgresSQL 1102e, the Cloud-AWS 1102i, or the Java 1102c,, the PostgresSQL 1102e, the Cloud-GCP 1102j or the .Net 1102d, the MSSQL 1102f, the Cloud-Azure 1102k.
[0114] In a similar manner, the fitment score may be calculated for all other business logics with respect to the selected business contexts. The architecture and technology combination may be identified based on the process given above. In some embodiments a business context dependency analysis, and a business context constraints analysis may be performed to finetune the selected architecture and technology combination. For example, in the business context of the banking application 1202a, the business logics of the authentication 902b and the entitlement management 902c may be dependent on the business logic of the transaction Management 902d. Hence, in the selection of architecture and technology combination for the authentication 902b and the entitlement management 902c, the architecture and technology combination of the transaction management 902d may have an impact.
[0115] In some embodiments, the multi-dimensional analysis 802 may be performed to identify a subset of architecture and technology combinations from the set of architecture and technology combinations for the one or more business logics
Docket No: IIP-HCL-P0142
-28-
and the one or more business contexts. Once the set of architecture and technology combinations are identified, an application-level analysis 802d may be performed. In the application-level analysis 802d, the technology and the architecture for each of the one or more business logics from the subset of architecture and technology combinations may be identified based on application-level configurations.
[0116] By way of an example, upon identifying the architecture and the technology combination, each shortlisted business logic – architecture – technology combination may be passed through the application-level analysis 802d for the final decision making. Each of the architecture and technology combination may be analyzed against the already selected or available components/service of the application. The application-level configurations and context may also be considered in the application-level analysis 802d analysis. Based on the analysis, the business logic may be associated with a new technology and architecture combinations that may be associated with another existing business logic. For example, in the case of the business context of the banking application 1202a, there may already be other applications or components of the same organization in the production. These components/applications may already be deployed on an environment (for example, on the cloud AWS). In this scenario, even if the above analysis suggests the combinations, Java, PostgresSQL, Cloud-AWS, or Java, PostgresSQL, Cloud-GCP or .net, MSSQL, Cloud-Azure, the Java, PostgresSQL, or Cloud-AWS combination may get the preference in the application-level analysis 802d.
[0117] Based on the multi-dimensional analysis 802, a technology from a set of technologies and an architecture from a set of architectures for each of the one or more business logics may be identified. For example, the multi-dimensional analysis 802 may produces a recommendation on the architecture and technology to be used for the one or more business logics based on the business context.
[0118] Further, once the technology from a set of technologies and an architecture from a set of architectures are identified for the one or more business logics. Thereafter, a dynamic transformation of the one or more business logics may be done through a dynamic business logic transformation unit 804. For dynamically transforming the one or more business logics, at least one template from a code template repository may be identified based on the technology and the architecture identified for each of the one or more business logics. Further, based on the at least one template and based on the technology and the architecture identified, a code may
Docket No: IIP-HCL-P0142
-29-
be generated for each of the one or more business logics. It may be noted that, the code may be generated by the code generation engine. Based on the one or more business contexts, the code may be deployed on the technology and the architecture identified for each of the one or more business logics.
[0119] In other words, initially, a suitable template from the template library may be identified based on the recommendation. Further, the code generation engine may generate the code base from the template that corresponds to the given business logic, architecture, technology combinations. Further, deployment context level parameters may be identified from the deployment context parameter repository and may then be associated with the generated code base to make an output deployable. The deployable element may be deployed in the selected target deployment environment 806. The target deployment environment 806 may be at least one of a cloud, such as, a cloud-AWS, a cloud-GCP, or a cloud-Azure.
[0120] As will be appreciated by those skilled in the art, the techniques described in the various embodiments discussed above are not routine, or conventional, or well understood in the art. The techniques discussed above provide for developing the application on-demand using the best suitable technology and architecture combination based on the business context and the business logic. Further, the techniques may improve accuracy of search engine and may facilitate automated mapping of the entity with the expected context.
[0121] As will be also appreciated, the above-described techniques may take the form of computer or controller implemented processes and apparatuses for practicing those processes. The disclosure can also be embodied in the form of computer program code containing instructions embodied in tangible media, such as floppy diskettes, solid state drives, CD-ROMs, hard drives, or any other computer-readable storage medium, wherein, when the computer program code is loaded into and executed by a computer or controller, the computer becomes an apparatus for practicing the invention. The disclosure may also be embodied in the form of computer program code or signal, for example, whether stored in a storage medium, loaded into and/or executed by a computer or controller, or transmitted over some transmission medium, such as over electrical wiring or cabling, through fiber optics, or via electromagnetic radiation, wherein, when the computer program code is loaded into and executed by a computer, the computer becomes an apparatus for practicing the
Docket No: IIP-HCL-P0142
-30-
invention. When implemented on a general-purpose microprocessor, the computer program code segments configure the microprocessor to create specific logic circuits.
[0122] It will be appreciated that, for clarity purposes, the above description has described embodiments of the invention with reference to different functional units and processors. However, it will be apparent that any suitable distribution of functionality between different functional units, processors or domains may be used without detracting from the invention. For example, functionality illustrated to be performed by separate processors or controllers may be performed by the same processor or controller. Hence, references to specific functional units are only to be seen as references to suitable means for providing the described functionality, rather than indicative of a strict logical or physical structure or organization.
[001] Although the present invention has been described in connection with some embodiments, it is not intended to be limited to the specific form set forth herein. Rather, the scope of the present invention is limited only by the claims. Additionally, although a feature may appear to be described in connection with particular embodiments, one skilled in the art would recognize that various features of the described embodiments may be combined in accordance with the invention.
[002] Furthermore, although individually listed, a plurality of means, elements or process steps may be implemented by, for example, a single unit or processor. Additionally, although individual features may be included in different claims, these may possibly be advantageously combined, and the inclusion in different claims does not imply that a combination of features is not feasible and/or advantageous. Also, the inclusion of a feature in one category of claims does not imply a limitation to this category, but rather the feature may be equally applicable to other claim categories, as appropriate.

We claim:

1. A method (300) of on-demand application development, the method (300) comprising:
identifying (302) one or more business logics (902) from a data repository based on functionalities associated with an application to be developed and one or more business contexts (1202) associated with the application;
performing (304) a multi-dimensional analysis (802) on the one or more business logics (902) and the one or more business contexts (1202), wherein the multi-dimensional analysis (802) comprises a business logic level analysis (802a), a business context level analysis (802b), an architecture and technology level analysis (802c), and an application-level analysis (802d);
identifying (306) a technology from a set of technologies and an architecture from a set of architectures for each of the one or more business logics (902) based on the multi-dimensional analysis (802);
identifying (308) at least one template from a code template repository (218b), based on the technology and the architecture identified for each of the one or more business logics (902);
generating (310) a code based on the at least one template and based on the technology and the architecture identified for each of the one or more business logics (902); and
deploying (312) the code based on the one or more business contexts (1202) on the technology and the architecture identified for each of the one or more business logics (902).
2. The method (300) as claimed in claim 1, wherein the business logic level analysis (802a) comprises:
determining (402a), for each of the one or more business logics (902), a first affinity score relative to each of the set of technologies and each of the set of architectures based on a set of predefined business logic parameters, wherein the first affinity score corresponds to ease of deploying a business logic from the one or more business logics (902) in each of the set of technologies and each of the set of architectures, and wherein the set of predefined business logic parameters for a
Docket No: IIP-HCL-P0142
-32-
business logic from the one or more business logics (902) comprises at least one of input dependency of the business logic, usage pattern associated with the business logic, dependent business logics, influenced business logics, architecture affinity, technology affinity, and output generated by the business logic.
3. The method (300) as claimed in claim 2, wherein the business context level analysis (802b) comprises:
determining (404a), for each of the one or more business contexts (1202), a second affinity score relative to each of the set of technologies and each of the set of architectures based on a set of predefined business context parameters, wherein the second affinity score for a business context from the one or more business contexts (1202) corresponds to ease of deploying the one or more business logics (902) in each of the set of technologies and each of the set of architectures in the business context, and wherein the set of predefined business context parameters for a business context from the one or more business contexts comprises target audience for the business context, business priority of the business context, architecture affinity of the business context, technology affinity of the business context, constrains associated with the business context, business contexts influenced by the business context, and business contexts dependent on the business context.
4. The method (300) as claimed in claim 3, wherein the architecture and technology level analysis (802c) comprise:
determining (406a) a third affinity score for each of the set of technologies relative to each of the set of architectures.
5. The method (300) as claimed in claim 4, wherein performing the multi-dimensional analysis (802) comprises:
identifying (502) a set of architecture and technology combinations for the one or more business logics (902) and the one or more business contexts (1202), based on the first affinity scores, the second affinity scores, and the third affinity scores;
determining (504) a fitment value for each of the set of architecture and technology combinations;
comparing (506) the fitment value determined for each of set of architecture and technology combinations with a predefined threshold; and
Docket No: IIP-HCL-P0142
-33-
identifying (508) a subset of architecture and technology combinations, wherein the fitment value of each of the subset of architecture and technology combinations is greater than the predefined threshold.
6. The method (300) as claimed in claim 4, wherein the application-level analysis (802d) is performed on the subset of architecture and technology combinations, and wherein the application-level analysis (802d) comprises:
identifying (602a) the technology and the architecture for each of the one or more business logics (902) from the subset of architecture and technology combinations based on application-level configurations.
7. A system (100) of on-demand application development, the system (100) comprising:
a processor (104) and a memory (106) communicatively coupled to the processor (104), wherein the memory (106) stores processor-executable instructions, which, on execution, causes the processor (104) to:
identify one or more business logics (902) from a data repository based on functionalities associated with an application to be developed and one or more business contexts (1202) associated with the application;
perform a multi-dimensional analysis (802) on the one or more business logics (902) and the one or more business contexts (1202), wherein the multi-dimensional analysis (802) comprises a business logic level analysis (802a), a business context level analysis (802b), an architecture and technology level analysis (802c), and an application-level analysis (802d);
identify a technology from a set of technologies and an architecture from a set of architectures for each of the one or more business logics (902) based on the multi-dimensional analysis (802);
identify at least one template from a code template repository (218b), based on the technology and the architecture identified for each of the one or more business logics (902);
generate a code based on the at least one template and based on the technology and the architecture identified for each of the one or more business logics (902); and
Docket No: IIP-HCL-P0142
-34-
deploy the code based on the one or more business contexts on the technology and the architecture identified for each of the one or more business logics (902).
8. The system (100) as claimed in claim 7,
wherein the business logic level analysis (802a) comprises:
determine, for each of the one or more business logics (902), a first affinity score relative to each of the set of technologies and each of the set of architectures based on a set of predefined business logic parameters, wherein the first affinity score corresponds to ease of deploying a business logic from the one or more business logics in each of the set of technologies and each of the set of architectures; and
wherein the business context level analysis (802b) comprises:
determine, for each of the one or more business contexts (1202), a second affinity score relative to each of the set of technologies and each of the set of architectures based on a set of predefined business context parameters, wherein the second affinity score for a business context from the one or more business contexts corresponds to ease of deploying the one or more business logics in each of the set of technologies and each of the set of architectures in the business context.
9. The system as claimed in claim 8, wherein the architecture and technology level analysis (802c) comprise:
determine a third affinity score for each of the set of technologies relative to each of the set of architectures.
10. The system as claimed in claim 9, wherein to perform the multi-dimensional analysis (802) the processor (104) is configured to:
identify a set of architecture and technology combinations for the one or more business logics (902) and the one or more business contexts (1202), based on the first affinity scores, the second affinity scores, and the third affinity scores;
determine a fitment value for each of the set of architecture and technology combinations;
Docket No: IIP-HCL-P0142
-35-
compare the fitment value determined for each of set of architecture and technology combinations with a predefined threshold; and
identify a subset of architecture and technology combinations, wherein the fitment value of each of the subset of architecture and technology combinations is greater than the predefined threshold.
11. The system as claimed in claim 9, wherein the application-level analysis (802d) is performed on the subset of architecture and technology combinations, and wherein the application-level analysis (802d) comprises:
identify the technology and the architecture for each of the one or more business logics (902) from the subset of architecture and technology combinations based on application-level configurations.