How to become a technical business analyst

To be or not to be technical as a business analyst? As a business analyst, you might have asked yourself this question so many times before. A quick and simple answer is: No, you do not have to be technical. However, a realistic answer is hidden in myriad questions that follow this question, such as:

  • Can you afford not to be technical in an economy that is heavily driven by technology?
  • Can you afford to be completely dependent on other competencies to help you deliver value to your business stakeholders?
  • What happens if they are not available to help you when you urgently need to prepare a presentation to your stakeholders? Or better still, what happens if they give you incorrect information?
  • Will you be able to pick up the errors in the information? Who stands to lose professional credibility if you miss the errors?

Most of the consumers of business analysis skills are corporates in financial services (banking and insurance), telecommunication, broadcasting, fintech, medical aid (healthcare), auditing, retail, etc. The core business model of these corporates is driven by technology. The innovation that they chase, as a differentiator to their customers, is enabled by technology (to a considerable extent). It is inevitable that, at some point, they expect a business analyst who can apply technical lenses to a solution and overlay it with customer experience.

Edward Ngubane, DVT, head of business analysis, business enablement division.

Edward Ngubane, DVT, head of business analysis, business enablement division.

In the same way that Moore’s Law predicted and explained the exponential growth of computing power, the growth of knowledge, in general, has been exponential as well. This is because the truth about knowledge is not absolute, but relative. What we know to be true today is simply our way of defining a phenomenon we are trying to understand within the constraints of what we have at our disposal. The more our constraints get lifted, newer truths about the very same phenomena emerge. Therefore, it makes sense that medical scientists and researchers discover or find cures, and not invent them. To ‘find’ presupposes ‘former existence’. It is simply an evolution of the discovery journey.

The same thought process can be applied to software development methodologies and the business analysis practice. Less than 10 years ago, the waterfall methodology represented the ‘truth’ of software development projects. With the evolution of knowledge, better ways of handling software development projects appeared, and this ‘truth’ was found wanting. It is highly possible that, fast-forward 10 years from now, the ‘agile’ truth might be displaced by another truth that might appear at that time. In short, this shows the nature of knowledge is always evolving, and so is the nature of skills needed to keep up with the evolution of knowledge as new ‘truths’ are discovered. You cannot afford not to be technical as a business analyst. This is the current ‘truth’ we must acknowledge.

The ‘shelf-life’ of knowledge

The ‘shelf-life’ of what we consider as ‘true’ knowledge about a phenomenon is getting shorter by the day. The truth about what we knew a few years ago is already being recalibrated. The ‘truth’ of how we understood our role as business analysts five years ago is shifting, has shifted or must shift. This is primarily because it is informed by the continuous evolution of the ‘truth’ about our understanding of customer behaviour, customer preferences, customer needs and wants, etc. In short, market forces have shifted, and this shift is underpinned by technological advances. It is underpinned by new ‘truths’ that these advances have enabled. Product development is no longer driven by a ‘push’ strategy, but by a ‘pull’ strategy. Technological capabilities have enabled customers to ‘pull’ new products from opportunistic and innovative corporates through the avalanche of data they generate daily.

With this understanding, how can you survive as a business analyst if you are not technical in any shape or form? How can you remain relevant in the jungle whose heartbeat is determined by technology, with all of its new ‘truths’? Over the past few years, I have attended and given many talks about business analysis, and most recently I attended a talk by Talifhani Banks. He is the Chief Data Scientist of a South African company called Analytics Advertising, and was recently voted as one of the Top 10 Rising Stars for Entrepreneurs in 2021 by Accenture.

To paraphrase his talk, he argues that if you do not skill up as a business analyst, you’re at risk of being declared irrelevant and not needed. In his talk, he argues that, in the corporate world – while they may not tell you – they easily identify you as the weakest link if you are that business analyst who will not keep abreast of the technical skills required to add value to your business stakeholders. It is inevitable, then, that from that point onwards, they will work on your exit plan. Now, what are these skills that you need to be technical in your role as business analyst?

Data analysis skills

I have already alluded to the fact that technological advances have led to data proliferation. And the latter is one of the drivers informing the emergence of ‘new’ truths about our knowledge of customers’ behaviour, preferences, needs and wants (regardless of the market segment). This has placed a business analyst in a position where his/her extraction, interrogation and presentation of data skills are exposed. One option is to rely on data analysts and data scientists to play an active role in this part, while a business analyst simply becomes a messenger.

Clearly, this is not an option that stands to help any business analyst eventually. Another option is to embrace data and see it for what it is – an emergence of new ‘truths’ about our knowledge of our customers. And if you move this new ‘truth’, then you must be keen to upskill yourself as a business analyst with the right tools and techniques of how to draw insights from data. You can then present these to your business stakeholders to enable them to develop the right products and services as ‘pulled’ by their customers. Rather than seeing data analysis as a separate competency, you should seek to develop the skill of data analysis and regard it as part of widening your skillset and adding to your toolbox of skills.

A quick Google search shows that data analytics and data science are among the highly sought-after skills in the world we live in. Further to this, Google lists r-programming, SAS, Tableau, Apache Spark, Excel, Rapid Miner and Knime among the top 10 tools to use to help in the transformation of data to gain meaningful insights. How many of these tools have you tried out? Or are you of the view that they have nothing to do with your role of gathering business requirements and/or writing user stories?

Fair enough, they may not be relevant to your current role. But I can assure you, they are very much relevant in your attempts to re-invent yourself and keep up with the evolution of the new ‘truths’ about what the business needs are. They are the new skills and techniques you need to learn to move closer to or enhance your technical knowledge.

Software development skills

Whenever the point of a business analyst being technical is raised, it is misconstrued to imply that he/she needs to be able to write code. This is not the expectation and has never been an expectation. However, while you represent the interest of business, as a business analyst you are in the trenches with technical colleagues, the developers, solution architects, testers and systems analysts.

In some cases, business analysts work in file-based environments, with no fancy GUI stuff. Often, there is a lot of handling data structures and back-end calls, APIs, xmls, etc, in these environments. It is, and can be, a source of frustration for you as a business analyst if, firstly, you are not able to follow the conversation (tech talk), and/or cannot contribute to the talk at all. Your confidence takes a knock and engaging with your colleagues in the realm of software development becomes a point of frustration.

Imagine having to ask a tester or a developer to select a few records from the database for you so that you can have a meaningful conversation with your business stakeholders simply because your SQL skills are non-existent. Does this dependency not affect your ability to deliver on time, because you now rely on someone else to have a gap in their schedule to do this for you? Imagine not being able to follow a conversation with your systems analysts when they talk about data and meta-data, stored procedures they must create or need to run at a certain point to meet a business requirement, because you have no technical background at all.

Surely these situations always put you on the back foot. What about being able to follow pseudo-code as they take the team through the solution design? While you will not be expected to write code, your understanding of what a piece of code looks like and reads like gives you an added advantage in your role as a business analyst.

For the sake of your professional sanity, you have to upskill yourself in some of these areas and embrace the technical nature of what you do as a business analyst.