Our Majestic Monolith: Part OneLearn about the context around our Majestic Monolith, including the project, our team and our philosophy.
Before I can tell you about our Majestic Monolith, and why we love it so much, some context is needed as technology doesn't exist in a vacuum. The context is what makes this the right pattern.
This post will set the stage to understand our project, our team and our philosophy. Given these three pieces of information we'll then dive into why we've elected to employ a Majestic Monolith as our architectural pattern (or lack thereof!) and why it has led to the highest level of success we could have possibly delivered on a project with the odds stacked wildly against us.
This particular piece of work is done for an organization that is lacking in information technology across both a CIO and CTO perspective. The organization is also incredibly risk averse (for good reasons). The project started approximately four years ago (2019) as a proof of concept and has evolved significantly in terms of its importance to the organization and impact it has on daily operations for a large number of individuals.
The project is the first bespoke, cloud-native application built and deployed. That means, it is the first application running in a real cloud, the first application that needs to be supported via an offering mindset and the first application that is a living, breathing organic capability. These make for a lot of firsts!
The organization is highly bureaucratic, with policies that are out of date and incongruent with modern approaches to technology and software development. From a Westrum perspective the organization is not in an ideal position to make a project such as this successful.
Given the nature of the receiving organization, the outcome for the project was highly predictable; failure! Really, the most likely outcome was that the project would not succeed. It could create a great opportunity for learning and understanding the amount and types of friction in the system that would prevent future projects from succeeding. It would also succeed in "failing" as a low dollar value project, versus failing for decades with a very high dollar value.
However, thanks to a product-market / problem-solution fit and organic adoption that can only be dreamt of, the offering grew to a significant capability in the organization.
Finally, the project has a well known upper limit of usage. It is not a web scale application and wouldn't ever need to be. The likely user base is in the low tens of thousands with an unlikely upper bound of low hundreds of thousands.
Our team is amazing. It is also very difficult to staff due to a number of macro and micro factors. At the high level, the tech labour market has been very competitive over the past several years. We're also tied to a contract that has a near-term known end date which dissuades candidates looking for stability. At the lower level, we must satisfy a number of very complicated criteria for each individual to qualify for the project. The net, we have to invest 10x into talent pipeline development and recruiting to hire an individual. As a small company, this takes a major toll and greatly limits the types of candidates we can hire and where we can directly compete.
Over the project we've floated between 5 (mostly) and 11 (recently) headcount with a large portion of junior members. This is in comparison to a compound annual growth rate of over 700% for our user base. We've grown users by a factor of 690x and our team by a factor of 2x.
Again, due to contractual obligations we have a defined set of roles we can hire for. They are mostly limited to Full Stack Developer positions - however, this works well for the size of the project and the nature of the work. We need developers who are happy to journey through the entire stack, in an entrepreneurial way to deliver meaningful value to the end users. If it is HTML or CSS one day, that's fine! If we're digging into database indexes the next day, that is also fine. Given the small headcount, specializing just isn't realistic.
Despite all of the above challenges, our team is involved for the right reasons and has time and time again proven that it can focus on the work that matters in driving big change for our client and ramp up on deep technology when necessary.
We exist to drive real impact. That is, the entire team is responsible for knowing the “business value” that is being delivered (or not!) as a direct outcome of their technical work. We optimize for improving the lives of our customers, which in some cases means we have to shy away from sparkly technology (I see you over there event sourcing, right behind GraphQL that I'll get to right after the Phoenix Framework is up ...).
We put a great focus on teamwork and on individual growth. We do this through a number of initiatives, but the understanding is that we must all be constantly improving. The industry is moving, our project is succeeding and the risks are perpetually increasing.
We also are pragmatic, in that how we spend an hour of our time matters. Literally, as such a small team with such a big mission every hour matters and must be invested with intention. This also means that we must be responsible and work aggressively to reduce our technical debt and minimize our surface area of knowledge as we implement new features. It is fun building new things, and we appreciate that it is a lot easier when the developer isn't tripping over all of the old things!
Last but not least, we know that as a team we must invest in things that in return give us superpowers. That is, tooling, systems and processes that can return an order of magnitude performance boost. If you've met with us, you know that we take Developer Experience very seriously, and that belief is at the heart of creating an A+ development workflow that makes it easy to ship great features.
Next Up: Our Monolith
Given the context of our project, our team and our philosophy, next, we'll dive into a look at our Majestic Monolith and why we are continuing to thrive because of it. Clearly we are unique in some of our constraints, and our opportunities! However, given the above we believe that in the next post it will become clear that the Majestic Monolith is the only real choice. We'd also like to think that you might see some similarities in your organization and that you might appreciate your Majestic Monolith a little more after reading about our journey.
Looking to join the effort and help us evolve our Majestic Monolith? If so, take a moment to review our open positions!