FORM 2
THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENT RULES, 2003
COMPLETE SPECIFICATION (See Section 10 and Rule 13)
Title of invention:
SYSTEMS AND METHODS FOR SELECTION AND
RECOMMENDATION OF DATA STORE TYPES FOR
SOFTWARE APPLICATION 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
Preamble to the description
The following specification particularly describes the invention and the manner in which it is to be performed.

TECHNICAL FIELD [001] The disclosure herein generally relates to software application architectures, and, more particularly, to systems and methods for selection and recommendation of data store types for software application architecture.
BACKGROUND [002] Designing a software architecture for a large system is accompanied by the complexities of determining various components that best fit application requirement. The requirements of the application can be functional or non-functional in nature. Solution architects are faced with this non-trivial task of determining not only the precise components for ensuring correct functionality, but also ensuring that user defined Service Level Agreement (SLA) is guaranteed. While an architecture is comprised of multiple components such as messaging component, data store and processing components and visualization component to name a few, it is to be noted that data component is fundamental to the functioning of any software system and plays a critical role in the process of software application architecture and its usage. The primary challenge in any software architecture design is determining correct data flow and the data store required, to ensure that not only the functional requirements of the system are met, but also that the architecture is scalable and reliable.
SUMMARY [003] Embodiments of the present disclosure present technological improvements as solutions to one or more of the above-mentioned technical problems recognized by the inventors in conventional systems. For example, in one aspect, there is provided a processor implemented method for selecting and recommending data store types for software application architecture. The method comprises receiving an input request from a user, wherein the input request is specific to architecting a software application specific to a domain; selecting a pre-defined decision tree amongst a plurality of decision trees stored in a database based on the input request, each node in the selected pre-defined decision tree

comprises a pre-defined query, wherein the plurality of decision trees are constructed using a plurality a questions comprised in a question bank, wherein the question bank comprises questions corresponding to one or more domains, and wherein the plurality of questions in the plurality of decision trees are based on functional and non-functional features of a particular domain; sequentially traversing through one or more nodes in the selected pre-defined decision tree based on a response received for a corresponding query at each node; automatically triggering a set of prioritized atomic rules stored in the database based on one or more sequential responses received for each query of the one or more nodes sequentially traversed; generating one or more composite rules using the set of prioritized atomic rules; and dynamically selecting, based on the one or more composite rules, a set of data store types from a plurality of data store types stored in a taxonomy comprised in the database and recommending thereof, wherein each of the plurality of data store types corresponds to one or more components of the software application.
[004] In an embodiment, the plurality of data store types is based on one or more properties of the one or more components of the software application. In one embodiment, the one or more properties comprise at least one of functional features, and non-functional features.
[005] In an embodiment, wherein the one or more composite rules are a combination of two or more atomic rules.
[006] In an embodiment, each of the plurality of data stores types is classified into a decision table using a taxonomy tree based on associated functional or non-functional features.
[007] In another aspect, there is provided a system for selecting and recommending data store types for software application architecture. The system comprises a memory storing instructions; one or more communication interfaces; and one or more hardware processors coupled to the memory via the one or more communication interfaces, wherein the one or more hardware processors are configured by the instructions to: receive an input request from a user, wherein the input request is specific to architecting a software application specific to a

domain; select a pre-defined decision tree amongst a plurality of decision trees stored in a database based on the input request, each node in the selected pre¬defined decision tree comprises a pre-defined query, wherein the plurality of decision trees are constructed using a plurality a questions comprised in a question bank, wherein the question bank comprises questions corresponding to one or more domains, and wherein the plurality of questions in the plurality of decision trees are based on functional and non-functional features of a particular domain; sequentially traverse through one or more nodes in the selected pre-defined decision tree based on a response received for a corresponding query at each node; automatically trigger a set of prioritized atomic rules stored in the database based on one or more sequential responses received for each query of the one or more nodes sequentially traversed; generate one or more composite rules using the set of prioritized atomic rules; and dynamically select, based on the one or more composite rules, a set of data store types from a plurality of data store types stored in a taxonomy comprised in the database and recommend thereof, wherein each of the plurality of data store types corresponds to one or more components of the software application.
[008] In an embodiment, the plurality of data store types is based on one or more properties of the one or more components of the software application. In one embodiment, the one or more properties comprise at least one of functional features, and non-functional features.
[009] In an embodiment, wherein the one or more composite rules are a combination of two or more atomic rules.
[010] In an embodiment, each of the plurality of data stores types is classified into a decision table using a taxonomy tree based on associated functional or non-functional features.
In yet another aspect, there are provided one or more non-transitory machine readable information storage mediums comprising one or more instructions which when executed by one or more hardware processors cause selecting and recommending data store types for software application architecture by receiving an input request from a user, wherein the input request is specific to architecting a

software application specific to a domain; selecting a pre-defined decision tree amongst a plurality of decision trees stored in a database based on the input request, each node in the selected pre-defined decision tree comprises a pre¬defined query, wherein the plurality of decision trees are constructed using a plurality a questions comprised in a question bank, wherein the question bank comprises questions corresponding to one or more domains, and wherein the plurality of questions in the plurality of decision trees are based on functional and non-functional features of a particular domain; sequentially traversing through one or more nodes in the selected pre-defined decision tree based on a response received for a corresponding query at each node; automatically triggering a set of prioritized atomic rules stored in the database based on one or more sequential responses received for each query of the one or more nodes sequentially traversed; generating one or more composite rules using the set of prioritized atomic rules; and dynamically selecting, based on the one or more composite rules, a set of data store types from a plurality of data store types stored in a taxonomy comprised in the database and recommending thereof, wherein each of the plurality of data store types corresponds to one or more components of the software application.
[011] In an embodiment, the plurality of data store types is based on one or more properties of the one or more components of the software application. In one embodiment, the one or more properties comprise at least one of functional features, and non-functional features.
[012] In an embodiment, wherein the one or more composite rules are a combination of two or more atomic rules.
[013] In an embodiment, each of the plurality of data stores types is classified into a decision table using a taxonomy tree based on associated functional or non-functional features.
[014] 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

[015] The accompanying drawings, which are incorporated in and constitute a part of this disclosure, illustrate exemplary embodiments and, together with the description, serve to explain the disclosed principles:
[016] FIG. 1 depicts a taxonomy representing various properties or features based on which data stores are available for classification, in accordance with an embodiment of the present disclosure.
[017] FIG. 2 depicts illustrates an exemplary block diagram of a system for selecting and recommending one or more data store types for software application architecture, in accordance with an embodiment of the present disclosure.
[018] FIG. 3 is an exemplary flow diagram illustrating a method for selecting and recommending one or more data store types for software application architecture using the system of FIG. 2, in accordance with an embodiment of the present disclosure.
[019] FIG. 4, depicts an exemplary software application architecture ‘Team App’ for which data store type(s) is/are to be selected and recommended by the system of FIG. 2, in accordance with an embodiment of the present disclosure.
DETAILED DESCRIPTION OF EMBODIMENTS [020] Exemplary embodiments are described with reference to the accompanying drawings. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. Wherever convenient, the same reference numbers are used throughout the drawings to refer to the same or like parts. While examples and features of disclosed principles are described herein, modifications, adaptations, and other implementations are possible without departing from the scope of the disclosed embodiments. It is intended that the following detailed description be considered as exemplary only, with the true scope being indicated by the following claims.
[021] The process of designing a new software architecture or re-architecting an existing solution, is complex and is often accompanied by multiple

challenges. Re-architecting comes into play owing to issues relating to performance, inherent hardware upgrades or the need for porting an application to the cloud. Software architects are faced with the task of selecting the right component in an architecture stack. The architecture stack is comprised of multiple components such as the data store component, data or stream processing component, the middleware, visualization component and so on. It is imperative that the software architect, determines components that meet the overall requirement of the user application.
[022] In software architecting domain, as of today, most of the huge monolithic software architectures are actually being restructured or redesigned into micro service architectures. Micro service architectures are small components wherein each component is a complete functional unit cell in itself performing a particular task. The functionality from a monolithic architecture is re-designed in such a way that each small independent component performs its independent task. When there are series of such components, they need to interact with each other. Metric passing interfaces are provisioned which enable them to interact with each other for exchanging messages to exchange data and in general achieve the same functionality which could be achieved by a monolithic software architecture. But without having a framework of being architecture becomes a single point of failure since in such environment everything is distributed.
[023] As discussed above, data becomes a fundamental unit for such kind of architectures. It is therefore pertinent to know how functional units are designed and how interaction of these functional units with each other are decided and what exactly is needed for such interactions. This requires data flow for an entire system which is fundamental unit of any application. Furthermore, it is important to know how data flows across different components and how this data gets stored.
[024] Embodiments of the present disclosure address these unresolved problem when designing a software system with all these complexities. For a microservice architecture or any other form of distributed architecture, it is important to know how and which architecture component is going to be fitted

with a particular type of data store are decided in order to ensure that both functional requirements of the software application and the non-functional requirements are met for architecture (e.g., not only functional requirements but also the non-functional requirements). This largely depends on several critical parameters for example, but are not limited to, incoming data type, from where is the data coming in, volume of data, velocity of incoming data, and so on. Given the above critical parameters, it is to be noted that data has multiple properties such as structured, unstructured, speed of data flow, volume of data, rate at which data comes in (e.g., data in batches or data in real-time) and the like. All these should be accounted into decision making process of what would be an ideal data store for a particular software component.
[025] In the entire micro service architecture, a deeper view of particular component(s) is needed to decide which data store best fits for these particular component(s) depending upon the end requirement, which becomes a challenge. This challenge is still persisting, as previously in monolithic architectures which is a different era altogether, solution architects have mainly thought of structured query language (SQL) databases and relational database management system (RDMS) databases which work fine since there is structured data which fit into these databases very well. With the advent of technology and dynamic change in data with respect to time, there is lot of unstructured data, e.g., data may be in the form of images, text or other media, and so on and heterogeneous becomes another property of data which systems are seeing.
[026] Again within such above systems, high speed systems (e.g., high performance computing systems) are observed. As discussed above, architectures are breaking into smaller components and each component within itself may be handling a different type of data but all these components need to interact within themselves to achieve a common goal which originally a monolithic system would be achieving. So for a solution architect this is not only time consuming but also a very challenging aspect to determine the best suited data store for any (software) component for software architectures.

[027] Embodiments of the present disclosure provide systems and methods for selecting and recommending data store types for a given software application architecture under consideration. This is achieved by the present disclosure by building a taxonomy comprising both functional and non-functional features which would be part of any data store. By building such taxonomy, the present disclosure enables viewing at different aspects of data: data type (e.g., structured or unstructured), application type (e.g., monolithic system which is more of a centralized application, micro service is one of the many types of decentralized application), data properties (e.g., ACID properties (Atomicity, Consistency, Isolation, Durability) of transaction support provided by RDBMS in order to ensure accuracy, completeness, and data integrity), velocity, support for analytics, and the like.
[028] On the other data, architecting a software application also requires determining way of querying data while it is stored. In other words, storing the data is one aspect, reading the data is another aspect for a given application (e.g., how data is read for a given application). Suppose, the requirement is faster data read capability versus a data write capability. Therefore, with above requirement, the question remains - what can be the different ways this data can be queried (for instance: can the query action be performed using a single attribute or multiple attributes are required?). There are various data stores which enable one on how to redesign a query mechanism. For instance, query mechanism can be designed using index, multi-column or wide-column techniques. Again this is suited for application type, which is why making a decision becomes difficult.
[029] While data storage becomes critical, end users also need to focus on the volume of data that a software application can handle where the user can take call whether it is read intensive or write intensive. While all the above features constitute functional capabilities, software application architectures also comprise non-functional requirements (NFR) features. For example, NFR may include query feature such as scalability, latency, availability, consistency, and the like. Current conventional systems find themselves challenging in incorporating functional and non-functional features in software application architectures.

[030] The present disclosure enables systems and methods for creation of taxonomy using the functional and non-functional requirements. Using this taxonomy, the present disclosure classifies different type of data stores (e.g., SQL and NoSQL). Of late the trend has been to move to NoSQL. As a solution architect, it is difficult to reason out why a particular data store is picked up/selected over other data store. Many a times, the only reason stated by a solution architect is of being familiar with that particular data store and number of times he/she has used it in the past for architecting software applications.
[031] Further, the present disclosure also builds a question bank. Consider a scenario, where a solution architect is faced with a problem of designing or finding a best component for a data store. The present disclosure enables system to trigger a set of questions to the solution architect, wherein these questions are based on overall features that an application desires to have which could be functional and/or non-functional. The present disclosure generates these question banks across domains that are simple for a semi-technical person to understand and to answer without having to get into triggering detailed question(s). Such questionnaire is helpful for a person of one domain designing components of an application of another domain (e.g., person from retail domain designing components of an application for a hospitality domain).
[032] To account such scenarios as well, present disclosure provides systems and methods that trigger high level questions (which are pre-defined and can evolve over time using self-learning capabilities) to the semi-technical person such that he/she is able to provide answers. The system of the present disclosure may be comprised with machine-learning/artificial intelligence components to evolve and also update the questionnaire comprised in the system for each software application architecture type and domain thereof, including automatic selection and recommendation of data store types for subsequent incoming requests (e.g., software application architecture request for which data store types are required). Using the answers, rules are triggered/fired (e.g., (i) atomic or primitive rules and (ii) composite rules). Primitive/atomic rules are rules which give certain basic information which may be correct but when tried to fit it in a

composite rule may not be correct (or contradicting certain condition(s)). For instance, say input data is on memory, rule can say data type is structured, if data is image or files, then it can be called unstructured. In other words, this means if data does not have ACID properties (Atomicity, Consistency, Isolation, Durability) then it is NoSQL data store type.
[033] So, in the present disclosure these multiple atomic rules which when bunched together form composite rule(s), wherein the composite rules enable selection and recommendation of data store type for (i) software application architecture or (ii) component(s) of the software application architecture.
[034] In a nutshell, embodiments of the present disclosure focus on alleviating the complexity faced by the solution architect when determining an appropriate data store, for any architecture component. The present disclosure presents the above taxonomy of various features of a data store which are significant in the decision making process for the design of any software system. Systems and methods of the present disclosure classify (commonly used) data store types into a decision table using the taxonomy tree. This decision table gives rise to atomic and composite rules. These rules are (or may be) stored in Drools, which is a business rule management system. Embodiments of the present disclosure also discuss a case study to illustrate how the decision table based approach, assists solution architects in determining a data store type which a good fit for a given user input request comprising building software application architecture.
[035] Referring now to the drawings, and more particularly to FIGS. 1 through 4, where similar reference characters denote corresponding features consistently throughout the figures, there are shown preferred embodiments and these embodiments are described in the context of the following exemplary system and/or method.
[036] As described above, the fundamental aspect of any application is its data. The application function is defined by the manner in which the data flows across the components of the application, the manner in which the data is stored

and accessed and the volume and velocity of the data. With multiple choices of data stores being available today, it becomes significantly challenging for software architect(s), to determine the precise choice of data store based on the features and behavior of the data. Data stores can be either SQL or NoSQL. The application may require support for RDBMS. As discussed above, embodiments of the present disclosure address the problem of determining a data store component, that closely matches the requirements of the user, wherein systems and methods of the present disclosure understand various components of a software architecture through (a limited) questions and answer session triggered for receiving response from end user. Rules (both atomic and composite rules) are built (or pre-defined) that are triggered based on the users’ responses. The rules are fired/triggered on decision tables, that facilitate the decision making process for the solution architect when determining an appropriate data store.
[037] In reference to above, FIG. 1 depicts a taxonomy representing various properties or features based on which data stores are available for classification, in accordance with an embodiment of the present disclosure. Taxonomy as depicted in FIG. 1 can be applicable to all types of data stores. In the present disclosure, the taxonomy as depicted in FIG. 1 is built (or created) by the system 100 of FIG. 2 based on user inputs (e.g., user inputs may include suggestions/feedback on a certain feature to be in a specific data store type, and the like). Based on study carried out by the present disclosure for software architectures in various domains (e.g., enterprise, microservice (or micro service)), a set of features were identified, that are (most) relevant to a software architecture, when deciding the type of data store component for the overall architecture. The features can be functional (features that affect the regular functioning of an application - transaction support, complex queries, data volume and velocity) or non-functional (performance parameters such as scalability, availability). For any application (e.g., refer FIG. 1), in the present disclosure, system first needs to understand if the data is structured or unstructured. Additional categories pertaining to data are the need for Atomicity, Consistency, Isolation, and Durability (ACID) and transaction support by the application,

velocity and volume of the data and support for analytics. This enables the
solution architect to determine if a RDBMS (relational database management
system) is more suited versus an SQL (Structured Query Language) or NoSQL
data store. The non-functional requirements (NFR), focus on the performance
guarantees that are expected by the application, which directly affect the choice of
data store. In the present disclosure, NFR features, for example, but are not
limited to scalability, read latency, write latency, availability, consistency have
been considered. Other NFR examples include but are not limited to,
authentication, while transaction no duplicate entries, time-out sessions, number
of concurrent users accessing one or more components of the software
application, and the like. It is also important to understand how data is accessed
by the application. This determines the manner in which queries are fired on the
data, which in turn influences decision for choice of a suitable data store. Data
stores can be broadly divided into two categories - SQL data store and NoSQL,
with and without support for RDBMS. While NoSQL stores came into play to
provide scalability and support for unstructured data, many NoSQL data stores
provide support for ACID properties as well. Below are examples of
classification of different types of data stores based on the taxonomy presented in FIG 1. More specifically, following are categories of NoSQL data stores:
1. Key Value Store - This store is based on a hashtable (or hash table) in which there exists a unique key and a pointer to a particular data item.
2. Document Store - This is similar to a key value store, but the data (or values) are stored in a document format. The document may follow some kind of structure such as XML (eXtensible Markup Language) or JSON (JavaScript Object Notation).
3. Columnar Store - Data is stored in such a manner that columns of data are grouped together, as against grouping of rows. This is unlike relational databases which store a single row as a continuous disk entry.
4. Graph Store - Data is stored using edges and nodes wherein edges represent the relationships between nodes. A flexible graphical representation is extremely useful in addressing scalability concerns.

[038] Below Table 1 depicts a decision table that classifies data stores based on the taxonomy presented in FIG. 1. In the present disclosure data stores classification is based on user inputs (e.g., user inputs may include suggestions/feedback on a certain feature with a specific feature value to be classified as a specific data store type, and the like as depicted in below Table 1). This classification is used in the creation of rules for the rule engine, in one embodiment of the present disclosure.
TABLE 1

Feature Feature Value RDBMS Key Value Document Columnar Graph
Data Type Structured Y N N N N

Unstructured N Y Y Y Y
App type Centralized Y N N N N

Decentralized Y Y Y Y Y
Data property ACID Y Y/N Y/N Y/N Y/N

Transaction Y Y/N Y/N Y/N Y/N

Velocity Moderate High High High High
Query Simple Y Y Y Y Y

Complex Y N N N N

Single attribute Y Y Y NA NA

Multi attribute Y N Y NA NA

Index Y N Y NA NA

Column NA NA NA Y NA
Storage Volume Moderate Large Large Very Large Large
ReadHeavy Y Y Y Y Y
WriteHeavy N Y Y Y N
Analytics N Y Y Y Y
NFR Scalability ModHigh High High High High

ReadLatency Low Low Low Low Low

WriteLatency Mod Low Low Low Mod

Availability High High High High High

Consistency Strong Eventual Eventual Eventual Eventual
[039] FIG. 2, with reference to FIG. 1, depicts illustrates an exemplary block diagram of a system for selecting and recommending one or more data store types for software application architecture, in accordance with an embodiment of the present disclosure. The system 100 may also be referred as ‘selection and recommendation system’ or ‘data store recommendation system’ and may be interchangeably used hereinafter. In an embodiment, the system 100 includes one or more hardware processors 104, communication interface device(s) or input/output (I/O) interface(s) 106 (also referred as interface(s)), and one or more data storage devices or memory 102 operatively coupled to the one or more hardware processors 104. The one or more processors 104 may be one or more software processing components and/or hardware processors. In an embodiment, the hardware processors can 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 processor(s) is configured to fetch and execute computer-readable instructions stored in the memory. In an embodiment, the system 100 can be implemented in a variety of computing systems, such as laptop computers, notebooks, hand-held devices, workstations, mainframe computers, servers, a network cloud and the like.
[040] The I/O interface device(s) 106 can include a variety of software and hardware interfaces, for example, a web interface, a graphical user interface, and the like and can facilitate multiple communications within a wide variety of networks N/W and protocol types, including wired networks, for example, LAN, cable, etc., and wireless networks, such as WLAN, cellular, or satellite. In an embodiment, the I/O interface device(s) can include one or more ports for connecting a number of devices to one another or to another server.

[041] The memory 102 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. In an
embodiment, a database 108 is comprised in the memory 102, wherein the
database 108 comprises information, for example, input request pertaining to
software application architecture of a specific domain, pre-defined decision trees,
information on selected decision tree, question bank, corresponding responses
received from users for respective questions, domain specific functional and non-
functional requirements, traverse information within a select decision tree for each
given software application architecture requirement, and the like. In an
embodiment, the memory 102 may store (or stores) rule engine that comprises of atomic rules (e.g., also referred as ‘primitive rules), composite rules, data store types, and the like. The memory 102 further comprises (or may further comprise) information pertaining to input(s)/output(s) of each step performed by the systems and methods of the present disclosure. More specifically, information pertaining to input request, selection of decision tree among decision trees comprised in the database 108, the way each node is traversed in the decision tree based on the responses received for the queries fired at users’, type of prioritized atomic rules triggered, composite rules generated by using the triggered atomic rules, selection and recommendation of data store type, and the like, may be stored in the memory 102. In other words, input(s) fed at each step and output(s) generated at each step are comprised in the memory 102, and can be utilized in further processing and analysis.
[042] FIG. 3, with reference to FIGS. 1-2, is an exemplary flow diagram illustrating a method for selecting and recommending one or more data store types for software application architecture using the system 100 of FIG. 2, in accordance with an embodiment of the present disclosure. In an embodiment, the system(s) 100 comprises one or more data storage devices or the memory 102 operatively coupled to the one or more hardware processors 104 and is configured

to store instructions for execution of steps of the method by the one or more
processors 104. The steps of the method of the present disclosure will now be
explained with reference to components of the taxonomy of FIG. 1, the system
100 of FIG. 2, and the flow diagram as depicted in FIG. 3. At step 202 of the
present disclosure, the one or more hardware processors 104 receive an input
request from a user, the input request is specific to architecting a software
application specific to a domain (or domains). At step 204 of the present
disclosure, based on the input request, the one or more hardware processors 104
select a pre-defined decision tree amongst a plurality of decision trees stored in
the database 108. Each node in the selected pre-defined decision tree comprises a
pre-defined query. In the present disclosure, the decision trees are constructed
using a plurality a questions comprised in a question bank. The question bank is
comprised in the memory 102 wherein the question bank comprises questions
corresponding to one or more domains. Further the plurality of questions in the
plurality of decision trees are based on functional and non-functional features of a
particular domain for which the software application architecture request is
received. At step 206 of the present disclosure, the one or more hardware
processors 104 sequentially traverse through one or more nodes in the selected pre-defined decision tree based on a response received for a corresponding query at each node. The sequential traversing and response being received at each node result in obtaining one or more sequential responses or a set of sequential responses. For instance, at node 1, response 1 (e.g., say answer 1) is received. Based on the response 1 at node 1, the system 100 may traverse to either to (i) node 2 or node 3 or (ii) to node 2 and then followed by node 3. Similarly, the system 100 further traverses to a next node (e.g., say 4th node) based on response for query at (i) node 2 or node 3 or (ii) at node 2 and then followed by query at node 3. This is done until a last node (or a nth node being the last node) in the selected decision tree which results in set of sequential responses, wherein response for a query at one node is followed by a response pertaining to another query at another node. Therefore, depending upon a response for a particular query at a node, certain other nodes may be skipped (as an upcoming node may be

irrelevant based on a response to a query of a current node), and the system 100 may change its path within the selected decision tree (e.g., say at 4th node, a response was received, and the system 100 chose path that led to node 6 directly instead of path that led to node 5 followed by node 6 and/or node 7). Such a change in path(s) may be observed number of times until the last node is reached for which a corresponding response (or answer) is obtained from user, thus resulting in a set of responses, hereinafter referred as ‘sequential responses’. At step 208 of the present disclosure, the one or more hardware processors 104 automatically trigger a set of prioritized atomic rules (e.g., also referred as primitive rules or simply ‘atomic rules’) stored in the database 108 based on the sequential responses received for each query of the one or more nodes sequentially traversed.
[043] Assuming the input request is pertaining to a software application architecture say, ‘Team App’ (TA). FIG. 4, depicts an exemplary software application architecture ‘Team App’ for which data store type(s) is/are to be selected and recommended by the system 100 of FIG. 2, in accordance with an embodiment of the present disclosure. The TA is an application that enables multiple users in an organization to interact and share information with each other via a common platform. The users are members of specific teams, in one example of the present disclosure. Teams are formed for various projects and the users can share or read information pertaining to a project on the team thread. Additionally, the users have other options such as exchanging private messages with other users via chat application, interacting with bots that are tuned to perform tasks specific to the organization. Assuming, this architecture will (or can) be designed as a microservice architecture where each service acts as a functional component. In the case study as depicted in FIG. 4, the present disclosure has focused on a component referred as ‘Team Service’. The aim has been to determine data store that best suits team service. The Team Service enables the user to be a member of a project team thread. The user can then post information to the thread, read information, download and upload data in various forms. The system 100 traverses through each node wherein the system 100 fills a questionnaire

comprised the selected decision tree based on answers provided to the questions by the user at each node. Each question and answer is associated with some primitive rule in the rule engine comprised in the memory 102. Once all the primitive rules are identified, the system 100 then generates composite rules based on the decision tree to determine the data store type which is a best fit based on the user application requirements.
[044] Below Table 2 depicts questions and the corresponding answers for the component ‘Team Service’. In addition, Table 2, also depicts relevant atomic rules that are identified and triggered by the system 100 based on the answers (or responses) received for the questions at each node of the selected decision tree. In other words, Table 2 depicts questions and answers with relevant rules identified for triggering.
Table 2

Feature Question Response Rule
Structure What function does the service perform? Content Management R26

Is the input in text form? Yes R9

Does input contain numbers? Yes R1

Does input contain images, media files? Yes R2
Application Type Is data likely to change? Yes R6

Is application transactional? No R5

Is data based on relationships? No R15

Is incoming data high volume? Yes R6

Is incoming data moderate velocity? Yes R16
Storage Retrieval Is data read intensive? Yes R1

For how long does the data need to be stored? Infinite R6

Is the data queried on single attribute? No R19

Is the data queried on multiple attributes? Yes R20

Analytics reports? No NA

Frequency of report generation? NA NA

Non-Functional Requirement Scalable in number of users (5 years)? Yes R1

Read Latency low moderate high? Yes R26

Write latency low or moderate or high? Yes R27

Data storage size? Large R6

Availability? High R25

Downtime tolerable? Moderate R20

Consistency? Tolerable R22
[045] For the sake of brevity, a simplistic scenario without too many constraints as shown above is considered and a meaningful use case is illustrated for better understanding of the decision tree based atomic rules triggering and generation of composite rules thereof for data store type(s) selection and recommendation. However, it is to be understood by a person having ordinary skill in the art that complex scenarios can be considered that require architecting (simple or complex) software applications. The questions (as comprised in the decision tree selected) are categorized using the taxonomy depicted in FIG. 1.
[046] As can be seen above, Table 2 illustrates information that is obtained from user(s) about the software application required for architecting (or software application under consideration for architecture). The questions have been structured to follow a specific format, in one embodiment of the present disclosure. The rules column implies specific rule that is fired/triggered corresponding to the question. Below Table 3 depicts relevant atomic rules identified and prioritized for triggering.
Table 3

Rule No Rules
R1 IF (data:input = number) THEN (data:type = STRUCTURED)
R2 IF (data:input = media; image; file) THEN (data:type = UNSTRUCTURED)
R3 IF (data:acid = N) THEN (data:store = NOSQL)
R4 IF (data:transaction = Y) THEN (data:store = SQL;RDBMS)

R5 IF (data:transaction = N) THEN (data:store = NOSQL)
R6 IF (data:volume = HIGH) THEN (data:store = NOSQL)
R7 IF (data:velocity = HIGH) THEN (data:store = NOSQL)
R8 IF (data:query = SIMPLE) THEN (data:store = NOSQL;RDBMS; SQL)
R9 IF (data:input = text) THEN (data:type = STRUCTURED;UNSTRUCTURED)
[047] It is to be understood by a person having ordinary skill in the art that only few atomic rules are described. However, in reality there could be as many atomic rules being identified and triggered, as the system 100 would attempt to explore (or explores) all aspects of the data store types at a primitive level. Atomic rules are generally never strongly conclusive. This is primarily because there can be multiple possibilities that fulfill the criteria of an atomic rule (e.g., R8). It is only in conjunction with other constraints that atomic rules provide conclusive results. This is achieved using composite rules outlined in below Table 4 discussed in the later sections.
[048] Based on the atomic rules for the given structure, it can be inferred that data is unstructured in nature. The questions in the AppType section identify if the application requires transactional support and if the data has high volume or is highly related. The inference based on the rules obtained here is that ‘Team Service’ component may not need a graph data store (since the data is not highly related), and the component may also not need an RDBMS (since the data does not require transactional support). In fact, rule R5, infers that a NoSQL data store is a good choice in such circumstances. Note that at this stage atomic rules are prioritized and triggered based on the user inputs. The Storage Retrieval column enables the system 100 to infer that the data is read intensive and that it is to be stored for an infinite amount of time. This implies that the data volume is high, and will also be queried on multiple attributes (which is specific to a document data store which enables querying on multiple attributes by enabling building of an index across multiple attributes). Finally, the NFR section reveals details about

the read latency, infers that if the data storage is small, medium or large based on the values provided by the users and the need for availability, tolerable downtime and consistency requirement. The above atomic rules generated are combined to generate and trigger composite rules subject to the constraints. More specifically, at step 210 of the present disclosure, the system 100 generates one or more composite rules using the set of prioritized atomic rules. Using the generated composite rules, the system 100 then dynamically selects one or more data store types from a plurality of data store types stored in the taxonomy (refer FIG. 1) comprised in the database 108 and recommends the same thereof. Each of the one or more data store types corresponds to one or more components (e.g., Team service and its sub-components, if any) of the software application, in the present disclosure. Below Table 4 depicts one or more composite rules generated using the prioritized set of atomic rules.

Table 4
Data Store Rules
IF (data:type = unstructured) AND (data:apptype = decentralized)
NoSQL AND (data:velocity = HIGH) AND (data:scalability = HIGH) AND (data:readlatency = LOW) AND (data:writelatency = LOW)
AND (data:query = simple) THEN (data:storetype = NOSQL)
IF (data:type = structured) AND (data:apptype = centralized)
AND (data:acid = Y) AND (data:transaction = Y) AND
RDBMS (data:velocity = MOD) AND (data:scalability = MODHIGH) AND (data:readlatency = LOW) AND
(data:writelatency = MOD) AND (data:query = complex) THEN
(data:storetype = RDBMS)
IF (data:storetype = NOSQL) AND (data:readheavy = Y) AND
Key Value (data:writeheavy = LOWMOD) ANDOR (data:singleattribretrival
= Y) THEN (data:store = KEY VALUE)
Document IF (data:storetype = NOSQL) AND (data:readheavy = Y) AND (data:writeheavy = Y) AND (data:multiattribretrival = Y) AND

(data:indexing = Y) THEN (data:store = DOCUMENT)
IF (data:storetype = NOSQL) AND (data:readheavy = Y) AND
Columnar (data:writeheavy = Y) AND (data:multicolumn = Y) AND
(data:volume = V LARGE) THEN (data:store = COLUMNAR)
[049] As can be seen from above Table 4, conditions that are satisfied are for Rule ‘NoSQL’ and Rule ‘Document’. So essentially, for the ‘Team service’ component, the decision tree based approach selects and recommends a NoSQL document data store type with a high likelihood based on the requirements of the user application. In the above Table 4, NoSQL is an intermediate composite rule that enables the rules, KeyValue, Document, Columnar in determining the specific type of NoSQL data store. These rules assist the composite rules in arriving at the final decision for determining a data store.
[050] In the above depicted Table 4, examples such as, key value store, or document store differ in attributes. For instance, for key value store - the data store type is NoSQL and this is more suited for readheavy applications as opposed to writeheavy applications. In the readheavy applications, queries may include what kind of data retrieval happens here? Is it a single attribute retrieval or a multiple attribute retrieval – does it support multiple attribute retrieval? Does indexing of data happens – yes or no. Based on this data store type (e.g., key value store or document store) can be selected and recommended. For instance, on a high level it can be said that data type is a NoSQL and it is readheavy application. In this case, both key value store and document store both could be probable answers. This may create confusion in solution architect’s mind. In reality, the deeper the questions are asked, both could be readheavy applications. On other hand, for writeheavy applications, key value store gives moderate or low performance and it only has single attribute retrieval versus if there is a need of multiple attribute retrieval or if data needs to be indexed then in that case this makes distinctly clear that a document data store type is the right choice.
[051] As mentioned above, solution architects are faced with a wide variety of options in order make a choice of the correct data store when

architecting a solution or a software application. With agile being a prominent business drive today, the turn-around time has drastically reduced. Additionally, the complexity of data in terms of volume and velocity and the need for providing SLA guarantees pose additional challenges when determining the right components that comprise a software architecture. Multiple types of data stores, all varying with each other to provide the desired feature set make this a non-trivial problem to address. Therefore, embodiments of the present disclosure provide systems and methods for selecting and recommending one or more data store types for software application architecture, wherein system 100 of the present disclosure builds a taxonomy (e.g., taxonomy of FIG. 1) and classifies different data store types (which is depicted in FIG. 1). The rule base is populated with rules which are triggered based on the application requirements specified by the user. The rules facilitate the decision making process of a software architect in making a choice of the data store component in the overall architecture.
[052] The written description describes the subject matter herein to enable any person skilled in the art to make and use the embodiments. The scope of the subject matter embodiments is defined by the claims and may include other modifications that occur to those skilled in the art. Such other modifications are intended to be within the scope of the claims if they have similar elements that do not differ from the literal language of the claims or if they include equivalent elements with insubstantial differences from the literal language of the claims.
[053] It is to be understood that the scope of the protection is extended to such a program and in addition to a computer-readable means having a message therein; such computer-readable storage means contain program-code means for implementation of one or more steps of the method, when the program runs on a server or mobile device or any suitable programmable device. The hardware device can be any kind of device which can be programmed including e.g. any kind of computer like a server or a personal computer, or the like, or any combination thereof. The device may also include means which could be e.g. hardware means like e.g. an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or a combination of hardware and software

means, e.g. an ASIC and an FPGA, or at least one microprocessor and at least one memory with software processing components located therein. Thus, the means can include both hardware means and software means. The method embodiments described herein could be implemented in hardware and software. The device may also include software means. Alternatively, the embodiments may be implemented on different hardware devices, e.g. using a plurality of CPUs.
[054] The embodiments herein can comprise hardware and software elements. The embodiments that are implemented in software include but are not limited to, firmware, resident software, microcode, etc. The functions performed by various components described herein may be implemented in other components or combinations of other components. For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that can comprise, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
[055] The illustrated steps are set out to explain the exemplary
embodiments shown, and it should be anticipated that ongoing technological
development will change the manner in which particular functions are performed.
These examples are presented herein for purposes of illustration, and not
limitation. Further, the boundaries of the functional building blocks have been
arbitrarily defined herein for the convenience of the description. Alternative
boundaries can be defined so long as the specified functions and relationships
thereof are appropriately performed. Alternatives (including equivalents,
extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope of the disclosed embodiments. Also, the words “comprising,” “having,” “containing,” and “including,” and other similar forms are intended to be equivalent in meaning and be open ended in that an item or items following any one of these words is not meant to be an exhaustive listing of such item or items, or meant to be limited to only the listed item or items. It must also be noted that as used herein and in the appended claims, the singular

forms “a,” “an,” and “the” include plural references unless the context clearly dictates otherwise.
[056] Furthermore, one or more computer-readable storage media may be utilized in implementing embodiments consistent with the present disclosure. A computer-readable storage medium refers to any type of physical memory on which information or data readable by a processor may be stored. Thus, a computer-readable storage medium may store instructions for execution by one or more processors, including instructions for causing the processor(s) to perform steps or stages consistent with the embodiments described herein. The term “computer-readable medium” should be understood to include tangible items and exclude carrier waves and transient signals, i.e., be non-transitory. Examples include random access memory (RAM), read-only memory (ROM), volatile memory, nonvolatile memory, hard drives, CD ROMs, DVDs, flash drives, disks, and any other known physical storage media.
[057] It is intended that the disclosure and examples be considered as exemplary only, with a true scope of disclosed embodiments being indicated by the following claims.

WE CLAIM:
1. A processor implemented method, comprising:
receiving an input request from a user (202), wherein the input request is specific to architecting a software application specific to a domain;
selecting a pre-defined decision tree amongst a plurality of decision trees stored in a database based on the input request, each node in the selected pre-defined decision tree comprises a pre-defined query (204), wherein the plurality of decision trees are constructed using a plurality a questions comprised in a question bank, wherein the question bank comprises questions corresponding to one or more domains, and wherein the plurality of questions in the plurality of decision trees are based on functional and non-functional features of a particular domain;
sequentially traversing through one or more nodes in the selected pre-defined decision tree based on a response received for a corresponding query at each node (206);
automatically triggering a set of prioritized atomic rules stored in the database based on one or more sequential responses received for each query of the one or more nodes sequentially traversed (208);
generating one or more composite rules using the set of prioritized atomic rules (210); and
dynamically selecting, based on the one or more composite rules, a set of data store types from a plurality of data store types stored in a taxonomy comprised in the database and recommending thereof (212), wherein each of the plurality of data store types corresponds to one or more components of the software application.
2. The processor implemented method of claim 1, wherein the plurality of
data store types is based on one or more properties of the one or more components
of the software application.

3. The processor implemented method of claim 2, wherein the one or more properties comprise at least one of functional features, and non-functional features.
4. The processor implemented method of claim 1, wherein the one or more composite rules are a combination of two or more atomic rules.
5. The processor implemented method of claim 1, wherein each of the plurality of data stores types is classified into a decision table using a taxonomy tree based on associated functional or non-functional features.
6. A system (100), comprising:
a memory (102) storing instructions;
one or more communication interfaces (106); and
one or more hardware processors (104) coupled to the memory (102) via the one or more communication interfaces (106), wherein the one or more hardware processors (104) are configured by the instructions to:
receive an input request from a user, wherein the input request is specific to architecting a software application specific to a domain;
select a pre-defined decision tree amongst a plurality of decision trees stored in a database based on the input request, each node in the selected pre-defined decision tree comprises a pre-defined query, wherein the plurality of decision trees are constructed using a plurality a questions comprised in a question bank, wherein the question bank comprises questions corresponding to one or more domains, and wherein the plurality of questions in the plurality of decision trees are based on functional and non-functional features of a particular domain;
sequentially traverse through one or more nodes in the selected pre-defined decision tree based on a response received for a corresponding query at each node;

automatically trigger a set of prioritized atomic rules stored in the database based on one or more sequential responses received for each query of the one or more nodes sequentially traversed;
generate one or more composite rules using the set of prioritized atomic rules; and
dynamically select, based on the one or more composite rules, a set of data store types from a plurality of data store types stored in a taxonomy comprised in the database and recommend thereof, wherein each of the plurality of data store types corresponds to one or more components of the software application.
7. The system of claim 6, wherein the plurality of data store types is based on one or more properties of the one or more components of the software application.
8. The system of claim 7, wherein the one or more properties comprise at least one of functional features, and non-functional features.
9. The system of claim 6, wherein the one or more composite rules are a combination of two or more atomic rules.
10. The system of claim 6, wherein each of the plurality of data stores types is classified into a decision table using a taxonomy tree based on associated functional or non-functional features.