“So, what is a business analyst?”
“What does a business analyst do?”
These are the two questions I am most often faced with at social events where the topic of career is on the table. And if you are in business and wondering why we can’t just sell you a developer, another common question is: What value does a business analyst add?
Informing someone that you are a business analyst (henceforth BA) is about as informative as saying you are a manager: there are so many permutations that a single word (or phrase) really does not really suffice. In fact it can do more harm than good, as people tend to nod their heads and piece together their experience of ‘business’ in conjunction with their understanding of ‘analyst’ and come up with their own approximation of just what it is that I must do.
The reply I usually give is the following analogy: in the world of IT, a BA is to a programmer what an architect is to a builder.
If you were to build a new house, who would you go to first, a builder or an architect (assuming sufficient funds to do both)? You go to the architect. This is the person with whom you discuss your dream home, with whom you share your vision. You tell them about your passion for cooking, your growing family, about your son who has just taken up the drums. The architect takes this information and and turns it into a design that meets your needs functionally while also being aesthetically pleasing.
In contrast, the builder needs plans and sufficient information to order the right type and quantity of materials so he is able to construct a house with 6 bedrooms, a soundproof sleep-out, and a large kitchen. The architect understands the vision and ensures the finished article will fulfill that. So too with the BA in the context of software development.
The BA is a communication bridge between the business and the technical team: they are listeners and problem solvers, both creative and practical. They understand the problem or goal from the customer’s point of view (’I love cooking and have an impressive assortment of kitchen applicances’) and transform it into into something that can be built by the programmer (x cubic meters of cupboard space in this layout).
Another similarity is the architect is typically consulted for the duration of the construction effort – even though you might say that their main input – the design – was completed up front. BAs are often needed from inception to final QA, being on hand to answer questions and clarify concepts. They often have input into defining the test scenarios as they are the ones best understand the manner in which the final application is to be used.
I accept the analogy is not without flaws – if you are in IT you will probably have already spotted them. The major one is that a BA typically does not understand all the technical constraints of a solution they propose, and have to consult or hand over to developers and systems architects. I’m sure there are others.
But overall this comparison helps people understand that BAs are listeners, designers, problem solvers and facilitators. Their focus is on understanding, creation solutions, simplifying process, and clear communication of ideas. They are are a sort of ’project glue’ if you like.
All of which provides diversity and challenge, and ultimately why, after more than 10 years, I still enjoy being a BA.
