The implications are things that would have to be true in order for your characteristic to be achieved. They are levers you can pull in order to make progress.
Let’s work through an example
In part 2 I suggested that a Characteristic of a system that can support clients of any size is that API endpoints respond to requests the same amount of time for clients of any size.
What would need to happen to an existing SaaS in order to make that true?
- The API couldn’t do direct processing in a synchronous manner. It would have to queue the client request for async processing. Adding a message to a queue should be consistent regardless of how large the client, or the queue, becomes.
- For data requests endpoints would need to be well indexed and have constrained results.
- Offer async requests for large, open ended, data. An async request works by quickly returning a token, which can then be used to poll for the results.
Implications are measurable
How much processing can be done asynchronously today? How much could be done last month?
How many data endpoints allow requests that will perform slowly? Is that number going up or down?
How robust is the async data request system? Does it exist at all?
Implications are Levers
Progress on implications pushes your service towards its goal. Sometimes a little progress will result in lots of movement, sometimes a lot of progress will barely be noticeable.
Speaking to Implications
It is important that you can speak to how the implications drive progress towards your goal.
Asynchronous processing lets your service remain responsive. It doesn’t mean you can process the data in a timely manner yet. It sets the stage for parallel processing and other methods of handling large loads.
Before continuing on, try to come up with 3 implications for your most important characteristics.
You’ll want a good selection of implications for the next part – blockers.
We will explore what’s preventing you from moving your system in the direction it needs to go.