Monday, December 17th, 2012

Rebuilding Box’s Reseller Program

By

This post is part of a series from the product managers and engineers who built the new version of our API. They’ll be discussing the design decisions and technical challenges that we faced along the way, so be sure to keep checking this blog every day this week.

Box recently announced a new partnership with Deutsche Telekom in which they will be selling Box as an offering in their new online marketplace.  While we’ve had a small number of these partners in the past, this partnership marks the beginning of a push to both work with larger resellers as well as increase the number of resellers of all sizes.

When we first started this new initiative, we realized it was the perfect time to go back through our existing code and see what needed to change to support larger resellers, what needed cleaning up and what simply no longer made sense with what we’ve learned from our current resellers.  Only a small amount of our currently scheduled development work is strictly necessary to support our new resellers, but we made the choice to sacrifice some speed to make sure we built everything the right way.

While the concept of offering reseller functionality is easy enough, the logic that goes on behind the scenes to make sure we provision new enterprise accounts correctly, keep multiple salespeople from attempting to make sales to the same company, bill the correct company once the sale is made and otherwise keep track of resellers is much more complex.  To make things even more interesting, since all of this code is currently in use and we are attempting to bring more resellers on while also rewriting nearly everything, we have to make all of these modifications in small pieces and also make sure that we keep everything backwards compatible in the process.

At a high level there are three main areas to which we are making changes.  We are changing the overall model of how the code flows, we are rewriting nearly all of the individual pieces including parts of the data model and we are adding additional functionality underneath.  The choice to rework the flow hinges largely on both our internal use of Salesforce as well as its rich feature-set for Partner Relationship Management  (PRM).

We previously allowed our resellers to log into an in-house made reseller portal that had limited functionality but would allow them to do things like provision an enterprise or edit data for an enterprise they previously created.  We then sent this data to Salesforce to allow coordination with our own sales team. 

In the new flow, we instead integrated with Salesforce to allow the resellers to perform all of the same actions directly through Salesforce PRM.  By doing it this way, we can eliminate some previously necessary manual work as well as allow for a richer experience for those partners using it.

Changing the ordering of the large pieces only requires rewriting how those pieces fit together at the edges, but while we were at it, we thought this was a good opportunity to do a large amount of code cleanup.  This includes a lot of things that fall into three main categories – bringing code up to Box’s current standards, modularizing and reducing code re-use and reworking our data model.

The first category includes a lot of sub-items.  For example, we are adding all new unit testing to the entire feature.  We previously had automated testing but while it covered much of the code, it didn’t cover everything and was sometimes a bit flakey and less robust than it could be.  Another big work item is to move all of the reseller APIs off of our V1 API to our new V2 API.

We are also working to increase code re-use throughout the rest of our work as well by creating new methods in Box’s middle layer framework we call our actions framework.  By adding to this layer, we are able to reuse the same code for both resellers as well as standard users.  For example, we can use the same code when a reseller creates a new enterprise as well as when one of our sales people creates an enterprise or even when a user signs up for one on our website.

The final piece of cleanup is the data model.  I won’t go into a lot of details, but at a high level, we had a few overloaded fields that were quite confusing, as well as some completely unnecessary de-normalization and some vast limitations – such as only supporting one sales user per reseller.  Our general rewrite provided a good opportunity to spend some time up front to consider all of our requirements and redesign a database structure that will be robust and flexible.

Now that I’ve mentioned all of our code cleaning, I want to also mention that we’re taking this opportunity to add a bunch of new and exciting features as well.  Some of them, such as allowing the salespeople in our reseller organizations to log into Salesforce, results in a vastly improved user experience.  Other improvements may not seem like much but allow for interesting opportunities – for example, we made it possible to use the resellers themselves as an authentication provider, so if I go to Deutsche Telekom’s website and log in to their marketplace, I can click on a button and be redirected to my Box account already logged in.

This project is one of those rare and exciting opportunities, where we have the chance to take a large, powerful system and spend the time to really consider design so that we can solve existing pain points, build for the future and otherwise find the best design possible.  All of our behind the scenes clean up work will make the pieces clear and appropriately modular so that when we eventually have to make changes they will be painless.  We were able to take an outdated system and turn it into something that is both robust and expandable so that it will work for our existing use cases as well as look to the future.

By

See all of Joy's articles.