Creating Thriving Digital Platforms Built for Innovation.

Good morning class! Happy to see so many faces here today. Please have a seat, and if you haven’t already read part 1 of this article series, I highly recommend it. You could probably follow along in this one without having read the previous one, but why risk it?   

Now that we have that dorky introduction/cross-promotion out of the way, let’s get to the good stuff. Last time I promised you “a nitty-gritty collection of battle-tested tips to get you going on your journey, whether you’re a team starting a new product or a company in need of an update of your system”. Today I’m here to fulfill that promise. Without further ado, I give you today's 4 tips that are loosely about the planning phase of a project:

Despite the harsh title, this is the fuzziest point, so forgive me if I sound like a bit of a hippie at times. This might be the most important tip in this list though.  

Before you do anything else it's crucial to look at the way you reason about your platform and shift your thinking around it: Your platform will not be static anymore. It will keep evolving. It will never be finished. Take a minute to let that sink in if you need to.  

This way of thinking can be very unintuitive at first - we’re used to (and find comfort in) things being done, finite and static. The best-before date is a feature of the material world. This used to be the case with software as well. We treated software a bit like a car - we bought it, we drove it for a while, sometimes we fixed it up, then we got a new one.  

Nowadays it should be treated more like working out - it’s a process. We go to the gym regularly; we do a lot of exercises for overall health, and then a couple because we aspire to be more than we currently are. We focus on different areas based on our interests. Sometimes it’s leg day. Sometimes we skip leg day because the back needs more attention. If we stop going to the gym we get out of shape. We’re never really “done” in the way we are with many other things. I rarely work out myself, being a bit of a couch potato, but I’ve heard that this is the way the gym works.  

The market will never finish transforming. Your competitors will never finish existing or popping up. Your platform will never be finished as well, so that’s a good thing.   

All right, so the thinking has shifted, and we are comfortable with a more “liquid” view of our platform. But how do we prevent it from spinning out of control, starting as a, say, bookkeeping solution and ending up being an e-commerce platform for hamburgers? Well, first of all, you should ask yourself if it makes sense for your business to follow your customers (or competition) in that direction or not. Ideally, they should only be used as a guideline, informing but not controlling, your main tool of navigation: your vision and goals. Without a clear vision of your own you just end up chasing your competition. Being reactive is good - being proactive is better.  

Goals should be set on a business level and a project level. It should be a mix of long-term, short-term, hard, and soft goals. A good starting point is to discuss the questions listed below. The outcome of the discussion should be a set of goals that range from concrete (e.g. “We will release a new minor feature every month”) and abstract (e.g. “Our product should always enable communication in exciting ways”). Try to define as many goals as possible. Dare to be both mundane and visionary.   

• What value do we give to our users?  

• What value do we want to give to our users?  

• What do we need to be able to achieve this?  

• What do we want to achieve with our microservice architecture?  

Group your goals in long-term and short-term. The long-term ones are your vision, and the short-term ones are the steppingstones there. Also remember that goals are not rules: Healthy ones change over time - but a good rule of thumb is that the further away a goal is, the slower it should transform.  

This looks a little bit different depending on if you are splitting up a monolith or starting up a new project, but the core idea is the same - you need to know what work lies ahead of you. Many have headed for the land of microservices and returned with a tangled mess (or even worse: something semi-monolithic), just because they didn't plan. You need to have a plan before you start working. This might seem obvious but is a more common error than you think.  

The easiest way to do this is to start by defining all the functionality you will need or already have. Sort it and categorize it. What can be combined? What shouldn't be combined? What parts are crucial and what parts could wait? What is unknown and how can it become known? Take these learnings and define what microservices you need.   

When you know what you need you can start mapping out how all the services should interact with each other. At this stage you might find that you need to change the services you defined or add new ones. That's completely fine. Context has importance and it does change the demands of your architecture. Don't rush this process.  

By the end of this you should have a fairly good idea of the work ahead of you, maybe even start forming some kind of action plan on what order these services should be built in.   

During this process it’s also crucial to make sure that everything is connected to the goals you defined earlier (because you did listen to my previous tip and set up goals, right?). This alignment of services and goals doesn’t end here though. The most important thing to enforce, is that everything is still in alignment months down the road when someone higher up presents you with the inevitable demand of “Hey, [stakeholder] needs [random specific and unrelated feature] by the end of the week. Fix it”. This is the moment you’ve been waiting for: get the planning out and motivate why it’s a bad idea and how it can be modified into a good one instead. Then pat yourself on the back. You fought to steer the ship in the right direction, and you did it in a constructive and fact-based way. You did good.  

A fairly common mistake in microservice-land is to make all services either too general or too specific. But not all services are created equally, and that's a kind of beauty with this architecture. You can design the service in whatever size and ambition that fits its purpose.  

In some cases, you find that you have many small specific services that could easily be combined into one generic service that in turn could open up a new set of possibilities that used to be obscured by the fragmentation. This generic service can now be used in multiple places which means a lot less code to maintain.  

In other cases, you simply can't go generic. Maybe you don't know enough about the context or future? Maybe it's a question of budget and focus? Maybe you're experimenting with a new solution on the side and need to prototype a couple of vastly different routes? Maybe you just want to try out some new internal processes? It might even be all of them.  

Use your newly found freedom and flexibility to figure out what works for you and your system, there are no absolute truths here. Just make sure that your chosen specificity is a conscious choice not only relevant for your codebase but in the context of your business as a whole. 

This is probably the heaviest article in the series, but at least you now have some tools to get started with the planning phase. If you hit the gas as soon as this article is published, you might be done in time for the next one, where I’ll be talking a bit more about production-oriented day-to-day stuff, but please, don’t stress it. Let it take time, a good house is built on a solid foundation, quick is not always efficient, etc. After all, the planning phase doesn’t come as often as the production one, so cherish the moments you have together while you're in them.  

As usual: take care and remember to hydrate and stretch your legs once every hour. And good luck with whatever you do that made you interested in this blogpost in the first place.  

See you in part 3!