Fury Roadmap
Building a platform is an intimidating task.
First you have to provide a vision, something that helps people to understand the reasons for why the platform is necessary while also sketching out the vague shape of what will be delivered.
Then you need to build a technical roadmap to make that vision a reality, sketching out the bits and pieces that make up the platform, how they will interact and what sort of work will be required to make the whole thing a reality.
That's as far as I've gotten, and it's already been a hell of a ride.
I Live!
A good vision will paint a vivid picture of what the future could look like, if only you were allowed to build the system that you want to build. If you're familiar with the Good Strategy, Bad Strategy book, the vision is also known as the guiding policy.
A key part of the vision is a succinct description of some high-level capabilities; features or functionality that the system will provide to its users.
These capabilities are described with just enough detail so that the reader can visualise the value of the system, but not so much that they get overwhelmed and fail to see the forest for the trees.
An example of a high-level capability might be something like:
Migrations
Be able to effectively move a tenant from one shard to another
When you start building the technical roadmap, you need to break down those high-level capabilities into smaller pieces. They are still capabilities at that point, there are just more of them, describing the features and functionality of the system in more detail.
In a way, capabilities are similar to user stories.
A user story is an atomic unit of delivery, generally small enough to be completed in a reasonable amount of time (i.e. within a sprint or similar).
Capabilities are a bit bigger than that, and at the end of the day, each capability is likely to be delivered via the implementation of one or more user stories.
But there is still much work to be done before we get to user stories.
I Die!
Once you have even the vaguest handle on the capabilities of the system, you need to start thinking about how they will be delivered. That's where components come in.
A component is a technical thing, probably a software artifact of some sort (like a service). They are the sort of things that fit snugly into a technical architecture diagram.
Capabilities are necessary for describing what the system needs to do, but components are the how. The provide capabilities, sometimes by themselves, sometimes by working together with other components.
Components help you to figure out where the actual work needs to happen; what you need to build, what you should buy, what you need to adapt, etc.
Clearly identifying the components in play also drives the identification of the boundaries between those components and how they interact, which allows for the creation of contracts and interfaces.
Those delineations in turn allow for the work to be compartmentalised, just the same as it would be if you were fleshing out classes within a single software artifact. They grant opportunities for parallelisation or to involve additional teams and people in order to accelerate the overall delivery, while also helping people to understand how the resulting system could be used or integrated with.
The last benefit of having a clear and concise list of components and how they interact is that it generates a shared understanding between the engineers who will actually be implementing the system, so that they don't go off and build random things that don't slot together as intended.
You might think this is the point where you start getting into user stories.
You'd be wrong.
I Live Again!
Once you've got your capabilities sorted, and your components identified, it's time to start drawing things together into an actual roadmap and break the work out into phases.
A roadmap is basically just a sequence of what you're delivering and when you think it's going to happen. Most of the time you'll probably be wrong about both of those things, as no plan survives contact with reality, but as long as you balance the investment you're putting into planning against making things actually happen, you'll probably be fine.
Conceptually, the intersection of components and capabilities will result in projects, i.e. atomic pieces of work that deliver some sort of end-to-end value. They deliver one or more capabilities (or perhaps a fragment of a capability) by changing one or more components (ideally only one, but that's not always possible).
The problem is that if you just sequence all of those projects together and call it a roadmap, it might overload your stakeholders. I mean, if you frame your projects properly and name them well it might be okay, but as the body of work gets larger, that is less and less likely to happen automatically.
Don't get me wrong, you'll need to put all your projects together into an actual roadmap, but you should also add a layer of abstraction and define a set of phases that describe incremental value delivery and system maturation in a way that everyone can understand.
Each phase should have a name and a short description to give it a clear identity.
Each project will fit into a single phase, and every phase will have one or more projects that are required to be completed before it's done.
As an example, if you're building a platform to enable sharded services to easily manage their capacity, an entirely hypothetical situation of course who would do that, you might have the following as your first couple of phases:
- Capacity Observability - As a user, I know the state of my shards, understanding whether they are full or not
- Placement Decisions - As a user, I can rely on the system to make intelligent and balanced decisions about where my tenants should go during relevant workflows
- PROFIT!
Phases allow those who are not embedded in the day-to-day construction of the system to understand what is going on, while also allowing those who are down in the weeds to easily take a step backwards and put things into context.
I suppose at this point you could start creating user stories.
You know, if you want.
Witness Me
It might seem like the things I've described in this blog post happen sequentially.
- First you start with the capabilities
- Then you move on to components
- Then you define all your projects
- Then you bundle everything together into phases
That is very much not how it works.
When you're writing a technical roadmap, you'll jump backwards and forwards constantly, discovering new capabilities as you try to frame things into phases, finding out you need a new component as you think about capabilities, recognising that you've completely screwed up your list of phases as you talk to stakeholders and all sorts of other wonderful realisations that happen at the most unexpected and unpleasant times.
That's okay.
If you're delivering something meaty it's always going to be a journey filled with ups and down, twists and turns and tricks and traps.
And just like Max Rockatansky found out, there is no promised land at the end.
But things will probably turn out just fine all the same.
Member discussion