Do you like smartphones? Think they’re easy to use? Would you rather carry around a digital camera for photographs, a phone for calls only, a pager for messaging, a GPS for navigation, an mp3 player for music? With the amount you can do with a smartphone these days, this list could go on and on. <br> <br>The fact is that many of us do indeed have multiple devices that overlap in terms of function, but we often rely on the smartphone in many cases to do the job that another device may do better.
Certainly, you can take better pictures with the best digital camera on the market. However, those pictures likely come with the challenge of configuring the camera with the right settings to get the perfect picture. It’s often easier to take a picture on the smartphone with a simple point and shoot than it is with the camera. A high end DSLR camera that is considered “best of breed” that is properly configured will take a better picture than a smartphone, but when you need a quick, good quality picture a smartphone almost always does the trick. It’s too easy to snap that photo in just a few seconds. The smartphone’s hardware and software are designed to work together to make the process effortless.
So what does this have to do with business intelligence?
This is a pattern that I believe is applicable within IT organizations, and more specifically with enterprise data architectures. When I work with companies, I very often see architectures that employ best of breed point solutions in each part of the stack. An example might be Dell servers, Cisco switches, and an EMC SAN at the bottom of the stack; Oracle database software, Informatica ETL software in the middle of the stack; SAP Business Objects, SAS, and of course, Microsoft Excel, for BI/data visualization/analysis at the top the stack. <br> <br>Each piece does its part extremely well. <br> <br>Each piece has a set of features that make it best of breed for the purpose it serves in a specific part of the stack. <br> <br>This a nice, clean architecture with no overlap throughout the stack.<br> <br>Carrying the smartphone/digital camera comparison forward, in this architecture we can say SAP Business Objects is the digital camera. It’s an apt comparison; Business Objects is the best at what it does. You can get that perfect picture (report) out of Business Objects, assuming you configure everything correctly. It may take some time, but you can get exactly what you want down to every pixel.
The best point solution isn’t always the best business solution
What is the “smartphone” in this architecture? It could be a lot of things, but here I mean any other solution that might overlap with the best of breed architecture described earlier. This overlap might manifest itself in different ways. It may require you to move data around or persist multiple copies of data. It may be having two solutions that seemingly provide the same function, albeit in different ways. <br> <br>Is this worth it? I would argue it is, because the smartphone solution is something that is purpose built to provide fast, effortless access to information. We ended up with modern smart phones because we built something that end users wanted to use, that was focused on their needs, not on just making phone calls. Despite the annoyance of carrying multiple devices with you on vacation, it’s worth it when the moment arrives and you need a quick, decent picture. Similarly, the overlap that may result in an architecture with a combination of a best of breed point solution and a business focused solution is also worth it if end users quickly get what they need.<br> <br>Let’s say an end user within the business quickly needs an answer to a question due to suddenly changing market conditions. Where to start: Tableau, Business Objects, or SAS? Which system is easiest to use? Which system is mapped to the data set necessary to answer the questions? Once the correct system is determined, how long will it take to actually get the answer back? What’s the best way for this end user to get a (hopefully quick) answer to their question? This architecture has the best of breed enterprise BI tool, best of breed statistical analysis tool, and the best of breed visualization tool.
Put the user first
Another example: a new data scientist is hired onto the team (a trend that I see increasing) and that person is more comfortable using R instead of SAS. Do you force that person to use SAS because it’s the best of breed solution despite making the new team member less productive?<br> <br>In both examples, the end user of the enterprise data architecture and associated solutions is hindered from making fast, immediate progress on a real business problem in the name of the architecture. Do R and SAS overlap in functionality to some degree? Yes, but isn’t the goal to allow end users to get at that data as quick and easy as possible in order to help the business?<br> <br>In life, there are spontaneous moments constantly happening where you want to have that ability to snap a quick picture. This ranges from needing to remember a serial number to help with a repair to simply capturing that hilarious moment at home. Similarly, every day in our jobs we are constantly in need of data to answer a customer’s question, support an opinion in a meeting with your boss, improve a process, etc. What all of these moments have in common are their ephemeral nature; you need that picture/answer right then and there and quickly the moment passes. <br> <br>Why not arm your business people with the solution that allows them to quickly and easily get that answer, even if it overlaps with pristine, best of breed enterprise data architecture. Not only will your end users thank you, I’m guessing your business will improve.