In the last couple of months I was involved in a couple of consulting assignments where I had to understand the platform the team has built and give my recommendations. Platform is a broad term and it means different thing in different context.
In the first assignment, platform was about application development. So, it was about providing core services and making it easy to build new Microservices. The platform was built using Netflix OSS and Spring Boot.
In the second assignment, platform was mainly related to infrastructure and deployment side of things. Here, I was dealing with Kubernetes based platform that can run different workloads.
Platforms are difficult to build. They require constant time and effort to keep them running and meet end user expectations.
Today, I stumbled on a post from Box engineering team where they talked about things we should keep in mind when designing platforms. In this post, I am sharing key principles shared in the post and how these principles are relevant.
1. Design Broadly, Build Narrowly
From the post,
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.
This is the key if you want your platform to be suitable for wide array of use cases.
In the first assignment, one of the use case is to support admission forms of different university and colleges. The architect decided to build the core service keeping in mind the first university they wanted to onboard. This meant they build the service specific to a university. Later they discovered that different universities has different fields so their initial core platform service will not work. Ideally, they should have designed their application using metadata driven approach where frontend forms could be created from the metadata rather than hardcoding. This is the case where they designed narrowly. Hence, they were unable to build future use cases.
In the second assignment, the Kubernetes based platform had to support wide variety of workloads. The workloads could be traditional Windows batch based workloads that have to run in the datacenter to the modern Microservices based workload that can run in cloud. They spent a lot of time designing a hybrid platform that can support varying organization needs. For the first pilot they went with the stateless Microservices workload that is highly suitable for the platform but because they have spent time designing it for broader use case they are having relatively easy time onboarding traditional workloads.
2. Platforms Are Powerful and Flexible. Choose wisely what to expose when!
From the post,
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.
It is tough to achieve balance between being powerful and flexible. I see this constant tussle in my assignments.
In the first consulting assignment, they allowed users of the application to publish apps on their platform. They provide an inline editor where users can use the API to build custom apps. This is very powerful and flexible as users can solve their use cases which the platform does not solve by writing custom apps.
The big issue was that the API they exposed to end users is AngularJS 1.7 API. If you follow JavaScript world, you will know that most developers have moved away from Angular into React ecosystem. Because they exposed AngularJS 1.7 API to their users, they are know stuck with it. This is an inflexible design and giving them hard time attracting new developers.
Similarly, in the second assignment I found this constant tussle between power and flexibility. A platform based on containers is powerful and flexible as developers can choose any language ecosystem they want to develop their application. But, it becomes a mess very quickly as you don’t have expertise to run all the new technologies. To avoid this, one of our recommendation was to define a set of technologies that developers can use so that they have right amount of flexibility.
3. Build Incrementally, Get Feedback, and Iterate
From the post,
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.
Platforms take time to build as you want to get them right from the go. The result you don’t want is that your platform does not meet end user use cases. The best way to build platforms in an incremental manner. You have to define MVP for your platform and get that running in not more than 6 months. If you take more time then it might happen that your platform becomes outdated before people start using it. Then, you will be in race to keep updating your platform to latest version.
This I saw happening in my second assignment, they spent close to two years to build the Kubernetes based platform thinking about all the use cases and edge cases. It took them two years to get their first customer running on the platform. Because they were very narrowly focussing on platform they didn’t gave much thought to developer experience. They wanted to build the best platform with best storage, best networking, etc. that they gave little to the needs of developer who will consume their platform.
4. Write documentation
This is not part of the original list shared in box engineering team blog.
This I saw missing in both the assignments. We somehow don’t give enough importance to documentation which means we end up spending hours explaining the stuff we explained hundred times earlier.
In one of the assignment, we had to document the solution architecture so that we can make sense of their platform.
It is difficult to keep documentation updated but with a lightweight process you can make it part of your definition of done. Sooner than later you will have to invest on documentation so it better to start early. Usually, the best people to document are the people who developed the platform so make sure you give them enough time to document what they build. You will thank yourself later for doing it.
Shekhar Gulati 