Rethinking Architecture

This post was originally published on Brandwatch's main blog on 11th July 2014.

Architecture!

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.

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.

Scaling

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.

Number of queries in Brandwatch over time

Security

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.

Tools and Monitoring

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.

Advising other teams

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.