I was recently involved in work to design and set up the architecture for the SAS Global Hackathon, and especially setting up the SAS Viya sandboxes for all the teams. My main area of work—and interest—is analytics deployment, so it was interesting to see a rapid deployment and operational use in action. There were several user experience design factors that were considered in the deployment. You can find a detailed technical description of my work done for the Hackathon in this blog but here’s what I learned from the experience.
- Open source integration was a key requirement for users
Users had some very important requirements. First, they needed open source integration with the sandbox. We provided them with code that would enable them to access the sandbox from Python or R-Code. We know that easy and robust integration of different technologies is essential for hackathons. However, it can also be important in everyday analytics deployments too. Data scientists often have different preferences for programming languages, but still need to be able to work together, and you need an environment that facilitates this.
- It is essential to create trust in the environment
We wanted hackathon participants to be able to get their data into the sandbox easily. Each team therefore had access to a Microsoft Azure Storage Account. We also carefully considered the rules for sandbox access, including firewall rules, whitelisting IP addresses, and authentication. These options meant that participants were confident about using the sandbox. This created a level of trust that was essential for success in the hackathon. This is very definitely a lesson that can be applied more widely: users need to be able to trust their environment and know that it is safe to use.
- Flexibility can be embedded in several ways
We designed three types of architecture to provide the right environment for different types of use case. This allowed us to support multiple use cases without having to create bespoke environments each time. To control costs, we switched the environments on and off automatically each day. However, we added flexibility by encouraging teams to email if they needed access at different times. We could then extend the time, or change the opening hours. The use of automated switching made life easier for the support team, and meant that we had time to provide the additional flexibility needed.
- Self-service analytics provides multiple ‘wins’ for both users and organisations
For part of the teams we opted for a self-service environment for many reasons. The first was pragmatic: with just a small team providing support, it was the most viable option to allow teams to do as much as possible for themselves. Analysts also often expect self-service, so it makes sense. However, another nice quick win from the self-service approach is self-education. We effectively gave hackathon participants a hands-on lesson in how a SAS Viya installation on an Azure Kubernetes Service cluster works. Self-service therefore provides faster learning—and so faster deployment—than other analytics environments. It also has the benefit that user acceptance is higher.
- Automation, like self-service, provides several benefits for both users and organisations
I mentioned the use of automatic switching to turn the environment on and off. We chose to automate several aspects of the environment for the hackathon, for several reasons. First because self-service tools for provisioning architecture are impossible without automation. We needed to be able to provide the environment without placing a big burden on IT operations. We also needed it to be both agile and efficient. Automation, especially with the cloud environment, offered both those aspects.
- Speed of deployment can also be a crucial aspect of analytics architecture
One of the key lessons for us—and for any architectures of analytics environments—was about the ease of providing SAS Viya sandboxes in the cloud. This is essential for a hackathon, where users need to get up and running fast. However, it would also be helpful to organisations or teams setting up analytical ‘sprints’ or demonstrations. It could therefore be used for conferences and events, or for students—or, indeed, many other uses across a wide range of organisations and sectors.
I think one of the most useful aspects of supporting a hackathon is that we, as architects, can try new things. As my colleague James Ochiai-Brown commented on Twitter, “Our experience shows it is possible to set up self-service provisioning for the latest version of SAS Viya on Kubernetes. It really works!” At the SAS Global Hackathon, it was certainly not just the competitors who were experimenting or learning.
