O’Reilly Software Architecture

I thought it was about time I tried a new IT conference having frequented QCon and others for more years than I care to admit! So, here I am, writing from the bowels of the brutalist monstrosity that is the Hilton Metropole, in London, for this years O’Reilly Software Architecture Conference.


Full Schedule

Day 1

The keynotes were, if I’m totally honest, a little flat and quite disappointing. I didn’t really understand the format – why have more than one? Maybe when you suspect the individual material isn’t quite strong enough to stand on its own? They were perfectly acceptable presentations that would have been fine elsewhere in the program, but they didn’t have the wow factor that you have come to expect from an event of this size (and cost). We heard how streaming was the next big thing; perhaps a step-change, to rival the introduction of the RDBMS – but I think we already knew that? Nate Schutta’s talk was the exception and was very good…

Architect as a Storyteller

Nate explains why an architect’s job is to be a storyteller. Architects are essentially the Rosetta Stone of an organisation, providing translation services (or, as some would call it, the “elevator” between the executive suite and the development floors). The challenge lies in not only crafting a compelling message but doing so for wildly disparate audiences. (The pitch you give your developers will not go over well with the executives, for instance.) While we may not want to adopt iambic pentameter anytime soon (though who knows, that might encourage more people to read our various artifacts), we must consciously think about the story we are telling.”

Here are the slides.

Visualise, document, and explore your software architecture

Simon Brown

“The Agile Manifesto has typically been misinterpreted as “don’t write documentation.” Although contrary to the authors’ intent, this misinterpretation reflects the fact that many software teams have lost the ability to communicate what it is they are building. It’s no surprise then that these same teams often lack technical leadership, direction, and consistency. Simon Brown shares approaches and tools for visualizing, documenting, and exploring your software architecture.”

This was the stand-out talk of the day, for me at least. No where near enough time is spent on this topic, in our industry. We explored tools and techniques for improving how we document our architectures. Definitely some lessons here that can be immediately applied back in the office.

Here are the slides. There is also a video from a different event that seems to be more or less the same content. 

Research-driven Development

Philip Winder

“Chances are that like most developers, you love learning and having new problems to solve but hate monotony and bureaucracy. You’ve probably put strategies in place to mitigate the things you don’t like—for instance, using an anarchic development process like Agile to reduce the amount of time spent in meetings. But have you ever thought about the way in which you approach learning and problem solving?

Philip Winder argues that modern developers are in fact researchers, even if most don’t identify themselves as such. Research-driven development is the acknowledgement that developers are researchers. To that end, Philip explores shares practical tips to make people better researchers and therefore better developers.”

This talk focussed on the parallels between University Research and Software Development – the learned lessons from managing research projects that can be shared and applied to IT. I was unconvinced, beyond the obvious and not particularly helpful observations. Not an idea that is worth exploring any further. Perhaps useful as a reminder to developers that so much of what they do is not coding, but I think most programmers are acutely and painfully aware of this already.

Don’t ask, don’t tell – privacy by design

Eleanor McHugh

“After years of personal data breaches and mishandled payment data, lawmakers are waking up to the importance of online privacy. Eleanor McHugh explains why, to comply with new laws, we need to put privacy at the heart of our design processes. But how do we do this when design itself is often seen as the enemy?”

One definite takeaway for most people in the room – double checking EU GDPR compliance when we get back to work! This comes into force next summer and it’s widely expected that many organisations will be unable to fully support it (and therefor risk potentially significant fines). The talk featured some interesting anecdotes but was largely preaching (and a little patronising) without providing any real practical tips.

Here are the slides.

Beyond Accidental Architecture

James Thompson

“In many cases, existing architectures represent an accident of circumstances—big balls of mud that grow naturally anywhere there is a lack of deliberate architectural thinking and practice. James explains why you should move beyond the accidental and introduce intentional architectural thinking to your team, outlining the benefits of deliberate software architecture, from helping newer engineers understand why certain boundaries exist to enabling senior engineers to improve their skills and more.”

Certainly an interesting subject that is close to my heart, having suffered with the consequences of accidental architectures and, in may ways, made a career out of correcting them and evolving them. There weren’t any concrete tips here though that I felt would really help – like much material on the subject; it’s easy to retrospectively point out why it happens, but far harder to actually change organisational thinking. There are very real and in some cases perfectly understandable reasons why this happens, and at least it does keep a software developer in work after all…

Here are the slides.

Superheroes and con-artists – creating better teams

Don Kelly

“Hiring and maintaining a software team is a challenging proposition. Programmers are among the toughest craftspeople to manage and assess. To gain a fresh perspective (and relieve the boredom), Don turns to the pulp fiction of his adolescence for inspiration, explaining how he maps teams from fictional universes into the software teams he would like to build.”

This was a wonderful talk to end the day. It’s always nice to finish on something a little softer, after a day of technical presentations. This was very well presented and the material was both amusing but also interesting and genuinely useful/accurate. Plenty to learn here for the budding team lead, or for anyone forming new teams and thinking about the balance and the skills required (or more importantly, personalities).

Here are the slides.

Day 2

With the notable and predictable exception of Dan North, the keynotes were a little bit of a let down again. Dan was excellent, as usual, and should probably have taken a single, extended, slot. The others were, like the previous day, adequate enough talks but without any of the genuine lightbulb moments that you expect (and need, at 9am in the morning).

The Death of Cannot Reproduce, from Michelle Brush, does warrant a mention – I think it’s always worth highlighting the inadequacy of many companies in this area and the basic attitude problem that exists w.r.t bug investigation. You see this a LOT on twitter and I’ve been frustrated by it myself on many occasions – you helpfully point out a bug to your bank, grocer, phone provider, or whomever and are met with a slew of customer service guide book answers (have you tried an alternative browser, etc). Check out this thread on Twitter where Lloyds and Google (Android Pay) blame each other for my bug report and I, the frustrated customer, am left with no solution or explanation.

How to Break the Rules?

Dan North

“We invest so much in technology, so why do we seem to get so little benefit in return? We introduce new processes, tools, and methods, but when you stand back and squint, the organization still looks just the same.

Is technology overhyped and oversold, as many would have us believe, or are we doing something that means we lose out on all those promised benefits? Societies work because we follow the rules, but what if those same rules are holding us back?

The problem may be because we are failing to change our habits. Dan North introduces some uncomfortable truths from Eliyahu Goldratt, author of The Goal, a cornerstone of modern management theory, that help us recognize and challenge this behavior and unlock the true value from our technology.”

Excellent and inspiring – ideas that you can take back to your company and easily apply to bring about real, positive, change. He essentially reverse engineers a famous business book from the 80’s to produce a template (4 step process) for understanding how your proposed technology change can be successful in your organisation. The trick is in understanding what rules currently exist to manage the limitation that you are addressing and how those need to evolve to support the change you are making. From experience, it’s far harder to do than it sounds, because in a large organisation those rules are usually deeply engrained and often outside of your control to change, even if the benefits of doing so appear obvious to you.

Here are the slides.

Practical Security Principles for the Working Architect

Eoin Woods

“As our world becomes digital, the systems we build must be secure by design. The security community has developed a well-understood set of principles used to build systems that are secure (or at least securable) by design, but this topic often isn’t included in the training of software developers. And when the principles are explained, they are often shrouded in the jargon of the security engineering community, so mainstream developers struggle to understand and apply them.

Eoin Woods explains why secure design matters and introduces 10 of the most important proven principles for designing secure systems, distilled from the wisdom of the security engineering community. Eoin walks you though each principle the context of mainstream system design, rather than in the specialized language of security engineering, and demonstrates how it is applied in practice to improve security.”

As the name suggests, this was a very practical session with a useful clearly defined output that you can takeaway and apply when you get home. None of the principles were particularly revolutionary, but they were clearly explained and the condensed format is certainly useful as a high-level checklist when you set about designing a new system (or changing an existing one!). It was interesting to hear from a former UBS colleague on the challenges he faced while adopting these principles.

Here are the Top 10 principles – a useful resource to takeaway.


Here are the slides.

Serverless Architectures

Mike Roberts

“Mike Roberts offers a thorough overview of serverless, covering benefits and limitations along with examples and case studies to help you understand whether serverless is a good fit for your team and needs. Along the way, Mike also discusses the key elements of serverless that will have to advance as the technology evolves.”

Nothing significant to report here!

Architecting for the Cloud

Ann Mwangi

“Architects are increasingly becoming convinced that the cloud is the way to scale. The most important consideration after deciding on a cloud migration is the architectural design of the proposed infrastructure. Ann Mwangi shares considerations when deciding on and designing a cloud architecture for a business and highlights common pitfalls that teams fall into during this process.”

I discovered my new favourite buzzword. BOA – buzzword oriented architecture! Otherwise not a particularly interesting talk I’m afraid and I must confess to using the time to finish writing this blog entry – don’t you just hate those people typing away on their laptop during a conference talk!

Evolutionary Architectures

Neal Ford

“Drawing on concepts from his new book, Building Evolutionary Architectures, Neal investigates the family of software architectures that support evolutionary change and explains how to build evolvable systems. Understanding how to evolve architecture requires understanding how architectural dimensions interact; Neal describes how to achieve appropriate coupling between components and services. Incremental change is critical for the mechanics of evolution; Neal covers how to build engineering and DevOps practices to support continuous change. Uncontrolled evolution leads to undesirable side effects; Neal demonstrates how fitness functions build protective, testable scaffolding around critical parts to guide the architecture as it evolves.”

Good, but honestly I didn’t really get this – it just feels like testing to me? I think I need to revisit this, but it felt a bit like architecture ‘done right’ re-branded as something new and clever.

Thinking about thinking about architecture

Ben Evans

“Ben explores some of the best known cognitive biases and other effects that are relevant to architectural design and related tasks, covering core patterns and anti-patterns and sharing examples and case studies from his own projects that show how more cognitive awareness could have prevented the problems encountered.

Whether or not you subscribe to the cynical viewpoint of Oscar Wilde, who said that “experience is the name everyone gives to their mistakes,” Ben helps you look with fresh eyes on your own projects past and present to understand the benefits attention to cognition can bring, in the hope of making us better architects.”

Again, nothing significant to report here I’m afraid!

Day 3 (tutorials)

Morning – API Simulation (for micro service testing)

Apart from the photographer who lacked an understanding of personal space, everyone seemed to enjoy this session. The pace was good and the content genuinely useful. We were introduced to a new tool, Hoverfly, for simulating API responses and, more interestingly, injecting faults (think Chaos Monkey). Particularly useful is the ability to run Hoverfly as a webserver, so that you can bypass the pain of constantly switching a proxy on and off on your developer workstation and continue to use your existing suite of services development/testing tools (i.e. Postman). More on how to run as a web server here. Certainly a better (and simpler) approach to the mocking of the last decade. It is powerful enough that it introduces the risk that you will no longer test adequately against real services! I’m ashamed to say I was also discovering JQ for the first time – an excellent little command line utility for interpreting JSON. All in all, a productive workshop with clear applications for the lessons learned and useful new tools that I can use for developing and testing [micro]services.

Afternoon – Kubernetes & Envoy (Cloud/Container development workflow)

A very brief re-introduction to Docker and then Kubernetes followed by a more useful and interesting deep-dive into some supporting tools and practical deployment tips. We started with Forge, which is essentially a tool for automating many of the Kubernetes deployment steps. We then covered Envoy, albeit too briefly – a next-gen proxy, designed for the Cloud, that has evolved out of NGINX and others. The idea here is to embed this proxy in our development workflow such that it can be used to provide software level resiliency. This could be through Canary Testing; enabling multiple versions of a given service, for example. This, in turn, led to another new technology – Ambassador, which, from what I can tell, is simply an abstraction of the rather low-level Envoy proxy, with some authentication features thrown in for good measure. Again, more time needed on this as home work! Prometheus was the final piece of the puzzle, providing visualisation of Envoy metrics. So, lots of new tools but not really enough time to get properly accustomed with them. It’s clear that, unsurprisingly, Kubernetes has matured over the last few years and the community and tooling have improved significantly.

Here are the slides.


Putting the material itself to one side, there were the usual complaints; far too many middle-aged men with beards, far too few women and not enough freebies – not a single free O’Reilly book, come on guys!

Overall impressions – interesting, insightful and certainly worth another visit, but perhaps it doesn’t compare favourably to the ‘big two’ incumbent London events; QCon & Devoxx.

#OReillySACon @OReillySACon

16th & 19th October, 2017




Thinking Digital 2017

I’m writing this from the comfort of my train as I hurtle south through the English countryside following a memorable and very enjoyable conference, back in my home town of Newcastle Upon Tyne. I’m ashamed to say this was my first attendance at an event that is now celebrating it’s 10th anniversary. I will be sure to return next year!

tdc17The content was varied, thought-provoking, informative, very well presented and frequently amusing and inspiring. Think of it as a mini WIRED or TED event and indeed the organiser, Herb, does also run TEDx Newcastle.

The Startup Competition – write-up to follow, honest…

The Main Event (full schedule)

Session 1

Mark Mullen (Atom Bank)

Laetitia Cailleteau (Accenture) – applications for AI

Dan Biddle (Twitter/BBC)

Darren Jobling (ZeroLight) – has branched out from gaming to visualisation for Audi.

Session 2

Sophie Bostock (health)

Dr Anita Sengupta (rocket scientist)

Di Mainstone (art/music)

Tom Scott (future)

Session 3

John Kershaw (beards)

Adrian Westaway (design) – talk about tech not being the end game, the importance of UX etc

Simon Singh (maths)

Session 4

Richard Wiseman (magic and design)

Dr Justin Sanchez (darpa, brains/neural)

Imogen Heap (music)

Jeremy Silver

Chris Turner (rap)


Applications for Finance?

Given that my employer kindly agreed to fund this trip I should make some observations in the context of Financial Services. We heard from Atom Bank. With direct applications for my particular area of banking (Equity Research), we saw a pitch from City Falcon, an interesting disruptor in the FinTech space looking to simplify access to market data (or commentary) and present using intuitive interfaces, such as Amazon Alexa.

More details to follow, I promise…


#TDC17 @ThinkingDigital

16th & 17th May

How the burndown burned me out

“Scrum is leading us into temptation to work until we burn out.”

Michael Hofmann @ SGBER (2014)


I’m a ScrumMaster in a reasonably successful feature team at a large European bank, in London.

First of all don’t get me wrong – the title is deliberately dramatic and attention grabbing, but I am a firm advocate of Scrum and agile methodologies in general. I’ve worked on waterfall projects and is was not a pleasant experience – I have no desire to return to those dark days. I do however, believe that Scrum is far from perfect and offers its own unique challenges.

My problem is stress and the constant pressure caused by maintaining and sustaining a certain velocity (i.e. high pace), while at the same time ensuring that quality doesn’t suffer. I want the team to actually enjoy themselves at work and I often find the frantic pace just doesn’t allow this. Now, I know what you’re thinking – a teams velocity is supposed to be sustainable; that is clearly stated in the manifesto.

“Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.”

Agile Manifesto – Principles

The competing factor though is continuous improvement – this philosophy is instilled in all good agile teams and so there is a natural tendency to want to see your velocity increase.

I have another problem with velocity and it’s the implication or assumption that it is carefully measured.  If you measure something you are creating targets, whether you mean to or not. Should it be measured at all? I stopped measuring velocity a long time ago and we abandoned the burndown altogether; I haven’t detected any particular problems and morale has improved as a result. Anecdotally, I’ve seen no reduction in velocity or capacity.

Then you have the problem of how it is measured and reported (and then ultimately compared and used as a stick to beat a team with). Equally, if you don’t measure velocity, you have the problem that stakeholders and product owners will calculate it themselves, ambiguously and without assigning an actual measure or real value, based purely on their perception of your output. This is why if you run a successful Scrum team it often feels like you are digging your own grave – the joy of having a successful sprint and delivering against your plan is swiftly replaced by the overwhelming dread that you’ve got to do it all over again next week (and improve on it). You are left with the demoralising effect of feeling like you’ve somehow gotten worse or that you are going backwards. Either way, it’s stressful and not much fun.

There is a lot of supporting evidence in favour of an agile approach vs waterfall, with respect to the teams mental health – but this is largely based on the assumption that stress is reduced and far less than that found during a typical waterfall crunch period. Is it really? Does slightly reducing the stress levels but spreading them out so that it occurs in each sprint really improve things? At least after a couple of weeks of waterfall crunch you had the chance to rest and recuperate; with Scrum there is no end in sight.

I’ve also found that generally a Scrum team has a far more rushed attitude to delivery. This is a common criticism of Scrum and I’m not going to cover the issue in any detail here. You could call this ‘focus’ or the result of increased energy, motivation or enthusiasm, but the result isn’t healthy, for the product itself or the team members. Again, this is often the result of the drive towards continuous improvement. What if some things just take time and careful consideration?

“Move slow and craft things.”
Kevin Fox

Now, I realise that there isn’t anything in the agile manifesto about increasing velocity or rushing through things, but the reality is that the principles and the attitude that is instilled into the team does affect a number of people in this way. Certain personality types seem less affected than others and some people are more willing to miss their estimates and instead just do the job properly, but that is rare in my experience. It’s not just the burndown; it’s Scrum in general – people can find the process and the methodologies addictive and the never ending backlog of work just doesn’t fit well with certain personalities.

Closing a JIRA or moving a sticky note to a ‘done’ column is an intrinsically rewarding and motivating process. I don’t think that is an accident; I think there are elements of gamification within Scrum by design. Is this the right approach – we know that this encourages people to call a piece of work complete when perhaps that isn’t quite accurate. If all of your colleagues have moved some tickets or closed some items at your daily standup, there is some pressure on you to do the same, that is human nature. Again, there are many other articles covering the importance of the Definition of Done, or of the effects of peer pressure within an agile team.

I’m not the first person to make the connection between Scrum and exploitation…

“The daily Scrum meeting (stand-up) is another tool designed to maximise exploitation of developers as a capacity constrained resource by keeping them busy and keeping development moving forward.”

Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results.

David J. Anderson

To summarise, I think the agile approach fundamentally changes an individuals approach to work – largely in a positive way, but with some negative connotations for stress and an individuals attitude towards completeness and thoroughness.

What can you do about it?

Have some time off between sprints, perhaps a free day, so you don’t feel that you are jumping straight back into the fire! This would give everyone some time to play, learn, reflect etc. I’ve seen similar implementations where people have tried to introduce Google 20% time outside of the Scrum process, for example.

It is worth investing in a proper model of your system, ideally visualised and well presented. This model can help to articulate the business value of design, infrastructure or architecture work.

A good ScrumMaster, team lead or project manager will spend a lot of their time helping to ease the pressure on team members and insulate the team from frequently changing and increasing demands. It’s a fine balance, you need to be delivering ‘value’, but you also want to allow the team to fail occasionally to facilitate learning through experimentation.

My advice – drop the burndown, stop measuring velocity and appreciate that there is a real limit to team performance and efficiency; the continuous improvement curve can’t be linear!

As always, I’m keen to hear your thoughts and experiences.

Further Reading

How To Not Destroy your Agile Team with Metrics

The importance of a good team

It may seem obvious, but a good team of people is absolutely critical when implementing Scrum. Scrum and the delegated control and decision making that comes with it can be disastrous if you don’t have a team of people that you can trust.


Agile is based on this word, trust. You will be told, in all of the literature, that trust is crucial and that you must resist the old school management temptation to dominate and dictate. Can you implement Scrum successfully without this trust – the answer, obviously, is no. What if you find trusting difficult?

There could be good reasons for your scepticism. How do you know whether you have a team that you can trust?

Use an agile maturity model to help understand how capable the team is and how much potential there is for improvement. If you don’t see each and every member of your team maturing to the desired end state (presumably zen/guru) then its probably time for them to find another team. The weakest team member will always hold the rest of the team back and prevent your team as a whole from maturing.


Evaluate the team and have them self-evaluate using a formal model.

Run small experiments to limit your exposure and validate or invalidate your fears around trust and specific team members. Frankly, if you place your trust in them and it doesn’t work out, then you know what to do…

Of course there will be legitimate limits of your trust as a leader, but you need to be on that boundary and pushing it all the time. There is nothing wrong with that, as long as you have a plan to address the problem; maybe this month you don’t trust Bob with a release, but you can delegate a few smaller tasks and see how he gets on, then try again next month.

As Einstein famously said, insanity is doing the same thing over and over and expecting different results – if it’s not working, move on and change your team.

Do not, under any circumstances, try to shelter or insulate an individual for the team. The problem is  not limited to that individual, it will be having an effect (visible or otherwise) on the rest of the team. One de-motivated, non-believer can have a huge negative effect on an otherwise high functioning team.

Another problem with IT budgets

Well, it’s that time of year again – budgets and 2016 planning. Great! This process, certainly at my organisation but I’m sure at many others the World over, is met with dread. It can be maddeningly frustrating, stressful and time consuming and is often ultimately unsuccessful.


Recent research has shown that people in financially challenging situations often make bad decisions.

“When they were preoccupied by financially challenging scenarios, the poor did significantly worse. When concerns of scarcity captured the mind, the poor had notably reduced fluid intelligence scores and exhibited diminished executive control.”

Can we apply this research to corporate decision making? I think we can – the stress and complexity created by constraints is quite similar to that which you experience when dealing with personal financial difficulties (although obviously far less important). Indeed, the author actually alludes to the fact that you don’t necessarily need to be ‘poor’ to be affected.

“This also appears to be true for people who are not “abjectly” poor, just budget–constrained. When they were preoccupied by their finances they did less well on the cognitive tests, and the effect was substantial.”

So, perhaps there is a lesson here for the corporate budget process? I think we all know that 12 month, short-term, thinking is unhealthy – but is the mere fact that we are budget constrained very damaging in itself?

Of course, until we find a better approach, this is just yet another nail in the coffin for the current budget process…

WIRED UK article ‘Worrying about money can lower your IQ‘.



Deconstructed Viz – Male vs Female in the UK Houses of Parliament

Houses of Parliament Membership http://dadaviz.com/i/3828

This is a fairly powerful visualisation, but I’ve got a few problems with it…

1. What’s the story?

You kind of already know the answer before you see the results! So there are more male MPs than there are female – that ain’t news! This is a common weakness in many visualisations – it’s not showing you anything new, but rather its a pretty picture of a statement we already know to be true?

2. What’s the purpose of the visualisation?

Do we even need a graphic to get across this particular message? Is it adding any real value – we’ve already made the very bold statement in the title of the visualisation – “More male MPs were elected in 2010 than the total number of female MPs ever”. That clear statement is arguably enough on its own – I’m not sure the graphic is doing anything to drive that argument home?

3. Make it a fair argument!

It’s a leading question and that’s what I really don’t like. The author had a clear agenda – to highlight discrimination against women. Don’t take sides and try to let the user explore the data and draw their own conclusions.

Visualisations can and should be powerful – they should prompt a debate and discussion, but they should be based on a level playing field for that debate, with no obvious bias.

4. More questions than answers?

What about the context? The first thing I think when I see this graphic is ‘ok, but how many women actually stood for election?’.

We are implying that people aren’t voting for women, but we aren’t backing that up with evidence. We aren’t telling the whole story and we have to be very careful when we do that.

This is only part of the picture. Try to paint as complete a picture as you possibly can. That’s not always possible, but try to at least be honest about the gaps in your data.

Don’t leave them wanting more, or more confused than they were to begin with.

Scrum Maturity Model

This is a model for understanding and exploring Scrum team maturity. I created this model during a workshop ran by Olaf Lewitz & Krishan Mathis at the annual Scrum Global Gathering in Berlin.

The first diagram shows the circular states that represent the different levels of team maturity, with some examples of what demonstrates that level of maturity.


The second diagram highlights the fact that the team can only ever be as good as it’s constituent parts. Or in fact, as good as it’s lowest common denominator! In other words, if you have one particularly weak team member, it is going to hold the whole team back. This reinforces why the circular maturity model is so important – any change to the team can have dramatic effects on the overall team maturity.


The model isn’t scientific and doesn’t go into a lot of detail. It won’t tell you how to measure maturity or what you need to do to change it. It serves a single purpose; encouraging you to think about the maturity of your team. It will hopefully help you understand what you need to change and how fragile a team’s maturity can be.

This still needs a lot of work, I realise that. I’m deliberately publishing it quickly and soon after the conference in order to try and get a bit of feedback before evolving it further.

What have I changed from the original Scrum Master Maturity model that inspired this proposal?

  • Crucially, it’s a circular model. It’s not a timeline. This represents the fact that the team never stands still. The team always changes. New people will join with different levels of experience and new ideas and, of course, people will leave. It is important to realise that you are constantly moving around this circle as your team evolves. There is no start and end state.
  • I’ve extended the model to incorporate the team as well as the Scrum Master and also show the relationships between the two.
  • I’ve simplified some of the text and made it a bit less ‘wordy’!

You can see the original model that inspired this work below. Full credit to the original author of that model, Ángel Medinilla.