Don’t Put All Your Eggs in One Basket

Have you ever lost a project, or had it badly damaged? If so, then you should definitely read on. The classic idiom that is today’s title identifies a basic principle with broad applicability. Spreading things around reduces risk, particularly of losing them all (at once). For investments it may speak to diversification. For IT, it may speak to backups. But for analytics it may speak to the project environment itself.

Analytics projects often become quite large, and when they do this represents a significant amount of content, and with it, value. Depending on your vendor this valuable content may all be stored in a single project. This is certainly the case with our three-letter competitor. The risk (of a catastrophic failure) is probably the same regardless of project size (and fortunately, low), but when you get these large projects then the consequences are increased significantly. No program is perfect (and I would never make such a claim about Arbutus), so all it takes is one small hiccup in the program to wipe out the entire project; perhaps hours, days or weeks of work. Even if you’ve implemented rigorous backups, you’ll still lose everything since the last backup, and more often than not that can involve a significant amount of wasted time.

Well, what can you do about this situation? The obvious answer is to not use just one basket. The problem with the previous example is that they store everything in a single file. If anything happens to that file then you’ve perhaps lost it all. Instead, why not change the model, to reduce your risk? That’s exactly what Arbutus does!

An Arbutus Analyzer project isn’t a single file, but a whole directory tree of files. Each table definition, script, workspace, index, view, … is a separate file. Even better, each folder is a separate Windows folder of the same name. What this does is dramatically reduce your risk, by spreading the project’s contents across many separate files and folders. If something goes wrong, your total exposure is the recent edits you’ve made to that one object only. In the unlikely event of a serious problem you don’t lose your entire project, just that one item.

But it can get even better. While in separate files, your project is still on the same desktop. Arbutus’ shared folders allow you to spread your content across multiple servers. Shared folders appear just like they were a part of your project, but they aren’t. Instead, they are automatically added in from other locations. Your shared folders may be on another drive or another machine on your network; they may even be on a server in another city or country. When the shared folders are on a server then it is also much more likely that you have frequent and automatic backups. Instead of one basket, there are now many.

Analysts no longer need to accept the risk of storing their entire project in a single “basket”. Arbutus technology not only provides powerful technologies that enable sharing within teams or enterprises, but a valuable by-product is that it also minimizes the risk of losing it all.

A Refreshing Idea

When you use spreadsheets as input, how do you ensure the data is current? The same question applies to any refreshable source (like Access, XML, print image), but spreadsheets are by far the most common. This is a very relevant topic, because analytics, and particularly audit analytics, tend to be run periodically. Whether daily, weekly, or during your next audit cycle, when you re-run an analytic you have to refresh the source data.

OK, back to the question. There are two distinct scenarios here: one is that the spreadsheet has the same name, but newer data, like Branch11Sales.xlsx. While the name is the same, the data may be fresher. This is the easy scenario, and all the tools handle this well. But say you get a new file with a different name. Perhaps you set up an analytic based on Aug2016.xlsx and now you need to run it again with Sep2016.xlsx. This can be more challenging.

With our competitors, you have two choices: Refresh or re-Import, but both of these options have problems. If you want to refresh the data then you are forced to rename Sep2016.xlsx to Aug2016.xlsx, so the refresh will work. Unfortunately, the result is that your file name is no longer representative of the data it contains (the name says Aug, but it contains Sep data), and I guarantee you that this will bite you sooner or later.

The other option is to re-Import the spreadsheet, which is the normal approach to this situation. The problem with this is that you lose any of the value you have added to the table layout. You may have invested a significant amount of time getting the layout “just right”. Adjusting column names, widths, titles, etc, or creating computed fields, relations, etc. All are lost when you re-Import. This means you either have to repeat those steps with the new table, or create a quite complex script to re-apply all your changes to this new table. You may enjoy writing scripts and find this a challenge, but to me it is just unproductive time.

You might think that you could just re-link your table to the new spreadsheet, but this won’t work, as you’re only re-linking the intermediate flattened file, not the xlsx source, so this pretty much never works.

That is why I’m so proud of your options with Arbutus. Instead of two, you have three options with Arbutus. You can, of course, re-import or change the name and refresh, as above, but they have the same issues as already described. Instead, Arbutus offers a third (and much more suitable) option: why not just re-link to the new file! I know I just said that this doesn’t work with our competitors, but it does work with Arbutus. When you re-link any refreshable data file (like a spreadsheet, XML or print image), you actually select a new source file! In our case, this means picking a new .xlsx file directly. The dialog to select the new file automatically shows you only spreadsheets to choose from. Once you select the new spreadsheet, the intermediate data is (of course) refreshed, but your table layout is otherwise unaffected.

If you want both Aug and Sep to be available, then just duplicate Aug and then re-link the copy. Of course, this technology isn’t limited to spreadsheets. As I noted, other sources like XML and print image work in exactly the same way.

Your time is valuable, and the more of it you spend on analytics the better your results will be. Wasting time repeating steps or building unnecessary scripts, or risking the quality of your results by renaming source files shouldn’t be required for such a common scenario. Luckily, with Arbutus this needn’t be an issue.

Unicode and Analytics

Unicode is taking an ever larger role in modern analytics. In my (long) career its status has gone from non-existent, to a spec, to occasionally used in foreign countries, to built-in to Windows, to pretty much ubiquitous. Today, unless you your scope never leaves the United States you pretty much have to consider Unicode. Even for wholly US operations, you will frequently receive Unicode data, so even in the US Unicode is relevant.

Audit Analytics products vary in the Unicode support, so this is a very important topic. But before we get to that, a basic character set primer is in order. Generally speaking, PCs support two character sets: ASCII and Unicode, with Unicode being stored as UTF-16 or UTF-8. I say “generally speaking”, because ASCII has innumerable “code pages” to support the characters of specific languages and countries. Proper ASCII support (like Arbutus) allows you to specify the code page of your data, rather than just assuming the data matches your country’s code page.

Because of this multiplicity of code pages, an initiative was undertaken to standardize on a single character set, with no or very limited code pages. This became Unicode. As most analysts know, ASCII has one byte for each character (so “ABC” was stored in 3 bytes), but with many more characters this was no longer possible. The full Unicode set is very large, but as it turns out, 64,000 characters (2 bytes) supports virtually every character in common use in all current languages. This is referred to as the “Basic Multilingual Plane”, and the implementation as 2-byte characters is UTF-16. As a result, “ABC” in UTF-16 would be the 6 bytes “A|B|C|” (where | is a binary zero).

There are two big problems with UTF-16. The first is that for most users it can double the size of your data. The second is that the actual bytes contain lots of binary zeros. Many/most computer applications use a binary zero to end a string, so this causes no end of problems. In fact, to convert an application to UTF-16 is typically a very significant challenge.

UTF-8 was the solution to the problems presented by UTF-16, and is now all but ubiquitous in this Internet world. What UTF-8 does is store the most common English characters and symbols in a single byte, but then it uses either 2 or 3 bytes to store the non-English characters (with no binary zeros). North Americans, and in fact most Western European languages will notice only a nominal (or zero) change in file size, because “ABC” is exactly the same in ASCII and UTF-8. More importantly, since there are no binary zeroes in the strings, it is easier to work with in most situations. As a result, in UTF-8 “ABC” is still 3 bytes, but “ABĆ” takes up 4 and “ABﺝ” takes up 5. I won’t get into the technicalities, because they really don’t matter in most cases. The bottom line is that you typically get the best of both worlds: full character support with a nominal change in the files and file sizes.

Your corporate data may not be UTF-8, but since virtually all Internet data is, if your tool doesn’t support it then you are missing out on a ton of data. You might want to use Internet-based data as reference sources in your scripts, or externally supplied data may come that way, as is increasingly the case. In either case, the absence of UTF-8 support cuts you off.

As for application support, our major competitor supports Unicode, but has separate ASCII and Unicode versions. The two versions are incompatible, although you can convert from ASCII to Unicode (but not back). If you use their ASCII version, you can’t share table definitions or scripts with other Unicode users (without utilizing a 3rd party converter). This can present significant challenges in multi-national environments. Even worse, they provide no support at all for UTF-8 at all. Not only are they blind to large swaths of data, but they also double the size of most files they create.

Of course Arbutus supports Unicode, and supports it correctly. There is only one version of Analyzer, and it fully supports ASCII, ASCII code pages, UTF-16 and UTF-8. Because the software is inter-operable within these character sets, your files remain small, unless you specifically use Unicode, and even then in most cases the size is still about the same, as Arbutus converts files to UTF-8.

If you’ve had problems reading certain data sources or are unhappy about the exploding size of your files, perhaps it’s time to look at Arbutus.

Save the Date (and time and datetime)

Date and time processing is fundamental to many types of analytics, and so it’s important that your software handles them. More importantly though, the quality of your results will almost certainly depend on how well it handles them well. In the day, most analytics software only supported dates, but with the increasing pace of business, time is becoming much more important. Today, date and time support is now pretty much standard. Even so, there are subtle and not so subtle differences between products that can significantly affect suitability.

There are several aspects that are important when dealing with dates: elapsed times, constants and calculation. I’ll cover each in turn.

When you subtract two datetimes, you don’t get a point in time, but an ‘elapsed time’ (which may actually span days). Processing of elapsed times is a big thing. For example, the two times 15:22:18 and 17:44:18 are 2 hours and 22 minutes apart. What do you get when you subtract one from the other in your package? If the answer is 0.09861111111 then perhaps you get my point. I’m sure you can create a computed field that turns this into a more usable result, but why should you need to? The more time wasted on plumbing means less you can devote to the task at hand. Of course Arbutus will return 02:22:00 automatically, with no special handling. A subtler, but still interesting issue, is elapsed dates. With other products, subtracting two dates returns a number, so Jan 14-Jan 10 is 4. This isn’t a wrong answer, but it obscures the fact that you are measuring a period of time. Analyzer presents this calculation as “4 Days”, to ensure you understand the nature of the value. When the difference includes both a date and time then this is also automatically handled, so an elapsed difference might be 4 Days 02:22:17, for example.

‘Constants’ involves comparing the data (or calculating) against fixed values. Comparing two date and time values is pretty standard, but many datetime calculations actually involve elapsed times rather than points in time. How easy is it to add 8 ½ hours to the starting time, or given starting and ending times, how easy is it to calculate if someone has worked more than 8 ½ hours (perhaps an overtime calculation)? Since Arbutus supports elapsed time constants as well as point in time constants, this is as easy as t2-t1>`e08:30` (with the e for elapsed). Isn’t this better than t2-t1> (1.00000000/24*8.5) (the other guy’s standard approach)? Though uncommon, the comparison is even worse if an odd number of minutes (or worse, seconds) are involved. Eight and a half hours is easy to turn into 8.5, but what about 8 hours and 19 minutes (8.3166666)? While either approach will likely produce a correct answer, one is much easier to document, and for others after you, easier to follow.

‘Calculation’ involves working with datetimes, and there are two distinct issues. The first is flexibility. Say you have two fields that are the date and time of an event. How easy is it to create a single datetime for this pair? One might expect that it is as easy as date+time (as with Arbutus), but check your package: you may be surprised how hard this is. The second issue is accuracy. If your package doesn’t recognize the distinct nature of elapsed times, then computer numeric precision can result in processing errors. In the earlier example, it is easy to come up with 8.5, but the result of (1.00000000/24*8.5) is actually .354166… What this means is that the calculation doesn’t yield exactly 8.5 hours, just approximately. This may not be a big thing in many cases, but when the elapsed time is exactly 8.5 hours it may fall into the wrong category (such as work hours less than 8.5). Because Arbutus explicitly recognizes elapsed times, 8.5 hours is always exactly 8.5 hours, and you can rely on that in any of your analytics.

Date and time processing is a very nuanced area, a fact that is often not immediately apparent. Not only can errors result from poor implementations, but as I repeatedly point out, the simpler something is to do, the more time you have to think about results. Date and time processing is just another such example.

Protect Your Scripts

Most audit analytics programs are built around scripts. These scripts often contain valuable and/or proprietary information. For these reasons and others, you might want to protect them. This post discusses how you can implement script protection with Arbutus.

First of all, why protect scripts at all? Here are a few reasons:

  • You don’t want the script to change (perhaps careless edits may break the result)
  • You are required to ensure that they don’t change, and to track any such changes (as with a SOX control)
  • You don’t want the users to see how a process is implemented, perhaps to limit their ability to circumvent it, or maybe just to avoid distractions with details
  • You consider the script methods to be Intellectual Property (IP) and don’t want to give away your trade secrets

With Arbutus you have two main methods of protecting your scripts. If all you want to do is protect a script from change, then you can just set it as “read only”. As each script is a separate file, this is easy to do with Windows. Any script (or folder) may be protected in this way, whether local to a project or shared with other users. The contents of the script are still visible and can be run as before, but users may not change the contents. Also, they can’t remove the “read only” flag unless they have appropriate Windows rights.

On the other hand, you may also want to hide the contents of a script. With Arbutus, you use the Protect option on the Tools menu. Running Protect makes a copy of the script, but modifies the contents so they can only be interpreted by Arbutus, and even then only if you have the correct protection key. You can safely distribute this protected script to others. Users will be able to run the script, but will not be able to see or edit the contents, even with external tools like Notepad. This is a perfect way both to ensure the processing embedded in the script can’t be seen, as well as to protect your valuable IP. Scripts protected in this way also have a distinct icon in the overview, so it is immediately clear to all that a script is protected.

Both of these techniques work with Analyzer “out of the box”. At Arbutus we recognize that with security issues, one size seldom fits all, and we strive to ensure the maximum flexibility to meet your needs. If change tracking is part of your objective then there are approaches to implement this as well, but this topic is best for another post.

Power to the People

My last post covered refreshing data, and specifically how to ensure your results use the most current data.  To do this I mentioned one use of a technology we call auto-executing procedures.  To refresh your memory, these are scripts that automatically run whenever you open the associated table.  As I mentioned, there are more applications for this innovative technology.  Most (if not all) of them involve the area of self-serve analytics, as this is a technology designed to automatically take care of the details, leaving you to focus on the results.  This post is a summary of the main uses for Arbutus’s auto-executing procedures.

As mentioned last week, if you have a result table, used for whatever purpose, auto-executing procedures ensure that the table you see is always built with the most current data.  Not only can it re-perform the required analytic steps, but just as importantly, it can also ensure that your source data is current as well.  It might, for example, check for more recent versions of any of the inputs, refresh any refreshable sources, or run an FTP session to retrieve the latest data directly from your system.

Another situation is one where you know the table (result), but you don’t know the script(s) necessary to recreate it.  You could hunt around and try to identify the correct script, but this can be an error prone (and at least tedious) process, so why bother?  Instead, just open the table of interest.  All the rest is handled automatically, and your data is correctly re-built.  You might even include a test so that it is only re-built if the source data has changed.  This lets you focus on the results, without getting bogged down in the details.  For advanced users, tasked with providing analytics for a team, merely opening the shared table (by anyone on the team) will ensure correct results every time.

Extending the above example, for less experienced users you want to keep the interface as simple as possible.  The more complex the project interface, the more likely it is to confuse.  Rather than risking confusion with scripts, tables, etc., keep it simple and just show them the result tables they need.  They choose the table and the rest is automatic.

When a result table is based on user input, you can simplify the processing.  For example, you may have a generic query that allows you to specify a variety of criteria, such as date ranges, departments, categories, min/max amounts, etc.  You would normally implement this as a script for the users to run, but this is an alternate, and perhaps easier, way to achieve the same result.  When the user opens the table (say GL_Query, for example) they will automatically be prompted to supply the selection criteria.  When they click OK they will see the results for those specifications.  There is no longer a need to seek out the appropriate script; just open the table and the rest is automatic.

Similar to the above, you may have a standard analysis or query, that might be applied to any of a large number of files.  Perhaps you have a folder with daily reporting spreadsheets from each division.  You could use this technique to allow the user to select the specific file/spreadsheet they wanted to query.  This is easy for Arbutus, as our Dialog command includes the ability to select files using the standard Windows dialog.  You would then have your result for that specific file.

When using other Windows tools (like Excel) Arbutus’s ConnectPlus is also fully compatible with this technology.  Using Excel, the user simply chooses the query table through ODBC, and will then be presented with the same criteria dialog as if they were running Analyzer.  The result in Excel will be the result using the specific criteria supplied.  The Excel user needn’t deal with any of the complexities of performing the query, they just see the result.  These connections can even be saved, so the opening of the spreadsheet automatically launches the script, and produces the result.  An icon on the desktop can automatically generate even a complex result, with or without user input.

As I have said previously, self-serve analytics are a goal we should all strive for.  One of the issues with self-serve analytics is managing the complexity of the process.  It is one thing to have simplistic queries, but much more empowering if you can allow even novice users access to complex analytics.  Arbutus’s auto-executing procedures are a powerful way to make self-serve reporting more attainable, by simplifying the interaction with the user, even for non-Arbutus users.

A Refreshing Exercise

Today I want to talk about refreshing your source data and analyses.  There are two distinct aspects to refreshing: one is updating the actual source data tables, but more important is the refreshing of any analyses that are based on that data, as these are the real reason for the data in the first place.

Different analyses have different requirements regarding data latency, but as a minimum, the data has to be at least as fresh as the frequency you run the analysis.  If you are using CM to run a process daily, then the data had better be less than a day old.  Often you want it much more current than that, and it is your job to ensure that happens.  Virtually every source file is subject to refreshing.  The obvious candidate is a database connection (table), but your source might come from a spreadsheet, your organization’s accounting system, or even the web.

Each of these sources has different requirements and technologies to get the latest data.  For links to your accounting system, most analysts transfer the refreshed data manually, but you may well be able to automate this transfer (with FTP or otherwise).  As for databases and spreadsheets, you can issue the Refresh command, but you still need to remember to do so, and you may not even be aware that your data is stale.  This is why Arbutus’s optional direct read of these sources is so advantageous.  If you know you want the most current data, then read the database table (or spreadsheet) directly, ensuring you are always current.  The Internet is a special case.  It is so dynamic that when your source data comes from there Arbutus always automatically reads directly, ensuring the data is always current.

A more challenging situation can be the updating of your analyses.  If you have an interesting analysis/result, perhaps used to feed a visualization, dashboard or exception report, how do you ensure this is generated from the most current data?  The answer with Arbutus is “Auto-executing procedures”.  This is kind of like refresh on steroids.  Rather than refreshing a source table, it actually refreshes the entire analytic itself, regardless of complexity.  This can even include the refreshing of the data.  When you open the associated table the analysis is automatically re-run on the spot, so that the table you see was generated at just that moment.  There is no need to identify the steps to re-create the table, and then run them, as all this happens automatically.

There are many more benefits of auto-executing procedures, but I’ll describe those in another post.

Ensuring that your data and results are current can be a challenging process, and failures in this area can lead to errors in your results, and possibly even bad decisions.  The one thing that’s for sure is the more you rely on manual steps the more errors there will be.  This is why your tool should do everything possible to take care of the details, leaving you to focus on the results.  Arbutus is just such a tool.

Collaborative Analytics

As data gets bigger (and more complex), you often need more than one person to complete an analysis.  For this reason, it is critical that your analytics solution supports collaborative analytics.  In fact, I believe that the better supported it is, the better your results will be.

When I say collaboration, what exactly am I referring to?  In most teams the individuals have different strengths, and in many cases, different roles, and you will get the most effective results when you can easily draw on those skills.  Obvious candidates include:

  • the data analytics experts (perhaps you), who are familiar with the techniques to turn data into results. You may even have experts within this group, that specialize in particular techniques.
  • the subject matter experts who are familiar with the particular systems. If you are analyzing the shipping process (for example), it would be a great help to be able to draw on the knowledge of those familiar with the peculiarities of that specific area.
  • the data experts, familiar with the definition or identification of data. You may have data warehouses, mainframes, VSAM, DB2, IMS, … and having someone who knows where to look, and specifically how to access that kind of data, can allow you to focus on the analytics themselves, rather than the technicalities of accessing the source tables.
  • the automation specialists. With most modern tools it isn’t too difficult to automate a process, but when you call in the experts you can get a finished product that is more bullet-proof, and perhaps meets your departmental standards.

In the past analysts were often generalists, who were expected to fulfill all these roles, but with the complexity of modern environments, specialization has become inevitable.  It is now much less common that a single individual has all the skills necessary to finish the whole job.  If your tool doesn’t support collaboration well, then you may be forced to send copies of data (and other components) to others.  Not only is this inefficient, but it can lead to errors when the various versions get out of date.

This is why I am so proud of Arbutus’ shared folders.  Any analysis project can be run out of a shared folder, right from inside Analyzer.  In this way, the technical expert can create the tables, the subject matter expert can create the relationships and business rules, as well as identify the key fields.  You can do your analyses and perhaps turn the results over to a scripting specialist to make them repeatable (or even scheduled for CM).  You all work off the same set of tables and scripts, in a collaborative manner, so nothing is lost or duplicated; all without leaving your desk.  These experts can be anywhere in the world and it works just as well.

“Collaboration” is one of those words that may be poorly understood: What does this actually mean to me in my job?  I hope this gives you an appreciation of what it means, and how important this can be in maximizing your effectiveness.

Cut the Clutter!

Analytics can be a messy business.  A novice might think that all you’ve got is input data and results: nice and tidy.  Reality is typically far different.  Not only are there many dead ends that didn’t turn into useful results, there are also seemingly innumerable “helper” tables, fields and scripts that did contribute to the final result.

These artifacts are absolutely necessary to make the results repeatable.  The problem is that while they may be necessary, their mere presence clutters the project, even if you adopt standards to minimize their impact.  This can obscure both the critical components (fields, scripts and tables) that you need to interact with, as well as the results themselves.  This may not matter for you (the creator) right now, but for reviewers, or those who take over the project from you, or even yourself when you get back to the project in the future, it can make the project much more difficult to understand or repeat, even with appropriate documentation.  The rule I try to live by is to rely on documentation as little as possible, so clarity in my projects is paramount.

The other problem is tidying up after one’s self.  Many (or even most) of the tables you created along the way are no longer necessary once you get your result.  They are transient files that were needed at the time, and will be automatically created again when the analysis is re-run, but aren’t required the rest of the time.  This leaves you with three possibilities: leave the clutter in the project, tediously go through and delete all the intermediate tables that are no longer required, or (just as tediously) create a script that cleans up for you.

The goal is easy, a tidy and usable project, but the result can be challenging to achieve.

So imagine, if you will, that you could effortlessly clean up your project. Arbutus offers three unique technologies that help make this a reality.  One, Arbutus includes the ability to “hide” any field, table, script, index, …  You, of course, get to choose what is hidden, but this gives you the ability to present the project in the clearest manner, so only the important components are on display, without losing any of the underlying helper tables, scripts, workspaces and fields that are a necessary part of producing the result.  Everything hidden is still there, and can be shown at any time, but on opening the project you see just the important results, with the “plumbing” hidden away, as it should be.  This ensures that your analyses can be easily understood in the future.

Two, Arbutus will automatically delete intermediate files that are no longer required.  Just give them a standard name (like temp…, or whatever; you choose) and Arbutus will automatically clean up after you when the project is closed.  Tables, indexes, whatever, will be swept away with no action on your part.  Tidying up becomes totally automatic.

Three, sub-procedures allow you to bundle an entire set of scripts into a single package.  Your analysis might involve 3 scripts, or 300; it doesn’t matter.  The entire set can be easily bundled into a single script file.  This not only un-clutters the interface, but just as importantly, it allows you to keep all the related scripts together in a single package.  This makes it easy to maintain, document and run.

As I said at the start, analysis can be a messy business.  You owe it to yourself to make use of the best technologies to help.

Self-Serve Analytics

Self-serve analytics are an ideal we should all strive for.  They minimize the “time to answer”, by letting the consumer of information directly control its creation (rather than relying on a team of analytics experts).  You can maximize the value you can generate from your data by letting your entire team of subject matter experts do what they do best: apply their knowledge.  Once you’ve seen it properly implemented, it’s hard to go back.  Unfortunately, as with most ideals, this is one that is often not met, or is limited in scope.

There are a few common reasons for this.  It may be that your tool can’t access all the information required for your analysis (very common in data warehouse/mart environments).  It may be that you don’t have the experience or knowledge to identify the correct source data or techniques.  It may even be that you could perform the analysis, but it takes unacceptably long to produce a result (very common in this age of big data).

What is interesting about these problems is that they are all artificial!  These are not “hard” issues that can’t be violated.  Instead, they represent shortcomings in your tools.  They may not support all your data sources, or they may not support a collaborative analytics environment that will let you draw on the right experience from your team.  Most importantly, they may not have the power to produce timely results.

This last one is especially pernicious, as you have everything you need, except the time to wait for the result.  Every business decision essentially boils down to a cost-benefit analysis, including a decision to analyze data.  With analytics, the benefit is often nebulous (your analysis may or may not be valuable), but the costs are quite real.  These aren’t usually dollar costs, but time is money…  As a result, potentially valuable analyses are often not run, solely because your time is too valuable to wait.

Imagine, if you will, that all these barriers to self-serve analytics were removed.  This is what we deliver at Arbutus.  Our data sources are not limited to your data warehouse.  Instead, you can access all your corporate data, including the challenging mainframe and legacy sources.  Even if you want to stay with your existing tools, our ConnectPlus technology extends their data range in the same way.  Our shared folder collaborative analytics environment ensures that you can draw on the right knowledge to ensure you complete you task.  Finally, with typical processing speeds in the millions of records per second, we are up to your big data needs.

It hard to overstate the value of self-serve analytics.  Don’t let your tools stand in the way.