Engineers of Endava | Meet Gareth

Gareth Badenhorst is our Software Architecture Design Authority located in our London Office.??

Over the past 12 years, he has helped grow our accounts in Logistics, Payments and Insurance, and more recently, Health, all while supporting technical architectural best practices.

While Gareth’s role is sophisticated, his overriding goal is “to deliver value to the business rapidly and sustainably,” which he demonstrates from the beginning of every project.?

“I think technical excellence and leadership are somewhat independent of each other, but they’re complimentary as both are critical success factors for delivery, so the further you go in your career, the more you need people skills like stakeholder management.” He explains.??

“As an architect, you should match the solution to the client’s real requirements.??

“It’s about the trade-off between how costly the solution is and the business benefit to them having all that availability: I’m not going to sell and build someone a brand-new sports car when they actually need an old van, just because they’ve got a sportscar budget.”?

“I would focus first on non-functional requirements. I try to challenge product owners on these to ensure they are realistic for the product rather than needlessly ambitious.??

“I also want to be sure that their key requirements, those that have a significant impact on the solution, and that I’m aligning a candidate solution with technology strategy, enterprise architecture principles and patterns.”?

But it’s clear to anyone who talks to him that Gareth is still an engineer at heart who is acutely aware of the complacencies he wants to avoid as his career evolves.?

“There's a risk of architects becoming remote from the realities of day-to-day engineering and focusing only on the boxes, arrows, and abstractions on their flow charts while stroking their beards in an ivory tower.”??

“You start as a developer and engineer, working directly with the tools and components we put in those boxes.” He continues.??

“As your career progresses, you naturally get pulled away from hands-on engineering, so that intimate understanding of the tools you’re implementing becomes more superficial over time as new versions and technologies come along.??

“You know what it does and how it works when you're putting those arrows together, but it’s conceptual ? it’s not in the same depth because you’ve not really worked with it directly yourself.?

“It may be a personal style, but I absolutely have to know how something I’m adding to my design works on an engineering level before I’m 100% comfortable using it.”?

“The assumption that you can just hand it to the engineering team, and they’ll come back to you if there’s something about it you’ve missed can trip good architects up.”?

“I’m not the hesitant type, but it makes me nervous in case there’s some detail that I could have missed, so it’s really important to work with everything you’re putting in those boxes when you can.??

“Providing architectural support on projects has included more Enterprise Architect (EA) responsibilities, although I'm probably doing more solution architecture even then, so I can still get my hands dirty occasionally.”?

“It’s so important to take those opportunities, as I was lucky enough to when we built a lot of Kubernetes artefacts that we later used to build a client’s microservice Dev Ops pipeline a few years ago.”??

Gareth took this opportunity in 2016 when a major logistics client asked for our help with an unreliable self-service portal responsible for processing $ millions per day.?

“The client’s CIO asked us to achieve five nines (99.999%) availability, which is rare and pretty intense. When we started it was running at around one nine (90%) and was suffering outages that could last a day.”??

“It wasn’t scaled to handle peak traffic, had complex dependencies via integrations to a number of core systems, and poor performance in major geographical regions like China.” He explains.?

The team worked closely with the client teams and third parties to review and fix the systems.?

“We removed bottleneck ESBs and replaced them with microservice architecture Kubernetes.” Gareth explained.?

“We then used Cloud technologies to create a multi-region deployment across three major regions, deployed a multi-region cluster database, and introduced Ground to Cloud data streaming to reduce run time coupling on core record systems.??

“Then we used a global traffic management system to route requests to the closest region and failover to alternate regions, and finally, we enabled blue/green deployments and canary releasing to minimise outages when deploying new releases.”?

“In the end, I’m pretty sure we delivered the five nines!”?