The fundamental point of this ramble is this – most of you worrying about Disruption and Innovation have literally no idea what is round the corner and all your efforts are a probably an epic waste of time. Yes, this is a “the machines are coming!” post.
To give a little human context, on Friday Night after a couple of decent glasses of Red I got into a discussion with the BI Monkey’s other half about how her employer was chasing innovative customer experiences, vision and so forth. This set me off on a bit of a tangent on the scale of Corporate Vision as earlier in the day I have been reading about Elon Musk’s vision to get humanity to Mars, which eats most corporate visions for breakfast in terms of sheer breadth of ambition and scope. On the way got side tracked into AI (due to reading this earlier in the day). These coalesced over the weekend into this slightly rambling post.
One point which I will totally fail to address but want to think more about is – if we create a true intelligence – why is is Artificial?
Disruption and Innovation you are (possibly) smart enough for
There are three rough classes of AI. The first of which is Artificial Narrow Intelligence (ANI). Which means smart, but within very narrow boundaries. For example, my car has adaptive cruise control and though some tech voodoo is smart enough to be able to match its speed with the vehicle in front, apply emergency braking if needed and warn me if I stray out of lane. This is all very spooky on the first use but very quickly becomes something to switch on by default as I realise the car pays more attention to traffic than I do. Note I am not one of the majority of drivers who think they are better than average – I am definitely not that great and would rather a robot was in charge. Driving is hard and stressful, especially on busy roads (long country drives are a different story).
Anyway, the point is that the car is a way better driver than me, it’s smart, attentive, doesn’t get annoyed by the jerk in front cutting in and has absolutely no understanding of why it is going where it is going, what a sandwich is or how to play chess. It has a Narrow focus and is unlikely to move out from those guide rails.
This form of AI can be disruptive as we understand it. Truly autonomous vehicles are going to disrupt our economy like you wouldn’t believe and we are less than 10 years away from it now (Volvo have just stepped up and said they will accept liability if their self driving cars crash). Innovations like Uber’s approach will leverage these disruptions.
ANI however is a limited threat as it still needs a lot of help from us humans to be designed, given a purpose and boundaries, yadda yadda. At some point – currently estimated at around 2040 (give or take 10 years) – we will create our first Artificial General Intelligence (AGI). Which is AI that can learn, set its own boundaries, solve general problems and no longer need handholding by us. At this point you can pretty much forget Innovation. The machines will largely be better at solving problems than us. Our best bet is that we can at least ask the right questions and still get some answers that a standalone intelligence cannot pose or use by itself.
The Disruption that is caused by the ability for us as a species to create an on-demand intellect to address problems will be that – as an economic resource – our value will plummet. A machine intelligence will be able to answer thousands of questions at once, have perfect recall and access to more data than we can hope to ingest in our lifetime and – best of all from an economic perspective – will have marginal input costs (it won’t need pay for a start) and no issues with motivation.
There will be a brief burst of innovations as people pose interesting problems to these new intelligences and apply the solutions, but try having competitive advantage when you can ask your AI how their AI solved a problem and you get an answer in seconds. R&D lag is gone, specialist expertise and accumulated experience is rendered worthless.
Then of course these AGI’s will take the next step.
The Disruption which will make your Innovation irrelevant
The next step in the scale is Artificial Superior Intelligence (ASI). This is where an AGI is smart enough to make its self smarter and exceeds our intelligence altogether at a point known as The Singularity. At this point all bets are off. The ASI will be able to solve any problem we throw at it, create and solve new ones we weren’t even aware of and either drive us to extinction or gently herd us into the future in ways that will boggle our tiny little minds. The economy as we understand it will cease to be relevant so at least you won’t have to worry about your job.
So, we have to hope that we get Multivac or The Culture. The alternative is less about the ASI being hostile, and more about it being as indifferent to us as we are to a microbe. We may not consciously set out to destroy a microbe, but we may do so through our actions because we do not consider the microbe as we act.
Are we all going to die, BI Monkey? What should we do?
The safest course of action is to transfer all your money to me immediately and … I haven’t thought about step 2. Perhaps take more of an interest in this subject so we can be better prepared for the coming changes. We still have 20 years to Disrupt and Innovate like it matters in the meantime.
A quick snippet on the following scenario. I had daily data of users sessions in a system and wanted to know in a given period what the maximum number of unique users on a single day was. My data looked like this:
A user could connect multiple times per day, so I needed a DISTINCTCOUNT to get unique users. However for a given period I needed to know this per day. So for the period I needed to calculate the number of unique users per day in that period – which meant I needed to create an interim table using SUMMARIZE.
“Logs” is my source data table. “Session Date” is what I am grouping my table by to get the results per day. The context of the period I am looking at (be it year, month, quarter, whatever) is managed by the date filters I apply to the table. “UsersPerDay” is just the name I assign to my measure, which is the DISTINCTCOUNT of the User field.
What I will end up with is an interim table which has – per day – the number of distinct users. Though it will not be materialised, in memory it would look like this:
Then, to get the Maximum in a day for a period, we just need the MAX of the the UsersPerDay in this table. As it’s an expression, we lean on MAXX:
And there we have it! Note in MAXX the Expression we use to get the MAXX of is our custom “UsersPerDay” we created in the SUMMARIZE function. Intellisense won’t pick this up as it’s not part of the model but the formula works just fine.
I got to use Datazen for the first time in anger with a client this week, and my experience was a bit of a mixed bag. There are elements of it which are neat but a fair few niggles.
Things to love
It’s pretty. The simple visualisations mean it is easy to create a nice looking, uncluttered dashboard with minimal fuss and tweaking. The responsive design means cross device functionality is pretty good and looks nice. It’s also quick to build and change content.
Quick learning tips
First up, let’s get some practical learnings shared:
Use views or stored procs behind your data if hitting a SQL Source. Datazen has no query editor (just a big text box) and doesn’t always handle parameters gracefully. Plus debugging is a pain as error massages are often less than helpful (e.g. “Data Preview Failed”)
Set report friendly field names in you query as you can’t always manage them in designer – sometimes you can, sometimes you can’t.
Selecting the ‘All’ option on a Selection List Navigator sends back ” (empty string) as the parameter value to the query, so handle that rather than NULL.
Now, some major drawbacks:
Consistency of cross platform behaviour is not great. I found some drillthoughs didn’t work on iOS or Android. Windows 8 seems to be the go to client. It’s not fatal but for fussy clients it’s a hard sell that this cross platform tool doesn’t work as expected.
The Win 7 Publisher app is unstable, buggy and seems to have features missing – such as proper configuration for report drillthrough. It’s only been around a few weeks so it’s forgivable but if you have to use it seriously, make sure you have a Win 8 client somewhere to do your development work on.
The charting is actually quite limited. There’s no stacked bar, for example. Line charts can only be by time. Labeling and colours are pretty hard to control, often rendering components useless. A great example is the category chart (bar chart) – the renderer will sometimes decide not to display category labels – which then means you just have a nice picture of some bars with no context as to what each one is, like this:
Finally some irritations:
These are some of the things that got annoying as I used the product – not an exhaustive list – and small enough I’d expect them to be fixed relatively soon.
You cannot update columns on a grid component if the underlying column names change – you have to rebuild component (a small task but annoying during development)
You cannot set the Low/Neutral/High ranges for gauge columns on indicator grids so they match settings for other gauges
You cannot align numbers – and they are aligned left which is not good dataviz practice
There is no handling for outliers on heatmaps so one extreme value will screw your shading
You can’t cascade drillthrough to a level below
The data preview after creating a data view has no Scroll bar so if there’s a lot of fields you can’t see them
There are maps provided but you have to work out how they are keyed yourself so you can connect your data (to be addressed in a future post)
You can’t “oversize” the canvas so phone users can scroll down.
Nobody’s using it – or at least talking about it – so help is hard to find.
A lot of irritation boils down to “I want to set that but I can’t”. This I’m sure is partly design, partly product maturity.
After a week with the product I get a real sense that it’s not even a v1 product yet. Maybe v0.9. There’s lots of niggles in the product – and not just at the back end where users can’t see them. I could tolerate the back end weaknesses if the end user experience was great, but there’s holes there. Still, there’s a lot of good that can be done. It’ll be interesting to see how it fares given PowerBI has such a huge feature overlap.
One of the best changes in SSIS 2012 was to create the concept of a Project Connection – a connection manager that can be used across the whole project instead of being limited to the package scope, meaning you had to recreate and configure effectively the same connection in every single package you have. This feature is great… when you are starting a new project.
However a recent task I got handed was to migrate a 2008 project to the 2012 project model. All very sensible, to ease maintenance, eliminate XML configurations and generally bolster security. Then I got to work….
Converting a Package Connection to a Project Connection
Ah, the easy part. Pick your connection, right click, convert to project connection and … ta daa! You have a project connection!
Now… what about all the other packages?
Pointing every other Package connection to the Project connection
This is a little harder. The good bit is your project connection will appear in your available connection managers. The bad bit is there is no way to tell the SSIS designer to use this one instead of your old one. You can either manually repoint every data flow, Execute SQL, script and whatever other task happens to be using the package connection to the project connection – easy if your package is small and simple – or get X(ML)treme! Fortunately thanks to this post by Jeff Garretson I was reminded that SSIS packages are just XML, and XML can be edited much faster than a package using the designer. Jeff’s post only resolved how to fix up the Data Flow – I had a pile of Control Flow tasks to fix up too – so here’s how to get it done without hours of coding.
Step 1: In designer mode Get the Name & GUID of all Connections to be replaced and what to replace them with.
You can get this from the properties window when you have a connection manager selected in the SSIS designer:
Step 2: Switch to code view and replace all Data Flow connections
You can find where a package connection is being used in a data flow by looking for the following in the XML:
Agile methodologies have a patchy track record in BI/DW projects. A lot of this is to do with adopting the methodologies themselves – as I’ve alluded to in prior posts there are a heap of obstacles in the way that are cultural, process and ability based.
I was discussing agile adoption with a client who readily admitted that their last attempt had failed completely. The conversation turned to the concept of the Zero sprint and he admitted part of the reasons for failure was that they had allowed Zero time for their Zero sprint.
What is this Zero sprint anyway?
The reality of any technical project is that there are always certain fundamental decisions and planning processes that need to be gone through before any meaningful work can be done. Data Warehouses are particularly vulnerable to this – you need servers, an agreed design approach, a set of ETL standards – before any valuable work can be done – or at least without incurring so much technical debt that your project gets sunk after the first iteration cleaning up after itself.
So the Zero Sprint is all that groundwork that needs to be done before you get started. It feels counter agile as you can easily spend a couple of months producing nothing of any direct value to the business/customer. The business will of course wonder where the productivity nirvana is – and particularly galling is you need your brightest and best on it to make sure you get a solid foundation put in place so it’s not a particularly cheap phase either.
How to structure and sell the Zero sprint
The structure part is actually pretty easy. There’s a set of things you need to establish which will form a fairly stable product backlog. Working out how long they will take isn’t that hard either as experienced team members will be able to tell you how long it takes to do pieces like the conceptual architecture. It just needs to be run like a long sprint.
Selling it as part of an Agile project is a bit harder. Because you end up not delivering any business consumable value you need to be very clear about what you will deliver, when you will deliver it and what value it adds to the project. It starts smelling a lot like Waterfall at this point, so if the business is skeptical that anything has changed, you have to manage their expectations well. Be clear that once the initial hump is passed, the value will flow – but if you don’t do it the value will flow earlier to their expectations, but then quickly after the pipes will clog with technical debt (though you may want to use a different terminology!).
A couple of times recently I have come up against requirements which have required some fairly complex logic to apply security. One involved some fairly gnarly relationships coming from multiple directions, the other involved grinding through Hierarchies from parent nodes down to permitted viewable children.
The problem with both cases is that though the logic can sometimes be written (albeit usually in an ugly as hell manner) – the functions needed to do so perform atrociously. For complex relationships you are obligated to take in context after context, changing filters and doing all sorts of DAX voodoo. As we know by now, avoiding relationships is good for performance. Hierarchies can be managed through the PATH function, but it’s a text operation that is far from speedy.
Let’s give a quick example of some complex security – consider the below data model:
Here the security controls who can see what has been spent on a Task in the FactTable object. How can see what depends on their Role and/or the Unit they are in. There is also a 1:many relationship between a person and the login they can use.
So for dynamic security you need to navigate from the User Id to the Person and assess what Unit they are in for the Unit based permissions. You also need to assess what Role they are in to get the Role based permissions.
I took one look at this and shuddered at the messy DAX I was going to have to write, plus how terribly it would perform.
Do it in the Cube? Yeah Nah.
So I thought “Yeah nah” and decided the cube was the wrong place to be doing this. Ultimately all I was trying to get towards was to pair a given login with a set of tasks that login would have permissions against. This is something that could easily be pushed back into the ETL layer. The logic to work it out would still be complex, but at the point of data consumption – the bit that really matters – there would be only minimal thinking by the cube engine.
So my solution enforces security through a role scanning a two column table which contains all valid pairings of login and permitted tasks to view. Very fast to execute when browsing data and a lot easier to code for. The hard work is done in loading that table, but the cube application of security is fast and easy to follow. The hierarchy equivalent is a pairing of User Id with all the nodes in the Hierarchy that are permitted to be seen.
As a final note, for those non-Aussie readers the expression “Yeah nah” is a colloquialism that implies that the speaker can’t be bothered with the option in front of them. For example: “Do you want a pie from the Servo, Dave?” “Yeah nah.”