Patent Application
20150026660
This application claims priority to Indian patent application no. 846/KOL/2013, filed on 16 Jul. 2013, the entire contents of which are herein incorporated herein by reference.
Certain example embodiments described herein relate to techniques for leveraging application intelligence. More particularly, certain example embodiments described herein relate to gathering information about an application, e.g., to generate interaction patterns that may help to identify data relevant to decision-making, reason about a user's intended actions, generate inference documents that capture the user's intentions, etc. Certain example embodiments additionally or alternatively apply a “who”, “what”, “when”, “where”, “how”, and/or “why” approach to event auditing.
A simple Event Driven Application is one that responds to actions generated by the user or the system. Event Driven Applications can perform a predetermined sequence of actions depending, for example, on a sequence of actions and/or events with which they are presented. Simple examples of Event Driven Applications include vending machines that dispense products when the proper combination of coins is deposited, combination locks that require the input of combination numbers in the proper order, etc. Although these examples are simple, it is known that Event Driven Applications can model a large number of potentially complex problems such as, for example, electronic design automation, communication protocol design, language parsing, engineering applications, and/or the like.
It will be appreciated that in a good Service-Oriented Architecture (SOA) Governance solution, the careful development of services/applications may help to determine the value it adds to the business. Unfortunately, however, the development and evolution of the services are determined by a series of lifecycle states and events that are difficult to track and/or monitor, thus making it difficult to provide useful information to application/service developers and/or other interested stakeholders.
For example, recording of the evolution of applications and what happens as such applications go through multiple states/events during development and as they are used when actually deployed, can impose potentially significant requirements, e.g., when it comes to gathering data relevant to analyzing and understanding the important design decisions made throughout its evolution, as well as for application maintenance and anomaly resolution during development and deployed use.
The inventors have also realized that additional or alternative benefits could be derived from careful recording of the interactions with the aforementioned applications, e.g., based on observed and/or adduced interaction patterns. Interaction patterns can, for example, be studied to build intelligent applications that can automatically or at least semi-automatically determine new application workflows based on previous interactions that it had with the particular user. Examples of such changed flows may include, for example, dynamically changing a GUI according to analysis of human interaction patterns. Building a dynamic system, e.g., where less frequently used parts of an application filtered and user-preferred flows are at least initially shown, may reduce the number of “clicks” performed on a GUI and thus may improve the efficiency of the interactions, while creating a more natural feeling and easier to use application. Unfortunately, however, it oftentimes is difficult to gather this information, as well, and it therefore is difficult to enable solutions of these sorts.
Although some current attempts to have been made to use event driven auditing to build “audit logs” or the like, such techniques stop short of actually interpreting those logs to build intelligent systems. And although some tools have been developed for processing audit logs to collect and analyze the events so as to determine further courses of actions (e.g., like raising an alarm in monitoring systems, etc.), such approaches likewise stop short of actually instilling intelligence into applications, e.g., based on the events and logs.
Thus, it will be appreciated by those skilled in the art that it would be desirable to overcome these and/or other problems. For example, it will be appreciated that it would be desirable to build application intelligence on Event Driven Applications by effective recording of application evolution and usage.
One aspect of certain example embodiments relates to effective recording of application evolution and usage for usage learning and/or event auditing purposes. With respect to usage learning, certain example embodiments may help to capture data on the usage patterns and/or apply learning algorithms that work on the captured data to provide required intelligence to the application. With respect to event auditing, certain example embodiments may help to identify the “who”, “what”, “when”, “where”, “how”, and/or “why” of particular operations, e.g., to respectively identify for a given operation or combination of operations the user who is performing the particular operation on the application; what operation is being performed by the user on the application; the time at which the operation is being performed; the physical location at which the operation is performed; how the operation is performed (e.g., manually, automatically, some combination thereof, etc.); and the reason(s) behind the operation.
Another aspect of certain example embodiments relates to using application intelligence to determine application “hotspots” or commonly used features (including those that are most common) that help in areas such as application maintenance, performance tuning, and/or the like.
Another aspect of certain example embodiments relates to using application intelligence to equip an application with knowledge about different users' usage patterns, e.g., so that the application can present different workflows tailored for different users for the same application.
In certain example embodiments, an application intelligence gathering method for use with an application hosted by a computer system is provided. Artifacts are received from a computer readable storage medium, with the artifacts representing data gathered during execution of the application and relating to events that occur during the execution. Using a computer processor, interaction patterns associated with the events are identified. Inference documents are generated in connection with the identified interaction patterns using the computer processor. The inference documents include, for each said event, an indication as to whether that event is mandatory or optional and one or more reasoned statements concerning the user's intentions for that event. Using the computer processor, at least one custom application workflow is generated based on the generated inference documents. The at least one custom application is transformable into a new application workflow that is deployable into the application.
In certain example embodiments, there is provided a non-transitory computer readable storage medium tangible storing instructions that, when performed, gather application intelligence on an application hosted by a computer system, by executing instructions to at least: receive artifacts from a computer readable storage medium, the artifacts representing data gathered during execution of the application and relating to events that occur during the execution; identify interaction patterns associated with the events; generate inference documents in connection with the identified interaction patterns, the inference documents including, for each said event, an indication as to whether that event is mandatory or optional and one or more reasoned statements concerning the user's intentions for that event; and generate at least one custom application workflow based on the generated inference documents, the at least one custom application workflow being different from default application workflows. The at least one custom application is transformable into a new application workflow that is deployable into the application.
In certain example embodiments, a computer system for gathering application intelligence on an application is provided. Processing resources include at least one processor and a memory. A computer readable storage medium tangibly stores data gathered during execution of the application and relating to events that occur during the execution. At least some of the processing resources are configured to at least: identify interaction patterns associated with the events, using the computer readable storage medium; generate inference documents in connection with the identified interaction patterns, the inference documents including, for each said event, an indication as to whether that event is mandatory or optional and one or more reasoned statements concerning the user's intentions for that event; and generate at least one custom application workflow based on the generated inference documents, the at least one custom application workflow potentially being different from default application workflows. The at least one custom application is transformable into a new application workflow that is deployable into the application. The data gathered during execution of the application indicates, for each said event, what kind of event was performed, why the event happened, who was responsible for triggering the event, when the event happened, where the event happened, and how the event was triggered, as appropriate for the respective event.
These features, aspects, advantages, and example embodiments may be used separately and/or applied in various combinations and sub-combinations to achieve yet further embodiments of this invention.
These and other features and advantages may be better and more completely understood by reference to the following detailed description of exemplary illustrative embodiments in conjunction with the drawings, of which:
Certain example embodiments relate to use effective logging as a means for building application intelligence into systems. As explained in greater detail below, interaction patterns may be analyzed and/or inference documents may be generated, e.g., to aid in identifying data that helps in decision-making and to reason about a user's intended actions, and to build self-evolving systems, respectively. In certain example embodiments, heat maps may be generated to determine “hotspots” (e.g., within a critical path) in the system that can be performance-tuned when applying changes. Heat maps additionally or alternatively can be generated to facilitate the development of custom workflows and primary step identification to determine critical paths for testing changes to a system.
Certain example embodiments work on the principle that, in a computer interaction, a next set of actions undertaken by a human user and/or the computer system itself generally will be based at least in part on the interactions that happened in the previous step(s) and data collected from the previous step(s). This relationship implies that the data is key to the decision-making
In a related vein, certain example embodiments provide systems and/or methods that have the ability to reason about and/or understand the user's actions in the current state in relation to the “decision data” collected from one or more previous steps and thus can infer the rationale behind such actions. This ability of certain example embodiments helps to drive the learning that enables applications and/or their systems to evolve on their own.
Referring now more particularly to the drawings,
When events are captured, annotations can be added, e.g., to identify general transitions (e.g., common or repeated transitions or workflows), to associate comments with the events and/or event transition data, etc. For example, annotations can be added to identify the user's common workflows (e.g., preferred workflows) in certain example embodiments. These annotated workflows can also be presented to the user as “favorites.” Example annotations vis-à-vis the ATM example provided below may include, for example, Cash_Withdrawal—2000_With_PrintBalance and Cash_Withdrawal_With_PrintBalance. In addition to the workflows, logical groups (e.g., like 1000_Withdrawl (e.g., an action that involves Selecting Cash Withdrawl->Select Denomination->Confirmation) explained in greater detail below) can also be annotated for reuse, which can be directly integrated into custom generated workflows. The artifacts may be stored to a suitable storage location 106 (e.g., a non-transitory computer readable storage medium that is local to the system, accessible over the network, etc.). Any annotations also can be stored to the storage location 106, and the artifacts may be associated with annotations, when and as appropriate.
With the “Recorded Artifacts” in the storage location 106, the parser 108 will analyze these recordings to identify the interaction patterns between the user and the system in step S110, e.g., in cooperation with processing resources such as a processor and a memory. The interaction patterns analysis process my help to form logical groupings of sequences of events. These groupings may be based on parameters such as, for example, why the event was triggered, when it happened, and/or the like. Additional or alternative parameters outside of the “who”, “what”, “when”, “where”, “how”, and/or “why” paradigm may be used, in certain example embodiments.
Inference documents may be generated in step S112, e.g., to help capture the “intentions” behind the user's actions in each and every state in an application workflow. Using the interference documents, the parser 108 may generate a draft workflow of the recorded scenario in step S114, with these logical groupings being the steps/states in the workflow. This workflow will then be annotated to generalize the transactions. The resulting annotated workflow may be thought or as representing the “User Preferred” application flow. When multiple workflows are generated, they may be ranked and annotated in step S116.
When a certain threshold is met (e.g., when a given workflow is generated a predetermined number of times for the same or different users, etc.) and optionally when manually approved, a new application workflow may be generated and optionally deployed into the application in step S118. The custom workflows can also be used to determine the application hotspots in the system in step S120 and, as alluded to above, these hotspots and their related heat maps that can help in application maintenance and/or performance tuning
The following sections help elaborate on the description provided above in connection with
As indicated above,
Having described the initial
As discussed above, the effective recording attempts to log possible interactions (e.g., each and every possible interaction) between the user and the application. This may involve capturing event transition data that answers questions such as, for example, “What kind of event was performed”, “Why did it happen”, “Who is responsible for triggering the event”, “When did the event happen”, “Where did it happen”, “What data was passed between the user and the system”, “How was the event triggered”, etc.
Assume for the purposes of this ATM example that a customer named John goes to the ATM and withdraws money on the 1st, 11th, and 21st of Jan. 2013. Each of these transactions may be slightly different from the earlier ones. Assume further that each transaction is performed in accordance with the illustrative scenarios in Table 1, below:
Tables 2-4 below respectively show the details recorded for the three transactions.
These records will then be picked up by the parser to analyze interaction patterns.
As discussed above, usage learning involves gathering that aids in decision-making Thus, certain example embodiments strive to effectively collect the “critical data” during application/system execution. Execution may in general comprise a set of executable steps, and each executable step may involve an interaction with the user or other system. Thus, it may in some case be useful to understand interaction patterns.
In human-computer interactions, or in two-way conversations in general, the type of interactions could be broadly classified as one party providing information to the other, one party seeking information from the other, and one party asking the other party to perform an action. These interactions may be referred to as assertion patterns, information solicitation, and actionable patterns, respectively.
Certain example embodiments involve combining these interactions in a particular order. For example, a very simple calculator service that helps performing the addition of two integers could be defined as, for example:
The resultant data may then serve any purpose such as, for example, assisting with or even controlling decision-making, providing input to a next set of actions, etc. Thus, it will be appreciated that it would be desirable to analyze interaction patterns based on the recordings and knowledge about the system, e.g., to obtain decision-making related data and reason about an intended action.
Referring once again to the ATM example and the scenarios contemplated above, an analysis of the logs may result in the generation of the following report shown in Table 5, below.
This report, along with the recordings, will now be parsed to generate inference documents.
Inference Documents help capture the intentions behind users' actions in the states in an application workflow. This is done by reasoning about the users' actions in connection with a decision data set. The inference documents may be generated for every single transaction between the user and the system in certain example embodiments.
The inference document that is generated may include information indicating whether a state/event is mandatory, and the user's intentions behind an action. With respect to the former, an indication that a state/event is mandatory may mean that the user performed the related action because of the application flow and not because the user actually wanted to do so. Reasoning about whether an event/action type is mandatory or optional may be based on the following and/or other rules:
The tables in
Custom workflows may be generated for some or all transactions between the user and the system. The custom workflow may help capture the user's preferred application workflow, rather than the default application flow, and they may be generated based at least in part on the inference documents discussed above.
Custom workflow generation may involve filtering out mandatory steps and identifying primary steps.
In
The primary steps may be used to form an action group, with each action group grouping together a primary step and all of the states prior to that primary step. In the above example, Cash Withdrawal will become the first primary step and, thus, all of the steps executed before that will become a subset of the Cash Withdrawal step. The custom workflows shown in
As indicated above, it is possible in certain example embodiments to rank custom workflows in order to identify a user's most preferred application workflow. This may be performed in certain example embodiments by calculating the execution frequency of each of the states in the custom workflows. Table 6 below shows the ranking for the example transactions discussed above. A ranking may also be performed for the actions/data for a given state itself. For example, Table 7 below ranks the actions in the Cash Withdrawal state.
Based on these rankings, a user's preferred application workflow may be generated.
As alluded to above, a physical location parameter could analogously aid in presenting a most preferred workflow, depending on geographical location. Other parameters may similarly be used.
Annotating the workflows may be performed to help identify users' common workflows Annotated workflows in certain example embodiments can also be presented to the user as favorites and may be accessible wherever the application is used in some instances. For instance, for the ATM example discussed above, annotated workflows may be stored such that these favorites are available to the user from any ATM (and not just the ATM of the bank they bank with), e.g., by being stored on the ATM card or being accessible from a central store when an authenticated session is started.
Different possible annotations for the above transactions may include, for example:
A sample execution flow for the Cash Withdrawal 2000 With Print Balance annotation is as follows:
A sample execution flow for the Cash Withdrawal With Print Balance annotation is as follows:
In addition to generating the user's most preferred workflow, the custom workflow generation and/or primary step identification techniques can be performed over time anonymously and/or in a non-user specific manner to help build a “heat map.” The heat map may help to identify details regarding the steps most often used (e.g., revealing user-based critical paths) in the production system. Reports can be generated based on these details and, when provided to the application developers, the reports can help in maintaining applications over multiple versions and also in resolving anomalies. More particularly, heat maps may help to identify narrower hotspots, e.g., to aid in performance-tuning hotspots within a critical path, ensuring performance of the critical paths is at least as good as previous versions (even after changes are made to the system), prioritizing the tests to take advantage of the critical paths collected to help guard against “fixes” causing regressions, etc.
In the ATM example, based on the primary steps identified and the execution frequencies provided above, it may be determined that the steps such as Cash Withdrawal and Print Balance are “hotspots” in the application. These hotspots will be collected, and reported to the application developers.
It will be appreciated that the various documents, workflows, etc., may be stored to a non-transitory computer readable storage medium in certain example embodiments, e.g., to facilitate processing, provide authorized persons (e.g., developers) a chance to review such items prior to proceeding with the next steps (such as, for example, new workflow deployment), etc.
Although certain example embodiments have been described as relating to applying inference techniques to application events, it is noted that the example techniques described herein may be used to take into account system and/or external events in addition to, or in place of, application events. As alluded to above, it may be advantageous to take into account geospatial events (e.g., location information identifying where an interaction is originating from and/or interacting to). Similarly, the collection of device and network level events alone and/or combined with human-to-application interaction sets may be taken into account in certain example embodiments.
As a further example, more user behavior may be taken into account by examining locations where the application is used, the time of day used, the frequency the same user interacts with the system and/or application, the device or device type the user uses to interact with the system, a browser or browser type, etc. For instance, in the ATM interaction scenarios described above, it may be desirable to infer patterns based on the locations of ATM machines used, the time of day used, the frequency the same user interacts with a banking system from a mobile device and/or a web browser, etc. It thus will be appreciated that determining a user's preferred workflow may extend beyond a specific application's context.
The example techniques set forth herein may be use to build a system that can generate an “autobiography” based on the recordings. That is, certain example embodiments can help generate an application autobiography that is, in essence, a form of enhanced and well-formatted logging. These autobiographies can be customized in terms of what content is gathered and how it is processed and subsequently presented based on, for example, the target audience. This also may help to in a way redefine the way logging is performed, e.g., by providing techniques that in certain example instances enable the capturing of a complete or “360 degree” perspective of logging wherein all the aspects (e.g., what, why, how, when, who, etc.) of the log are captured and meaningful content is derived, as opposed to traditional logging where the logs are basically stale content generated out of events. Similarly, in certain example embodiments, the conventional approach of looking at a log as being static content with a predefined formatted structure can be changed, and a more human readable system generated autobiography of the logs can be presented in a template of user's choice.
Although certain example embodiments have been described in connection with Event Driven Applications and, thus, Event Driven Architectures or EDA, it will be appreciated that the example techniques set forth herein are not limited to such applications and/or architectures. For instance, the example techniques associated with the building of inference documents for generating “self-evolving” systems has broader implications and can be used in different types of applications and/or computer architectures. More particularly, although the example embodiments described above discuss instilling self-learning capabilities to Event Driven Application, it will be appreciated that the example techniques described herein may be generalized and applied to any kind of applications and/or systems that could benefit from logging as a means to building application intelligence into such systems and/or inferring intended user's actions by identifying data (that helps in decision-making and/or other tasks) and by generating inference documents for building self-evolving systems.
It will be appreciated that as used herein, the terms system, subsystem, service, engine, module, programmed logic circuitry, and the like may be implemented as any suitable combination of software, hardware, firmware, and/or the like. It also will be appreciated that the storage locations herein may be any suitable combination of disk drive devices, memory locations, solid state drives, CD-ROMs, DVDs, tape backups, storage area network (SAN) systems, and/or any other appropriate tangible non-transitory computer readable storage medium. Cloud and/or distributed storage (e.g., using file sharing means), for instance, also may be used in certain example embodiments. It also will be appreciated that the techniques described herein may be accomplished by having at least one processor execute instructions that may be tangibly stored on a non-transitory computer readable storage medium.
While the invention has been described in connection with what is presently considered to be the most practical and preferred embodiment, it is to be understood that the invention is not to be limited to the disclosed embodiment, but on the contrary, is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.
| Number | Date | Country | Kind |
|---|---|---|---|
| 846/KOL/2013 | Jul 2013 | IN | national |
