You’ve been building your service for a while now. It is out there and quite successful. Now you would like to make more services. And you notice that these new services would need some of the functionality of your existing service. Maybe it’s an SDK for your mobile apps, or a framework for your website, or a microservice for your backend systems. So you decide to make this platform into an independent component that can be adopted by future services, reducing their development time and unifying your services.

I have seen such a process happen a few times during my career, and I feel like I have a pretty good grasp of what makes such an undertaking a success or failure. So here is some advice in the form of simple rules on what to do to put you on the path to success.

Don’t Bother If You Have Only One Service

Maintaining a platform as a separate entity is always more work than having the functionality inside a single service. If you don’t have actual current plans to implement more services that could use the platform, just let the functionality live in your current service. Your service team probably already has a nice architecture with separation of responsibilities and they know best where the functionality should go in terms of that one service. Forcing the separation of the platform out of that would be just extra work that would bring no benefits if there is no other service in the horizon.

Choose the Platform Team Carefully

It is regrettably common to see platform design treated as any other development task. Something in Todo, to be picked up by whoever next has time. Don’t do this. Mistakes in the interfaces of a platform central to your services will cost immensely more than similar mistakes in a single service. They will force service developers into extra work, to write more brittle code, to uncertainties in what they can rely on the platform to provide. To avoid this, you should choose the most suitable people for the platform team, and to prioritize the platform work so that these people are available.

Who, then, are the most suitable people for platform work? They should understand abstractions to be able to create a clear, comprehensible interface to the platform. In general, they should know what makes a good API. They should understand versioning, since at some point the platform and services will begin evolving independently. And finally, they should be capable of refusing feature requests to avoid bloating the platform with irrelevant functionality. This is needed both mentally from the developer but also socially within the organization, as often it can be politically unwise to refuse requests from some people. If you want specific advice, your current development team is likely to know very well who are the most suitable people among them.

Extract Platform from Existing Service

A common way to implement a platform is to study the existing service, define the functionality that the platform should have, and begin implementing the platform from scratch. Then, when the platform is sufficiently feature-complete, a concentrated effort is made to swap the existing functionality in the service to use the new platform. In general, this is a mistake. It is rare that all the complicated functionality in the existing service was perfectly duplicated in the platform, so this will lead to a long period of implementing missing functionality in the platform and fixing difficult bugs in the already-deployed service.

A better way is to work within the existing service development. Sure, determine the platform functionality and design its interface beforehand. Do be ready to change this, though usually the basic design will be solid enough. But instead of implementing from scratch, refactor the existing service so that, piece by piece, the functionality that is supposed to be in the platform is moved into an isolated platform part of the service. This ensures that any bugs introduced into the platform are caught quickly during development by your existing service testing, and that the service will be in a good shape to use the platform when the platform is finally ready to be extracted.

Develop (at least) Two Services Using the Platform

You have your existing service, which is a perfect use case for your new platform in development. But you should still verify the viability of the platform by building another service using it, concurrently with the platform work or at least before the platform is released, whatever that means for you. The more different the other service is from your existing service, the better for platform validation, as it will show whether the platform design is too tied to your specific existing service or it truly is general enough to support your ambitions.

Furthermore, this other service should be a real service that you intend to deploy, not an example service written by the platform team to test their platform. You should absolutely have the latter as well, but it won’t be a true test of your platform’s viability. An example service written by the platform team won’t test how comprehensible the platform is to other developers who didn’t work on the platform. Also, while a typical example service is written to exercise all the platform functionality, it won’t do it like a real service would. In my experience, that does make a big difference, and a real service is going to encounter issues that the example service never would.

Collaborate Closely between Platform and Service Team

If you’re following the above advice, you have your platform team working inside your existing service team, extracting functionality piece by piece into the platform. Ideally, your service team developers would also have a pretty good grasp of the platform implementation. They would know the functionality extracted from the service, and it’s a good practice to involve them also in code reviews or such to spread the platform knowledge among all developers. When this process has advanced sufficiently, you will have your second service team trying to use the current platform in development, which should provide a good basis for their service even if it is not quite complete yet.

In this phase, it is crucial that your second service team works closely with the platform team. The original service team should be quite comfortable with the platform, as it is being extracted from their work, but the second service team is pushing the capabilities of your platform in development. They are the ones thinking up original uses for the platform, they are the ones finding service needs that are not covered by the platform yet, they are the ones finding the weird bugs that the original service never hits. So remember to have close constant contact between the new service team and the platform team to make sure that the requirements of the new service are taken into account in the platform design before you mandate it for your whole organization in the future.

Originally published at futurice.com.