Brandwatch in 2019: A Year in Review
By Leia ReidDec 30 2019
Published July 11th 2014
Editor’s note: Interested in the Engineering team and what they get up to? They’ve got their own blog over at engineering.brandwatch.com. Head over there for insights into what makes them tick, what they’re working on and other developments behind the scenes.
Every application, however small, has it – even a small command line utility or PHP website.
As an application grows it becomes more and more important to have a good architecture otherwise the cost of making changes becomes too large, meaning development slows to a crawl or the product becomes more and more buggy and unstable. This is commonly referred to as Technical Debt.
Once an application becomes very large and splits into multiple applications with multiple teams working on it then having and maintaining a good architecture becomes a job for a team in itself, and that’s where my team comes in.
We don’t just focus on paying down technical debt though, we have a range of other responsibilities.
Brandwatch processes millions of mentions per day, and that kind of scale demands good performance from the system.
We’re constantly measuring and improving the performance of the system, responding to reports of slowness, or making pro-active changes to ensure we can handle increasing capacity requirements.
We take security very seriously here and there is always work to do to improve the security of the system and respond to increasingly stringent customer requirements when it comes to keeping their data safe.
We recently implemented SAML authentication for users, and are looking at implementing other improvements such as more granular user permissions and two-factor authentication over the coming months.
We have a dedicated Webops team who keep an eye on all our production environments to ensure they’re running smoothly, but keeping a server running is a completely different task to ensuring that applications themselves are responding to requests in a timely manner and aren’t generating errors for our users.
To this end we recently started running NewRelic APM on a number of our applications, which gives us an overview of how our apps are performing at a glance, allows us to drill down into slow requests and database queries as well as see if certain areas of the application are erroring more than they should.
We also aim to develop internal tools to increase visibility of issues across the department.
Architecture isn’t a one-way street – it’s the responsibility of everyone in the department and we are there to help other teams when they need to discuss new designs or find out if there’s a better way to solve a problem they’re working on.
A traditional view of a “Software Architect” has been a wizened bearded developer throwing down impractical and sometimes harmful commands from their ivory tower.
Here we know we have a set of teams brimming with talented developers, and give them the freedom to express their creativity, ideas and opinions, while backing them up with real world experience and a knowledge of parts of the system that they might not otherwise have. That and only 15% of us have beards.
So that’s more or less what we do here! If you’re interested in any of this, we’re always after a helping hand – check our job postings for openings.We're Hiring