Architecture at Lendable: an engineer's perspective

Having joined Lendable almost two years ago and during that time having worked closely with our architects on different projects I thought it would be helpful to share my account of these interactions and how they compare to similar collaborations at previous places I've worked in the past.

In my own mind architecture is very much an emergent behaviour. An emergent behaviour by it's definition is behaviour that arises out the interactions of different constituent parts. Applying this reasoning to software architecture we consider emergent behaviour as the architecture of a software system evolving as we incrementally design the interactions and relationships between it's components. In a nutshell, this architecture emerges as we think deeper and consider more of what our system must do as opposed to being able to confidently anticipate or predict what that architecture will look like, up-front and ahead of time. A real world analogy reflecting this emergent behaviour can be observed when we think about traffic jams. They can occur when there are no accidents or road works. The interaction between different, individual drivers, their reactions to weather conditions and small delays (e.g. livestock wandering onto a road) can cause traffic jams that affects the entire flow of vehicles. If this happens too frequently traffic management engineers (architects) may re-appraise their original design of the roads and junctions (the architecture) in an effort to improve this flow of traffic.

Software architecture is quite a subjective term that means different things to different people in different contexts. From experience, if you speak to an engineer and ask them about the architecture of a system they have worked on they will tend to gravitate to speaking about how the code in components of that system is organised. They'll explain how the code in the different layers within a component interact and depend on each other. If you consider that as a 100ft view of the code, speak to a hands-on architect or a hands-off technical lead they'll tend to speak about the code at a higher level of abstraction, say 1,000ft. They'll tend to focus more on how the components within the wider system behave and interact with each other. More hands-off architects and DevOps engineers will reason about architecture typically at a deployment level of abstraction, at a 10,000ft view. In summary, when we think about software architecture, we think about different things at different levels of abstraction.

I crudely asked ChatGpt what the definition of software architecture was and based on the response it gave me below it reinforced what I've just discussed. The response talks about architecture concerning a "high-level view of the system" yet also mentions lower level concerns such as software "patterns and frameworks" too.

Considering architecture to be different things at different levels of abstraction is particularly pertinent to how I've observed our capabilities and how we approach architecture at lendable. At the various places I've worked so far in my career, aside from Lendable, I've worked with good and bad architects as you'd expect, but more pertinently I've found architects that are adaptable and valuable at those varying levels of abstraction to be as rare as hens teeth.

I have worked with the classic ivory tower type architects who operate in isolation from the practical concerns and realities of software development and as a result become completely misaligned with the tech teams they are intended to enable. In my experience these type of architects become like this because they are off the tools too long (looking at code) and then are only able to reason about architecture at a 10,000ft view. Many ivory tower architects have good knowledge at that level of abstraction, however their knowledge at any level lower than that tends to have evaporated. Because of this they make decisions without knowing or listening to, key lower level context and this causes churn and unnecessary re-work in the tech teams who are responsible for delivering the solutions they design.

Another type of architect I have encountered is what I would term the nomad. The nomad try to enable tech teams as best they can but they don't possess enough knowledge at the varying levels of abstraction where we need to consider software architecture. This usually applies to both domain knowledge and lower level technical fundamentals. In short, they have just enough horizontal knowledge to get by but don't possess enough deep vertical technical knowledge at all and because of this they struggle to challenge and ask the right questions of the tech teams they should be enabling. Nomads differ from ivory tower architects' autocratic style in the most polarising way possible in that they basically let you do whatever you please as they don't have enough knowledge to challenge what you propose. Becuase of this, it's easy for tech teams to be tempted to be veer into extreme territories. At one extreme this could be over engineering solutions and going down rabbit holes and struggling to deliver any business value. At the other end of the extreme this could be prioritising delivery too much over quality and building systems that are hard and time consuming to reason about and change.

If you notice from the last two paragraphs the word which keeps jumping out is "enable". The best architects I have worked with simply enable the tech teams they exist to help. To do this they must be adaptable and pragmatic and they must be able to provide valuable input at the varying levels of abstraction of software architecture I touched on earlier in this blog. This is very much the characteristics I associate with our architects at Lendable based on my experiences of working with them thus far. Overall they are a positive force, they enable developers to write and design applications easier, better, faster and more reliably. If I were to sum up our architects in a short sentence it would be 'they enable me to do my job easier and better'. If I were to type cast a third type of architect as I have the previous two, they would be the "enablers".

At many places I have worked previously, rightly or wrongly, I have often sought to fly under the radar of architects. Part of that may have been due to being a contractor I'm conscious my job was to deliver and I suspected too much engagement with architects would slow me down and derail that. The biggest compliment I could pay the architects at Lendable is that due to my experiences collaborating with them is that I've had a mind shift in the complete opposite sense here. Rarely a week goes by, where I wont ping our architects on slack asking them to go over documents I've written, designs I've proposed or to ask their thoughts on random ideas I may have. Our team encourage architects to attend our ceremonies, design sessions and if we struggle to agree within our team we enlist their help. Why this mind shift all of a sudden you may ask. Because they enable, that delivery quandary I mentioned at the start of this paragraph, they affect that positively.

Perhaps the most pleasing and enjoyable aspect of my experiences with the architects at Lendable is not just the fact they enable and add value to me and my team, it's more how they do that. They challenge with questions rather than directives, they are devoid of ego, they are responsive and above all if they don't know something, they'll say they don't know. All of this allows me and the team I work in to be vulnerable and seek support without internalising that needing help is reflection of some sort of shortcoming, individually or collectively.

I hope this blog doesn't come across as a puff piece as that was not it's intention. The intention was to highlight the vagaries of software architecture and how the architects I've worked with in my career so far cope with these vagaries and the subsequent impact this has on the teams they exist to support. It just so happens that in comparison to the architects I've worked with in the past anyway our architects here at Lendable are awesome! If your team is struggling with anything internally I'd encourage you to reach out to them, you won't regret it!