1. Design Broadly, Build Narrowly
Building a platform for the enterprise means supporting both enterprise and developer use cases. Although what you build for the enterprise user is in your control (by building the web application yourself), what a developer builds for their end users is not in your control. It's important to design for a broad range of use cases and create flexibility for third party applications while also keeping grounded in specific use cases and applications you want to build on top of the platform.
As an example, we built Box Metadata as a generic structured data store that knows nothing about Box files and folders (a platform) while also implementing metadata for Box files (a specific application) on top of it. If we wanted to just build a feature for the Box WebApp, we could have chosen a path of least resistance and added some columns to MySQL. We would have leveraged MySQL’s indices, filtering, sorting facilities and also leveraged our operational experience with MySQL. However, when considering that this data service has value as a platform, we had to anticipate that both enterprises and third party applications would want to store metadata. A fixed number of columns would really complicate the implementation and limit the power for app developers. We ultimately went with a separate MySQL instance storing JSON blobs for the metadata type definitions and key/value pairs, using JSON Schema for validation so that we can enforce types in the data we store.
Even further, since Box Metadata itself is a platform, we partnered with our own procurement team to build a Vendor Contract metadata template (a specific application of metadata) at the same time we were building the horizontal metadata capabilities (a platform). This let us use the specific application requirements to vet the general design for the platform and test our hypotheses about how things should work.
2. Platforms Are Powerful and Flexible. Choose wisely what to expose when!
The ultimate goal is to build a powerful and flexible platform for customers and partners, but you also want to avoid providing too much at once and getting locked into something that will be hard to change later. Especially with mobile applications, which are deployed in the wild and are hard to update all at once, you have to make every API change backwards compatible and attempt to be forwards compatible too! Increased usage also means more enhancement requests which then means a bigger contract in place between you and developers, which means more lock-in. The more you offer, the less able you are to evolve it.
On the other hand, having an API available can be an escape hatch. You can avoid requirements that are not mainstream or would result in a poor user experience. When customers have specific needs, requirements, and use cases, you can ask that they write their own apps through which they can define and meet their own processes and requirements. There's a lot of value in providing an API to let developers expand beyond your core use cases—you learn a lot from seeing what other people do with your platform.
3. Build Incrementally, Get Feedback, and Iterate
This essentially comes down to walking a fine line between exposing just enough but not too much in your platform, so you can focus your development on the most important use cases, while giving yourself room to iterate. Every time you make a major version change in your API, you will lose developers. Instead, deliver small bits of functionality in phases; provide just enough value without too much lock-in. For example, as we build out the API for Metadata we support CRUD operations for template instances but only read operations for template definitions. We will wait until later to provide create, update, and delete for template definitions as those will require us to also support programmatic data migrations which are much trickier to get right.
Building a platform is an incremental process. It's hard to anticipate exactly how enterprises and developers will make use of your platform, and your first iteration is unlikely to tap into the full potential of what you're building. To keep the iteration process moving and productive, get feedback whenever possible, and respond to that feedback. By developing incrementally and responding to feedback as you go, you can iterate your way to a powerful platform.
4. Create a Platform-first Mentality
Building a platform takes investment from everyone. If engineers are not all thinking platform-first, then you're likely wasting effort building a feature and later refactoring it into a platform capability. To change your engineering culture to be platform-first, you have to first align your technical and business goals to value delivering platforms instead of features. After that, you can tackle the more tactical issues, like making sure developers have the right tools and frameworks to implement consistent APIs in a scalable and distributed way. Defining best practices around endpoint design, versioning, authentication, authorization, paging, differentiating public from private APIs, rate limiting, backwards compatibility, and so on, will help developers more confidently design and develop new platform capabilities and APIs in a consistent way.
Help make the Box platform even more powerful! Join us.