Learning by doing

I wanted to share some information about an internal project my team is working on. My team is a group of technical advisors that support our large ecosystem of Canadian Independent Software Vendors (ISVs) who build commercial solutions on our platform. One of our ongoing challenges is to understand all of the many technologies available to developers, not just the Microsoft Platform but in the full developer ecosystem. That is a tall order, and the idea of “keeping current” is a concept difficult to imagine.

We asked ourselves: How can we help each other to learn more, faster? Our theory is that by working together as a team, we can learn faster than by working individually. We wanted to go beyond just simple knowledge sharing. We felt that by working on a full end-to-end solution, encompassing some key technologies that we wanted to go deeper on, that we would have greater insight into those technologies, and maybe build up some empathy for our Independent Software Vendors that we support.

So it began late last month when we spent a day together, brainstorming what it would be that we would build, and what tools we would use to get the job done. Getting consensus on these key mission statements would prove to be almost as difficult as learning all the technologies, but in the end, we made some compromises to land on a solution we could get behind.

Horse and Cart: The What and The How

It is very unnatural to start with the “How are we going to build this?” question prior to the “What is it we are going to build”, but we were driven by the learning experience. That’s not to say we didn’t iterate back and forth over these two topics, but, I need to fully disclose that the selected technologies might not be the best tools for the job, but they are close, if not at least reasonable selections.

We focused on a few key technologies areas and tools that we wanted to use:

1. Internet of Things: Nobody questions that this emerging area is one we need to get our legs under. We opted to try out a beacon scenario as we had some Estimote Beacons on hand.

2. Cross Platform Mobile Development: We might have used Xamarin for this, but we felt we need to learn more about Cordova: Packaged HTML/JS apps, using our fairly new support in Visual Studio

3. Cloud Backed Services: Using Azure was a natural of course. Although we could have stitched together a bunch of individual services (Web Apis, service bus, notification hubs) we opted to go for the “Happy Meal” approach by selecting Azure Mobile services which will give us a multitude of features, CRUD storage, Web APIs, Push Notifications, and Authentication. We also opted to jump into our Azure IoT suite that will give the ability to capture sensor data – via the connection of the Mobile App, and process it with Stream Analytics.

4. Storage, Content, Analytics, Reporting: Mobile Services bundles relational storage with Azure SQL Database, amongst other options. This will suit us for a good chunk of data. But we also wanted to explore our new Office Graph APIs as well. Therefore, we decided to store some user provided content via Excel. This would avoid us building a content editing system. This might make a bit more sense as we get through the scenario. Since we are already investigating Office 365 integration, It made sense to provide analytic capabilities with Power BI as well.

5. What else? We opted to managed our project and source code with Visual Studio Team Services (formerly Visual Studio Online). We also want to spin the wheels on Visual Studio Application Insights on Azure to monitor our application performance and user behavior.

The How

A rough architectural diagram was drafted below. This may change, but for now, our vision has us moving in this direction.

The What

So what is it that we are building? We felt that we could leverage the beacons somewhere in our head office in Mississauga. Anybody who has been in our building knows that we have several digital signs throughout our office to beam content to our visitors. One area in particular is our elevator area. One problem is that our elevators are too fast for all the content. Sometimes we see something interesting, and before we are done reading it, we have to jump on the elevator.

With our app, users will be able to sync their phones to the content on the digital signs. A beacon placed outside the elevator will let the app know which sign they are near, and pull content relevant to what is being displayed on the sign. We may eventually tie into our existing content database, but we thought it might be neat to pilot getting content out of an excel file in Office 365 that is maintained by an administrator.

Unlike the simple display sign, in our solution, we can track user behavior and engagement levels, by sending messages to Event Hubs from the mobile app as users connect to the service and show interest in specific topics. We will experiment with Application Insights and maybe our Mobile Engagement service down the road to help analyze what content is resonating with people in these common areas.

What Next….

As we begin this project, we will continue to update you. So far, we’ve broken down our stories into a product backlog in Visual Studio Online, and we’ve begun proving out the individual concepts and will be stitching all of this over the coming months. We will be sure to update you on our progress, and highlight the individual technologies we are using and what issues we overcome along the way.

Comments

• Anonymous
  February 25, 2016
  Is there a website, twitter account or anything else that we could keep track and see the code/results?

• Anonymous
  February 25, 2016
  Great question Jorge. We do have an internal VSO project - but were considering publishing code to GitHub. Look for an update on the next update in this series for something like that. Thanks for the feedback. Barry