Building or Buying Analytics

  • Comments posted to this topic are about the item Building or Buying Analytics

  • I think this sentence sums it up "developers working with analysts can truly add value and insight to the information a business holds."

    I've worked in the BI space for years, mostly on the business side.  But I'm a tech at heart. I now work for Calumo who provide BI solution software on SQL Server.  My experience is that Clients who have internal SQL Server resources who get engaged  have significantly richer analytics and BI reporting that drives the business.

    It's the best of both worlds.

  • I've never seen a successful implementation of Cognos, Power BI or Tableau without a BI Developer being heavily involved.  There are several reason for this but mostly because live data is designed to run a business system, not perform analytics, so we can't simply "plug" a BI tool into a production database (despite what the vendor says).

    In every successful implementation I've seen, there has always been a large element of ETL beforehand. Even if the end users doesn't know it.

  • I think we're rapidly moving toward user self-service.  Once upon a time secretaries took shorthand and managed all the correspondence.  Today, secretaries are a thing of the past, giving way to executive assistant, or, in most companies, the role is delegated to everyone.  Executives, even, manage their own calendars and emails.  Excel was purview of the technically savvy.  Today, everyone knows how to create and use a spreadsheet.  Data and BI are no different.  I work in IT and, officially, my title is Senior Software Developer.  But, I consider myself a Data Engineer (I disagree with the way the title Data Scientist is often used).  I get the data out of the operational systems and into an understandable format.  I then show the business how to access that data.  They can use any tool they want; Excel, Access, Qlik.  Unfortunately, most business analysts are not skilled enough to manage a Qlik (or PowerBI) data model.  So, I usually need to do that for them too.  But, we are really pushing for user self-service.

    Whether you build or buy, the key is going to be in data governance.

    Another point to consider in the build/buy decision is scaleability.  Rarely do the end users know what they want or need until they start playing with the data.  If you buy a tool or final solution, how easy is it to change?

  • Yes - I agree with Steveo.  There is a challenge in finding ways to flexibly enable end users to explore well managed, modeled, and governed data, while also being able to build out systems that can grow and scale, but still integrate new approaches found in the exploration process.  My outfit has a large BI solution, and a warehouse and marts with massive ETL, but we still face challenges in just getting data to the people who could find insights in it, and enabling them with software that can facilitate that process with sufficient power and speed.

  • In general I have never seen a solution that just works out of the box with no/minimal  configuration, or things that can only be done by business users.  BI is no different in that regard, picking the right platform can certainly save you a lot of time but to get a solution that really works you with almost certainly need to involve technical as well as business users.

  • I specifically work as the data architect for the analytics & data science team. I am that technical resource responsible for making the data happen for the team to use. There is great struggle with conforming even very clean data to the model that is needed. This is why just out the box solutions just do not work. At some point, someone needs to customize and that customization often requires tech resources to make happen.

    I am becoming more of a schema-on-read fan, where most of the customization is happening on the front-end rather than the back-end. Though, even then, you are relying heavily on the end user to know advance modeling concepts on top of allowing very complex transformation processes to exist in a front-end report versus a controlled back-end system. It has it's pros and cons, but even then, performance needs is often the main reason that a tech resource is still needed for when the user is self-service. They create a report, they model the data for the report, and it takes a long time to refresh, which triggers a person like me to make it faster.

  • I'm still torn on schema-on-read. While I do agree with you in some sense, and I think this will be the direction we go more in the future, I also worry about the overhead over time of changing schemas and the need to be able to "read" different versions over time, which  adds tech debt in my read code.

    I think this just shifts where the debt is.

Viewing 8 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic. Login to reply