Unified Information Access, Step by Step
In many shops, the dream of unified information access remains elusive. An industry expert offers well-honed tips.
- By Stephen Swoyer
- April 29, 2009
For many organizations, the Big Question with respect to unified information access (UIA) isn't "How can I get there from here?" but "Can I get there from here?"
The benefits of UIA -- which proponents say include improved analytic insight and enhanced usability (along with the cost-of-ownership benefits that are expected of any consolidation or standardization effort) -- seem clear. How to realize UIA is another matter.
Business intelligence (BI) and data warehousing (DW) veteran Seth Grimes, a principal with BI and DW integrator Alta Plana, favors a phased approach. Grimes is an expert in text analytics and unstructured information access and knows whereof he speaks. What's more, the prescriptions Grimes outlines in a recent whitepaper, Unified Information Access: Gain Active Intelligence from Content and Data, seem both reasonable and practicable.
At a basic level, UIA doesn't have to be an extremely costly -- much less an extremely onerous -- proposition. Would-be adopters can get started merely by creating a one-to-many portal front-end.
"The most basic approach to unifying data from multiple sources is via a thematically or functionally unified portal or dashboard ("mash-up"). Information from each source is conveyed in a separate display element. The user interacts with each element separately," he writes. "Next up the ladder would be some form of federation, where the user is presented with assembled responses to a single query that has been sent to multiple information sources. So-called meta-search engines are an example of federated query. There's no true integration of the data, no cross-source analysis."
The next step, Grimes counsels, is to engineer unified access at multiple levels: not just in the UI (via a portal or a data federation console) but at the query and data levels, too. This is trickier, he concedes, in part because it requires a couple of additional permutations. First, that adopters construct a universal index containing all of the data and relationships harvested from their data and content sources. Second, that they contrive to deliver support for programmable analytic workflows.
In this respect, Grimes advises, buying an enterprise or consumer search tool just isn't enough. "Enterprise and consumer search do of course rely on indexes, and some engines do have back-end rules-processing for specialized treatment of certain types of information. They do not have significant workflow capabilities, however, or anything equivalent -- for unstructured sources -- to the data integration, transformation, analysis, and dissemination steps that underlie enterprise BI," he points out.
Building in workflow features helps to ensure both the quality and the manageability of your UIA infrastructure, Grimes stresses. "Workflows are necessary for data cleansing [such as de-duplication] and integration purposes and for handling the diverse file types encountered in unstructured content."
This is putting the cart before the horse, of course. As a "Stage 0," so to speak, would-be adopters should first determine how UIA can help them, chiefly by performing a gap analysis to identify business pain points or other burgeoning issues that could relate to information access. Knowing where and why they hurt will help them better tailor their UIA prescription to address critical business needs.
Among other benefits, Grimes says, a well-oiled UIA infrastructure should help streamline business operations and increase efficiency; enhance customer management; improve decision making; and prove to be a boon to compliance or regulatory efforts.
Once they've done a gap analysis, would-be adopters can move on to Step 0.5 -- an evaluation or proof-of-concept (PoC) of a prospective UIA solution. In the evaluation phase, organizations should focus on the accuracy of results (e.g., the ability of a proposed solution to handle typical queries and joins); the degree to which any solution's analysis component really is unified (e.g., does it include text mining and linguistic, along with numerical and aggregate, capabilities); the way results are presented (focusing on customizability as well as filtering and calculative features); the usability and customizability of the user interface; and any performance issues, deployment concerns, or integration/customization requirements.
It's at this point that shops should start to put together a PoC, Grimes points out. He has very specific PoC criteria in mind. "It should cover full data volumes for a subselection of information sources, high-volume use for a subselection of usage scenarios, and testing of a broad set of representative functions. You may find it helpful to use automated testing tools to simulate load." He says that "lessons learned in the course of evaluations and prototyping are invaluable in crafting an implementation approach. By paying particular attention to the amount of time it takes to build a comprehensive proof of concept, you will get a good indication of how smoothly the full deployment is apt to go."
From there, of course, would-be adopters can proceed according to the implementation steps Grimes outlined above. He nonetheless tenders a couple of common-sense best practices -- a supplement to his phased approach.
"While an organization that already has a strong search/BI/analytics program enjoys a head start, UIA often simplifies the solution set by delivering several technical functions through one engine," he concludes. "It's prudent at first to target discrete, clearly defined business problems where impact can be measured and to carefully test at each implementation stage. A carefully planned introduction and early successes help pave the way for broad acceptance and adoption, turning stakeholders into advocates."