Deleted

  • Deleted.

  • Good questions, and lots of "it depends" answers...but I'll try to give my perspective. 

    1.  As a BI & Analytics Consultant, I see many companies hire somewhat technical people (analysts) within their business units to try and bridge the gap with IT. You'd think that we would have figured out how to get IT and Business to work together in harmony by now, but that's unfortunately not the case in many organizations and the business gets frustrated with IT's lack of (and slow) response to solve real business problems. Generally speaking, it would be the Analyst who asks the questions and IT to provide the technical answers, but it varies greatly and an Analyst who can ask the right questions and bridge the gap successfully with enough technical knowledge is worth a ton. From what I've seen, most companies expect some level of reporting capability from Analysts. But the more technical knowledge you have, the more value you would bring as you would not be reliant on IT for everything.

    2. Yes, I see this very often. Power BI is very intuitive and easy to use, but an end user without the necessary technical skills are just not able to develop enterprise-ready data models. That is still very much a technical skill, and a lot of my Power BI work as a consultant is to businesses create data models that can scale and be shared with many people.

    3. In my experience, the ability to create a star-schema data model (which is the most effective data model for OLAP analysis) is something that very few Analysts have. Understanding the source data and systems would be another.

    4. This really ties into my previous two answers. From what I've seen, most Analysts create single flat table data models. This might be ok for your one-off initiative, but doesn't scale when the model becomes complex or contains a lot of data. At least from a Microsoft perspective (Power BI), a star-schema is still a best practice. Dimensional data modelling skills would add to your value exponentially, and this is the message I give to every Analyst I ever speak to.

    5. There are many resources out there, and you being on this site is a good start. Here's a few others I can recommend (some of them have video content):

    Guy in a Cube
    SQLBI
    Chris Webb
    Paul Turley
    Power BI Blog

  • My suggestion would be that, whatever you end up doing, it needs to be what you want to do.  Remember also that all roads in this business lead to the data.  You need to know about the data and how it's stored and how to manipulate it using the language of data (T-SQL) or end up like the poor fellow in the following post...

    https://www.sqlservercentral.com/Forums/1912521/Date-showing-instead-of-blank-result

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Deleted.

  • Are you looking for a change to improve yourself, or just an opportunity to do what you are good at (or interested in)? The former is a healthy choice. The latter is not going to help you progress. You will be disappointed if you are looking for a position where you can redefine an established business process and draw up scope of work to the limit of your imagination.

    Enjoy modeling? I enjoy modeling too but I don't want to make a living renovating other people's houses. If you wish to play a bigger role, improve yourself, acquire a set of hardcore skill, then bigger responsibility will find you and you will become a pillar of the house - nothing is more fulfilling than that. Since you mentioned BI, please look up U-SQL and see if it interests you. Please let me know.

    Good luck with your future endeavor.

  • Keep in mind that business intelligence involves a lot of interfacing with internal and possibly external end users. The choices regarding technology and implementation will be handed down from above, and if you consider yourself more of a software engineer or a creative type who likes to stay "in the zone" focusing and perfecting your work, then you will actually find BI tiresome and frustrating. Rather than a master chef focusing on the craft, your role as a BI developer will be more like a maître d' dealing with fussy high profile customers who want it all done their way and delivered today. I'm just saying that, depending on your personality, it could seem that way.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • Deleted.

  • Here is my 2 cents as a data architect on a data science and data analyst team.

    Most data analyst are not tech savvy. As others have mentioned, the idea that a data analyst is tasked with building a data warehouse or a data mart with tools such as SQL Server or SSAS is really not ideal mainly because most are not really taught to analyse data in the same way you are modeling it. I would say a good majority are looking at very denormalized datasets in a very flat view. Everything that happens to get to that final view is handled by the IT team with the help of the business users helping define the business requirements.

    Does this mean the guys behind the scenes can't come to the front? Not at all. This really depends on you. Me personally, I got to where I'm at by inserting myself into the front-end of the conversation. I try not to let lines in the sand define my role and what I want to do inside an organization. That means, as a data architect, I've filled the role of being just a data analyst, I've had conversations with clients to help better understand and implement their business requirements while also working behind the scenes being support for the business users who are facing real business problems. Therefore, today, I have the unique opportunity to switch between both in my role, which allows me to work on all ends of the equation.

    As it stands however, most developers are not the ones asking the questions of the data. This is what the data analyst or data scientist is doing. Most of us on the backend are trying our best to support those questions. The reason for that is because most of us are not the ones working with the client. We are not representing the end user -- the data analyst is. Again, that does not mean you can't, but I've found more enjoyment with being side-by-side with the data analyst with the client where we are both defining the questions and answers together as one cohesive unit versus me being out the loop until a ticket comes by my desk. Maybe shooting for similar may help you a great deal. A lot of organizations are starting to see the benefit of working side-by-side versus in silos in this area.

    When it comes to the tech, this all depends. I personally don't think it's wise to get locked down to any one piece of technology if you work in BI. This means, switching between SSRS, PowerBI and Tableau should not upset you. It's going to happen because the competition is fierce right now and many companies are finding it hard to pick a tool that everyone can use. You should be about the data not the tools in this profession. This does not mean you shouldn't advocate to use the right tools for the job, it just means if you find yourself getting upset because you have to use SSRS over PowerBI, then your passion for data is likely not as big as you think it is, and passion for data and solving data problems is key in this role.

    Lastly, on your Azure, USQL and BI Stack questions. This just depends. Like above, I wouldn't try to get locked into anything because the landscape in this area is constantly changing. I wouldn't stress learning either or as much as you think you need to. I have yet to meet anyone who is good at SSRS who could not pivot to Tableau or PowerBI. The same is true for T-SQL to U-SQL. There are certainly cases for people going from say PowerBI from a point-and-click interface to more hardcore SSAS and SSRS development, but the point is still the same. Most can pivot. It's going to be much harder pivoting a data analyst to a data architect than it is a data analyst pivoting from PowerBI to Tableau.

  • You mention IT and Strategy vs. the Business.
    The Business is using PowerBI to address from what I see as IT not being able to create insights fast enough to suit them. And you note how the more complex the isolated solution is, the more likely it will fail over time.
    Is there any support from the IT side to define a true Data Warehouse that will tie things together better? And then place ideally 1 cube on top of it to expose to the users?
    The 1 cube would mean that the data would be much more normalized and all many measures to easily be placed next to each other. A big plus is that if multiple users are using the same cube, they will all get the same results. 

    Part of what you describe is far too common - the idea that if you give all the users self service tools, it solves everything.
    Reality in most enterprises is more of a mix - the bulk of data used resides in a more structured source, with business rules enforced in creation of dimensions and measures.
    KPI's can be built to serve the bulk of the needs, with ad hoc filling some gaps, and some Power Users able to help give IT direction for future expansion.
    What direction the company heads - a key is Business and IT being able to get together and being able to come up with a list of what is working well (and not so well) for each, and come up with a 1 or 2 year plan to present to upper management. 

    Both IT and Business need to be able to work together toward similar goals. Clashing and not creating solutions never works. The divide can easily become greater as IT is more measurable for time. You may stage some data for consumption, and it may have taken you a week to get it into production. From the Business side, they only count the 5 minutes to create the report. And since most in the business creating reports have other job titles, they do not separate out any development time. It could be 4 hours, but if they say it was 5 minutes, it is 5 minutes.

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

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