Why you don’t need a technical BA
The importance of infrastructure when building an application is being realised by organisations more and more. If you’re a larger organisation and have more than a handful of products or services, building centralised infrastructure for your development teams to use makes sense both in terms of effort and cost.
Now that you know you want to build a centralised monitoring and logging platform, a data pipeline, a centralised repository or whatever it may be you’re going to have to set up a team to build this.
You know who some of the key players in your teams are likely to be (developers, QA, Delivery Manager, Product Owner) and you know you’re going to have to collect a bunch of requirements and figure out how to break this work into stories, so you want a Business Analyst (BA).
Since the rise of this type of work, there’s a new kind of BA popping up — the technical BA. The technical BA knows what they’re talking about when it comes to infrastructure. Maybe they were a developer in their past lives, or they’ve worked on a many technical products before, and they probably know the difference between a lambda (something which triggers code to run quickly) and a llama (goofy long necked animal).
If you’ve got one of these rare creatures handy (a technical BA, not a llama) then by all means go for it! But what I want to emphasise is that you don’t need a technical BA. In fact, if you’ve got a skilled BA available who’s comfortable throwing themselves into a technical product, you can use them to your advantage.
Empathy with other non-technical folk is invaluable
The first month or two for a non-technical BA on a technical project is going to be rough. They’ll be asking for everything to be explained — probably more than once — and spending half their time googling terms they don’t understand. Being someone who is openly not technical makes being comfortable with what you don’t know much easier. Asking questions and getting people to visualise something to aid understanding will benefit the whole team, particularly any developers who don’t feel comfortable revealing to their team that they don’t know something. Before you know it, all the puzzle pieces are in place and the full picture is clear to the BA and the whole team who can articulate what the team is building, how and why, which is going to be super valuable.
When building applications with a beatufully designed UI, we’re all great at shouting about this in our organisation by doing showcases and newsletters, but you don’t often see infrastructure teams shouting about their successes. We shy away from talking about it to audiences which include non-technical people as we assume they won’t understand. Remember your BA didn’t understand not so long ago, and is in a unique position to empathise with other non-techies. Run showcases and create newsletter communications, utilising your BA’s ability to translate technical implementation language into words, diagrams and ultimately a storyline of the value which is being built. Infrastructure products are so essential that people in your organisation should know why this work is being invested in, and what your progress and learnings are — after all they will likely be your customers!
Understanding our users is still essential to build the right thing
We need to understand what our user is trying to do before we can figure out what to build, so we do a discovery. It’s easy to skip this key step of product development when building a technical product, or jump to a solution too quickly. Common examples of this include “we need logging, let’s use Splunk”, or simply “we need a data pipeline”. When you have a technical BA, they understand what you mean when you say “we need a centralised internet egress service” (something which controls access to the internet from an application) so they are less likely to question the solution and ask why.
First, we must understand the problem and our users — our users probably being developers! We want to know what the developers and their development team are trying to do, why they’re trying to do it, how they’re currently doing it, and their pain points. Since your team conducting this discovery include developers and possibly other technical folk, it’s all too easy to make assumptions. Involving a non-technical BA who doesn't have enough knowledge to jump to conclusions and make assumptions about why something is a pain or why a team chose a certain approach helps the rest of the team to conduct a discovery which is less leading and biased, more open and thorough.
How your users will consume your product is just as important as what your product is
Once the problem you’re trying to solve is understood and you’ve decided what you’re going to build, it is again easy to jump the gun and go straight into building it. The reason a lot of shared infrastructure and services take so long to deliver and onboard to, is because no-one thought about how users (developers) will use the amazing product you’ve built until you’re almost finished building it, often resulting in rework.
You need to decide how product teams in your organisation are going to onboard to your shared service; how they’re going to find out about it, how they’re going to get access to it (is it self service or managed by a team?), whether everyone can access it or you need to fulfil some criteria, etc. But onboarding isn’t the end of the journey for our users. As a shared service, you are now a dependency for anyone who you’ve onboarded. You need to consider how you can upgrade and build upon your infrastructure without interrupting service for any of your users, as depending on the criticality of the infrastructure product you’ve built and who is using it, any downtime could be costly and even catastrophic for your organisation.
Thinking about the complete user journey, from finding out about your service to consuming it for the lifetime of their application is essential. A non-technical BA can use their lack of knowledge of the implementation options to drive end to end service design. It may seem clear to someone technical how you would build and use an infrastructure service, but for someone without existing knowledge it is easier to ask the obvious questions and focus on how the developer — our user — will interact with the product and whether it is actually meeting the user and teams’ needs.
Going back to the reason we’re building a shared infrastructure product in the first place, we want to reduce the overall effort it takes for this to be implemented by each individual team. When making an investment in shared infrastructure services, it is common for organisations to mandate usage rather than make it optional. By designing and building an end to end user friendly service that solves problems rather than creating them, there should be no need for mandates. Making onboarding as easy as possible as well as building a quality product will make teams of developers happy to consume your shared service. And that’s all we really want isn’t it? — happy users.
A note on developers and development teams as users: When building infrastructure services it is appropriate and fine to consider the developer your user. However, we must remember that the reason they need this service is in fact to solve a problem for the end user of the product they are building. For example, enabling a product team to react when a function of their application is broken (via a shared monitoring and alerting service) isn’t for the benefit of the team itself, but for the benefit of their end user to reduce the time in which the thing they want to use isn’t working.
