The digital systems we build, the tools we use to build them, and the systems we use to operate them all overflow with data. From modern observability stacks to DevOps automation. The potential to use this data to develop more efficiently, operate more reliably and deliver better user experiences is immense.
We have all this data, yet we find the simplest of questions – "how are we doing?" – difficult to answer. Harder still is answering questions like "what is going wrong?", "where can we optimize?" and "how can we improve?".
The reason we find it difficult is, of course, the familiar problem of “missing the forest for the trees”. Day-to-day, we are immersed in the data we generate, but data in each tool is locked away behind an API or query interface we don’t have time to learn. It is siloed from other data and difficult to share.
The problem of visibility gets worse with scale. Engineering teams race ahead to develop new features, start new projects and adopt new technologies. As our systems get larger, more complex, and more dynamic, we increasingly lose control – of costs, security, reliability, performance, quality, and productivity. As the stakes get higher, the insights get harder.
Dashboards have become a bit of a guilty pleasure. We know we should be doing something better, but can’t get enough of them. Are dashboards enough? Can we do something better?
When someone asks ‘I want to see a dashboard’, what they usually mean is ‘I want to feel informed and in control’.
Like this:
What they ask for... An SLO dashboard
What they want... Quality of services to be measured, incidents to be resolved quickly, reliability issues identified and improved.
Or this:
What they ask for... A cost dashboard
What they want... Budgets not to be exceeded, overspend explained, costs attributed to owner, efficiencies identified, future spending predicted.
The desire for a ‘dashboard’ flows down to every level of the engineering organization. Support and incident teams need to know where to look when things go wrong. Infrastructure teams need to spot trouble before it impacts the business. And security teams need to know, well, everything.
So when it comes to data, while we like to talk about dashboards, we need more than just dashboards. We need a way to plug into our data, visualize it, perform an analysis, share the insights. And we need to do this continuously, iteratively and collaboratively, ultimately so that we understand what is happening and make better decisions.
Outside of engineering, these capabilities are called business intelligence (BI). Business teams have established tools like PowerBI and Tableau for this need.
BI tools have three important characteristics:
While engineering teams have been overflowing with data, we haven’t had the analytics tools to match. We think it’s time engineering teams have their own BI – one that’s built for their data, to model their complex systems, and for the real-time analysis engineering demands.
That’s why we built SquaredUp.
The challenges that modern product, engineering and IT teams face are similar to those of using business data, but distinctly different.
A business intelligence platform for engineering needs to:
We believe engineering teams can interact with data in a new way. To provide visibility, create shared understanding, and to enable better decisions. We want to empower engineering teams to move fast, stay in control and build better technology.
We’re on a mission to empower engineering teams with data.