How big should your software be?
Best-of-breed – part 2
In the previous post, I talked about the extremes of a spectrum of enterprise software architectures: from large monoliths down to microservices. tl;dr Monoliths are potentially simple solutions but inflexible; micro-services are very agile but come with architectural complexity. At the end of the post, I touched upon the question of whether simplicity and flexibility were of equal value and, hence, if the trade-off was linear.
It seems fairly likely that this model is not correct – there will be some Goldilocks zone in the spectrum, where the flexibility is enough and the complexity manageable. Of course, that sweet-spot will not be universal: the size of the internal technology team, how specialized the outcome is, the market and a host of other factors will come into play.
In this post I am going to explore a framework for modelling the payoff and take some best guesses at how that applies to some example scenarios.
A generalized framework for modelling payoffs
The examples that I will explore in this post are imaginary; they are designed to illustrate that there is not a one-size-fits all solution, nor a paint-by-numbers exercise to find the solution for you. That said, there are aspects that I think are generally applicable and that should be considered:
- What is your objective and how are you measuring it? OKRs can work well for this.
- What are the attributes of a project that will influence the objective(s)?
- For the decision you are trying to make, how do those attributes play our between the extreme cases?
While you should know point one and be able to intuit point two, the final one is tricky and requires work. To effectively describe the landscape, you are likely to need to produce a model in a spreadsheet and put some numbers in. You can guess the numbers to start but it’s worth finding contacts in similar organizations who are friendly enough to share their experiences and help you refine your model.
In the following examples, keep the 3 points above in mind and consider them in the context of each case.
Greenfield startup – limited resources, both in time and budget
In this case, the biggest constraint may be budget. Where you do have budget to spend, you need to avoid one choice closing off other low cost options elsewhere in the stack. The trick will be to find an inter-operable set of software where no single pieces blows the budget. You probably won’t want to pay for engineers where you don’t get differentiating value, either, so the integrations need to be simple or out-of-the-box.
|Objective||Build a functional system within budget|
|Key result||Project total cost of ownership less than X|
|Influential attributes||Licence cost and team size|
Here you can see the need to avoid expensive solutions – which will often rule out large enterprise suites – and, equally, you will not want the overhead of a committed team. If you can, buy best-of-breed where it differentiates you and open source or consumer-grade where it doesn’t. You will also want to plan your team size very carefully; while the steps in the illustration above are purely figurative, as a small company the impact of each FTE will significant.
Well funded new venture – trying to scale rapidly
If you have taken investment to scale faster than the competition, the cost of delay far outweighs financial outlay (at least within reason). You’ll need to get the commodity stuff out the way quickly then focus on your differentiator. Bear in mind – you might need to adjust course or even pivot, so don’t get locked in!
|Objective 1||Get out an MVP and gather usage data|
|Key result 1||Project delivered in less than X days|
|Objective 2||Test-learn-iterate to achieve product-market fit|
|Key result 2||Deliver second iteration in less than Y days|
|Influential attributes||Initial delivery time and time to change some functionality|
Some kind of SOA will allow you to adapt to changes as you try and achieve PMF: the big hump in the left of the “Time to pivot” wave indicates the risk of getting a single, inflexible solution for everything. The finance, in this case, is opening up the width of the Goldilocks zone: with enough budget and motivation, you could go all the way to true microservices.
Established company – fighting to get off a crippling legacy stack
The organizational overhead of a move away from a legacy stack can be paralysing. It’s a tough pill but you’re going to have to swallow it.
The OKR is much harder to define in this situation. It could be any one of many, For the purpose of illustration I will chose one possible OKR:
|Objective||Accurately track customer data throughout the enterprise|
|Key result||Reconcile Web Analytics with Single Customer View with an error rate of less than 0.01%|
|Influential attributes||SCV de-duping accuracy, data integration reliability|
A solid architectural strategy will be integral to success and without it the project risks spiralling into chaos. Plan your architecture wisely – hire an FTE to own it, if you don’t have someone already. Something well structured like an event-bus pattern is a good place to start, followed by a multi-stage migration plan that minimizes risk.
There are going to be a lot of requirements in a project like this as, if nothing else, it’s difficult to get agreement to drop BAU functionality in a large organization. That means a single monolith doesn’t exist. You might consider a suite, for some areas of the business, but make sure the vendor is a safe pair of hands.
Failure here is needing to do a large re-arch again. What you build now should last for at least 3 years and the architecture should be designed to live a lot longer than that.
As called out in part 1, the monoliths are spread too thinly to realistically achieve a best-of-breed status for any of the functions you need but, at the other end of the spectrum, if you self-build everything you will never catch up with the attention-to-detail and resilience that a vendor will have finessed over years and multiple clients.
The bump on the right hand side of the “Integration reliability” curve is for true microservices, and is debateable. I believe that there are enough engineers out there who are enthusiastic about micro-services that the right team will be likely to produce a more reliable network of services because they will spend a lot of time thinking about them. Microservices inherently make you consider integrations, whereas that is less of an emphasis if you have non-mission-critical integrations between a small number of self-contained solutions.
To conclude the second post in this series, I want to reiterate the sentiment that there is no right size of software. Small services work well for some companies, large monoliths have their place too. The prevailing truths are:
- With a little analysis you can identify which style of software will minimize the risk for you, as a buyer
- The specialists near the middle of the spectrum will have the best quality solutions, as long as their market is large enough and healthy enough to support their growth – these are the best-of-breed solutions
If you have taken the decision to look to the middle of the spectrum – avoiding both atomic microservices and all-encompassing monoliths – the next question is how do you decide which functions live together. In the final post in this series I will focus on that question and explore how a separation of concerns can help keep systems operating effectively over time.