Integration has become more like corporate encroachment and demands due-diligence to be the main ingredient in planning for IT systems (Ness Global Industries, 2010). Gathibandhe, Deogirikar and Gupta (2010) describe two integration types in business IT as: application integration and data integration. The former being the establishment of communication channels between applications for smoother business process flow, and the latter dealing specifically with combining enterprise data at the back-end level (Gathibandhe et al. 2010;Gravic, Inc., 2010). In enterprise application integration (EAI), applications should establish a common language to communicate with one another (Gravic, Inc., 2010). Meaning, all applications should have adaptable interfaces to communicate intelligibly in fulfilling tactical contracts with the entire communication system.
Integration is essential for RTBI since tactical resolutions detected in the BPM layer may instigate inquiry into more than one application, even worse if an urgent-response is ineluctable towards resolving a calling business event. However, Gravic, Inc. (2010) discourages reliance on EAI for RTBI. Stated as reasons are the inefficacy, invasiveness and unreliability that might result from linking up an EAI infrastructure with the RTRR layer of RTBI. That is, inter-application communication might be a source of response delay – due to inter-application data routing that needs to happen during transaction processing, therefore, non-conducive for RTBI which should boasts real-time organizational snapshots at any given moment. Again, intrusion done to live applications that are already engaged in other processing activities might weigh on database performance. Lastly, inter-application connectivity might mean that the collapse of one application in the network, breaks the entire communication system. However, it is all not lost as there is still enterprise data integration (EDI).
EDI is based on triggers that constantly load data into auditing structures (Gravic, Inc., 2010). Applications carry on as normal, but the generated data is also loaded (in addition to the normal application data structures) into data structures that serve as integration havens for organizational information systems. These structures must be designed such that essential data is constantly loaded as it is generated from all the online applications within an organization (Gathibandhe et al. 2010). There is no need for applications to talk to each other during transaction processing as the database enables data sharing from all enterprise applications via back-end channels. What EDI means is basically online ETL, that is, push all data changes into auditing structures, which might be direct replicas of fed data structures residing in a data warehouse. From these audit-like structures, mini batches can be performed to load the data into the data warehouse (Gathibandhe et al., 2010). Also, the RTRR layer can use these online-resident structures for urgent interrogation because of their miniscule nature (also implying increased response speed) – a process called federation. Figure 3 depicts this discussion in a diagram for clarity. This is also how an RTBI solution gains both its tactical and strategic capabilities. The gradual feeding of data into a data warehouse enables long-term strategic planning, while the agility towards new data incorporation into the data analysis process, enables tactical resolutions. Again, although this approach looks enticing, an elixir to corporate decision making, it has its own drawbacks. Olofson (2009) mentions real time data synchronization as one of the issues impacting on efficient decision making from decision systems. Data synchronization is relevant with EDI, because it is at this point that cross-application record similarity matters. An enterprise might identify the same customer, service or product differently in its disparate systems. Thus putting the burden to match overlapping information to run-time processing can be an unwieldy and unwise a exercise, even futile for that matter.
However, Olofson (2009) proposes the need for master data management (MDM) to be a priority in planning for enterprise information architecture. He further describes it as the creation of a single view of the lowest granule of enterprise records – see relevant material for MDM discussions as it is not the intention of this study to elaborate on it. It is thus proposed in this discussion that MDM has to precede EDI for an organization to see good returns on its investment on the RTBI solution.
Again from figure 3, a change log engine is also depicted, its purpose is to load into data structures fresh changes from on-line systems in a format that is similar to the one adopted by supersets residing in the data warehouse. Therefore, the only function of the ETL process is pushing new and latest changes into the data warehouse, and not heavy loads of transactional records like is the case with traditional BI soulutions.
Figure 3. RTBI - Operational LayerReferences:
1. Ness Global Industries (2010). From expected to achieved: four steps to making business intelligence work. http://www.cio.com/white-paper/595797/From_Expected_to_Achieved_Four_Steps_to_Making_Business_Intelligence_Work (Accessed 10 July 2010).
2. Olofson, C.W. (2009). Maximizing opportunity and minimizing risk through enterprise data integration: strategies for success in uncertain times. http://vip.informatica.com/?elqPURLPage=5453 (Accessed 10 July 2010).
3. Gathibandhe, H., Deogirikar, S. and Gupta, A.K. (2010). How smart is Real-Time BI? Available from: http://www.information-management.com/infodirect/2009_152/real_time_business_intelligence-10017057-1.html?pg=1 (Accessed 14 June 2010).
4. Gravic, Inc. (2010). The evolution of real-time business intelligence. Available from: http://www.gravic.com/shadowbase/whitepapers.html (Accessed 24 May 2010)
No comments:
Post a Comment