Guy Filippelli and Jeremy Glesner, both of Berico Technologies, shared several government case studies and made some compelling arguments for using MarkLogic to build solutions designed to tackle information analysis challenges. The case studies were well-thought out and despite the presenters not being able to tell us all of the details (due to the sensitive nature of the solutions they built), the session was very informative.
The guys started the case study portion of the presentation by defining “information fusion: The aggregation of information, regardless of type, to provide useful views of the information in meaningful ways.
The first case study - The relational approach
The Berico team built a system that was designed to be user-friendly and to display data in meaningful ways to personnel seaching for the bad guys in the war in the Middle East. Unfortunately, the tool was so successful that users started bringing the team dozens of new types of content in myriad formats.
While the success of the solution was viewed as a victory, it also created a new challenge: lots of additional work. The developers did not want to loose the data being provided to them, but were struggling to model the content to get it into the relational fields (columns and rows) the system relied upon. The project quickly overwhelmed the team because each new data format created a large amount of work to ready the content for analysis.
[To learn more about the reasons why relational database are not the best tool for these jobs, read Endless Possibilities: Norm Walsh on the Changing Nature of Publishing.]
The second case study - The MarkLogic Server approach
A similar project, utilizing data from a large number of data sources in a variety of formats, was launched using MarkLogic Server. The immediate and big difference is that the project relied on XQuery (and XML). This approach drastically reduced the skill sets required by the team to deliver a working solution and created a major reduction in workload due to the fact that MarkLogic Server can handle the data in its original format, without the need for a cadre of database programmers with special, expensive, and scarce talents to wrangle it into submission.
Because the content did not need to be modeled as it did in the relational database example, the team could focus their efforts on enriching the content, improving its accuracy, and developing additional innovations.
The final word: Total cost of ownership
The presenters made it crystal clear that it’s less expensive to purchase MarkLogic and use it to develop government data analysis solutions than to try and tackle the same challenges with a relational database approach. MarkLogic Server helped the team improve productivity, automate previously manual tasks, and slash data management costs.
In the short-term, it may seem wiser to use a relational database approach, Guy Filippelli, CEO of Berico Technologies said, “But in the long-term, it’s much smarter to take the MarkLogic approach.”
