Introduction
The big-data stream has taken off in to many core implementations recently. Most of these attempts are based on a heavy-duty data crunching, ‘passes’ for analysis and extraction of inferences. As the outcome of this activity, the business user makes certain inferences on the model that he/she is working on.
The conventional systems looked at an aggregated, pattern-based analysis where querying on an accumulate data storage was the primary activity. Trend in business intelligence (BI) suggest correlating purely un-related data that creates disruptive predictions that help improve business. The ‘data judiciary’ elaborates on a new way of looking at this big-data problem. The center-stone for this perspective is the root level data element itself.
The basic tenet of data judiciary is that the individual data elements – be it a file in a windows file folder, a database table row, a sensor reading, an email – make sense and their relevance and ability to help in making predictions need to be counted on. It is a bottom-up approach, compared to the top-down conventional big-data approach that considers subset of data and a huge analysis exercise.
The relevance of the individual data element is determined appropriately by a ‘data advocate’. It is a system automation subset that takes a set of laws and rules and represents the data towards upward consideration. The data advocate prepares a set of ‘case claims’. Case claims are streamed events that contain data context and the rule/law context for further considerations.
The next level activity is at ‘data court’ where the case claims are considered for fitment. These are done by the individual courts taking the laws and rules for processing these claims. The data court produces ‘Judgments’ as the outcome and a repository of these judgments help in the historical aspects of any BI requirements.
Data judiciary
The 'Data Judiciary' is a big-data problem solving framework. The framework changes paradiagm as it is centered on data elements which are in transit, by standing by them for their journey to make sense. Data elements have their own case, we need to sense it!
Implementation
The data advocates are system subset that has the below inputs.
The data advocates can perform the following:
Example:
An add-in for Microsoft Outlook interferes with the emails retrieved offline. The add-in is a data advocate. The add-in retrieves certain laws and rules from a potential central agency. One of such laws can be “A data item should directly be measured on its human interactions”. This law will lead to a rule “An email should be measured by the duration it is open in an email client”. The add-in compiles this information for a period (controlled or uncontrolled) and submits a case claim in a pre-defined XML format. A data court that is residing in an email server (Microsoft Exchange) processes all such case claims from its associated Outlook clients and forwards to the Judgment repository.
A BI user can then perform what-if analysis on the law “Human Interaction” that includes emails (through the process explained here), file folders, application screens, devices, order software, security systems, etc. The advantage of data advocates is that for each of the laws, the appropriate interpretations (implementations) can be done by advocates for different set of data elements. E.g.:- Outlook Add-in for emails, Oracle extensions for relational database queries, Windows event handlers for files in a file folder, JavaScript libraries for EMC content management systems.
Central/nodal agencies & integration layer
The laws and rules need broadcasting to the advocate systems and court systems. This can be implemented in an optional central controlling system (similar to the token authority in claims based authentication systems). It is envisaged to be optional since the laws and rules could be fixed in certain situations – especially in modeling decisions around real-time machine readings.
In situations where multiple advocates, courts and judgment context exist – for example, enterprise business intelligence – an integration layer can be implemented to facilitate the event streaming. These streams associate with case claims and judgments.
Intra-advocates/court communications
It is possible through a standardized schema to set up advocate-to-advocate and court-to-court interactions. These enhance judgment capabilities compiling heterogeneous judgment interpretations. This interaction helps distributing the interpretations at multiple levels thereby reducing the judgment bank burden and also by facilitating judgment inferences – that may be quick and crisp based on the laws and rules in consideration.
APP store for data advocates
The distribution of advocates’ work is the main characteristics of data judiciary, while taking in to account the laws and rules that the end user is performing analysis on. In an enterprise multiple systems, technologies and messages exist. This calls for an advocate store – an application store that can be subscribed by functional systems. For example, an Outlook advocate can be an app hosted and subscribed on demand. Similarly, for content management systems an extension advocate – possibly using a server managed extension or thick client add-on – can create the case claims event streaming.
Data judiciary on Cloud
The Cloud repository and computing engines are more relevant for laws, rules and judgment bank. Some of the courts also qualify for deployment on to a Cloud location. The courts in Cloud require compute capabilities on top of storage, environment or platforms.
In advocate-to-advocate or court-to-court communications, asynchronous methods can be employed. Also these communications resemble the torrent principles for peer to peer communications.
Walkthrough example
The scenario described in this example is of a US$6B enterprise who takes outsourcing orders. The CEO is seeking a report on the relationship between customer satisfaction indices and internet traffic volume towards social media web sites from corporate network and BYOD devices. The CEO is also looking at potential employee behaviors that influence the customer satisfaction.
The BI team sets up some laws and rules for performing this analysis.
The BI team configures a central repository using Microsoft SharePoint to store the laws, rules and judgments.
The IS team is asked to set up the necessary infrastructure and software for advocates and courts. They set up the below data advocates.
The BI team configures a central repository using Microsoft SharePoint to store the laws, rules and judgments.
The IS team is asked to set up the necessary infrastructure and software for advocates and courts. They set up the below data advocates.
A set of data courts were set up as enlisted below
Server that accepted case claims from all desktops and email advocates
A SAP data court that accepted all case claims from SAP
An offline asynchronous court in central Microsoft SharePoint that accepted judgment interpretations from the SAP data court, CRM and knowledge portal.
By this set up the BI team were able to identify potential parameters accurately derived. This set up is more or less a permanent one that remains in the environment. Specific advantage of this set up is the ability to take care the data in transit such as internet access patters from a corporate desktop and a tablet device under BYOD scheme for the same employee. Another advantage is that a central repository of all the data for multiple cycles of analysis is not required as the workload is distributed to the courts and advocates. Also, by changing the laws and rules of the situations, the courts and advocates behave appropriately.
The extra burden of setting up the advocates and courts are the disadvantages of this system. Also the BI interface for what-if analysis is not in the purview of this system.
For more information, you can reach out to global.consulting@wipro.com
Praveen Kodikkambrath is a Practice Head and Principal Architect with Microsoft Practice, Business Application Services, at Wipro Limited. He brings with him, 18+ years of experience in development, consulting, delivery, sales & pre-sales, go-to-market activities, CxO and Analyst interactions, innovation and marketing.
His area of expertise has been Application Estate Transformation. He has built transformation services to scale, including management of services & strategy, customer accounts, solutions development, delivery and management of associated people structures.
At Wipro, Praveen handles two practices - Modern Microsoft Applications and Application Remediation and GTM for. NET and BizTalk business. In his current role, he has pioneered a productized solution that addresses all transformation requirements across Microsoft technologies (SharePoint, BizTalk, Dynamics, and Azure). He has also been instrumental in driving key top-25 accounts as part of his practice management responsibilities.
© 2021 Wipro Limited |
|
© 2021 Wipro Limited |
Engineering, Construction & Operations
Pharmaceutical & Life Sciences