The past couple of years, my kids participated in The Hour Of Code. If you haven’t heard about the initiative, check it out. Basically, a wide range of Silicon Valley titans teamed up to provide kids with age-appropriate introductions into the world of programming. It is a very impressive program and millions of students participated in it this past year.
As I watched my kids go through some exercises to move Angry Birds characters through a maze or to fight a battle in a castle, I was drawn to the programming interface provided. It is called Blockly. I hadn’t seen it before, but it was a terrific way for kids to learn to program. Why? Because it allows them to visually focus on the logic that they needed to create as opposed to the syntax details of any given language. I’ll first explain this concept in more detail and then move into how it can help us with analytics.
WHAT IS BLOCKLY?
Blockly provides drag and drop icons (that look like blocks of course!) that the kids use to complete a given Hour of Code task. Perhaps the task is to get an avatar through a maze on the screen. By pulling “move forward”, “turn left”, “move forward”, and so on, on top of one another it is possible to get the task done. Over time, loops and conditional blocks are introduced in the Hour Of Code exercises. For example, there is a block that says “IF” with a gap below it and then has a “DO” with another gap. Simply drop condition blocks into the IF/DO block to create your logic.
WHAT MAKES BLOCKLY SPECIAL?
While watching my kids enjoy their first programming experience, I had an “aha” moment. While the blocks and the logic the kids were building were all intuitive, I had no idea what programming language was actually being submitted behind the scenes. Furthermore, I realized that it didn’t matter! Any number of languages were capable of this simple logic and all Blockly had to do was to pick one and translate the block-based logic to the appropriate syntax. Converting to a different language wouldn’t change the user experience at all, but would be a matter of new conversion logic under the hood.
I loved the fact that my kids were learning generic programming and logic skills without getting bogged down into syntax details. After all, they needed to learn the concepts first and foremost. Once they know what they need to do and how the logic works (the hard part), it is easy to learn a specific programming language syntax to directly implement the logic.
APPLYING THE BLOCKLY CONCEPT TO ANALYTICS
I have always felt that the ability to grasp the logic required for an analytics process is the key skill set that analytics professionals require regardless of whether their job description is Data Scientist, Analyst, Data Miner, or something else. Translating the logic you’ve dreamed up into the specific code syntax of SAS, Python, or R is just a tactical exercise if you know what needs to done.
Unfortunately, with the recent proliferation of data platforms and toolsets, analytic professionals of all stripes are often in the situation today of having to log onto multiple systems to execute different pieces of analytic logic before bringing all of the intermediate results back together to finish the process. There is a rational reason for this. Namely, with the rise of big data, organizations are finding that different types of data used for different purposes are often better stored and processed in different ways. We have relational databases, Hadoop, graph/network oriented databases, a variety of NoSQL platforms, and more on the storage side and we have similar complexity on the analytic toolset side.
Assuming that analytics professionals will be facing the challenge of interacting with multiple platforms to execute their analytic logic, is there a way to get them back to worrying about analytic logic and away from worrying about multiple logons and multiple syntaxes? The answer is yes!
ANALYTIC LOGIC VERSUS SYNTAX
There is a lot of work in the industry today aimed at simplifying analytics processes by abstracting the complexity of underlying analytical platforms. One example is the Teradata Unified Data Architecture, which I like to call a Unified Analytics Environment. While I naturally know Teradata’s approach best since I work for the company, there are other organizations aiming for the same goal. The future is heading in this direction.
The objective of these new architectures is to allow a user to enter his or her analytic ecosystem from a given entry point and to have the ability to execute all logic required across all platforms with a single syntax from that single entry point. Under the hood, a lot of translating and passing of work requests in various syntaxes may be required, but the systems will automatically take care of that for the user.
The power in this approach is that same as that in Blockly. Namely, we enable our analytics professionals (and business users too!) to focus on the logic they require without worrying about differing systems and syntaxes. This can greatly accelerate the creation of new and impactful analytics processes. After all, wouldn’t you rather solve another problem instead of translating yet another part of your logic into yet another specific syntax?
As the complexity of your analytic ecosystem continues to grow, make sure that your organization is thinking ahead about how to simplify it for users. Personally, I like the Blockly concept and bet that your people will too.