As part of my role volunteering with IIBA UK, I recently hosted an online event exploring the extent to which business analysis professionals need technical knowledge and skills. With over 130 BAs attending, we explored what voices in the BA world are saying (professional bodies, certifications, thought leaders etc.), what recruiters are asking for in job ads, and what we’re actually doing in our day jobs.
Needless to say, we uncovered a range of views! There was a rough trend towards recruiters asking for more technical knowledge, and our industry suggesting we don’t need these to do our jobs. BAs in the workplace find themselves somewhere in the middle – and many BAs do come from technical backgrounds in development or data engineering.
My role in proceedings was to act as facilitator, and in the spirit of impartiality, I actively held back from sharing my own views. However, many of those that have worked with me in the past are likely to have heard me expressing strong feelings on this topic. I thought I’d share some of my thoughts on BA technical knowledge below.
Use of software applications
Obviously, we need to be able to use basic productivity tools such as the core MS Office suite. You need to be able to create documents and presentations, use spreadsheets, and manage your inbox and calendar effectively.
There are also several classes of tool that support particular BA activities – requirements management tools, online whiteboards, virtual meeting apps, process modelling tools, etc. While we certainly don’t need to be able to use every tool out there, I’d expect every BA to be proficient with at least one of each type, and able to pick up similar tools very rapidly.
Some tools (I’m thinking Jira!) are becoming so ubiquitous that knowledge of them can almost be considered mandatory. However, it’s worth noting that many features and functions may be more relevant to other roles (e.g. Scrum Master).
Data
Data is a huge topic, so I’m breaking it down here to better explain my thinking about what a BA needs to know.
Data analysis and insights
The ability to interpret data is really important. This means being able to consider averages, totals, trends, statistical significance. Crunching numbers can be crucial in determining what needs to change in the business (e.g. in Lean and Six Sigma), or in establishing the business case for a solution. Communicating our insights effectively is also important.
Some BAs might be equipped with the ability to mine data directly (e.g. performing SQL queries) or to produce great visualisations with tools such as PowerBI – but these are extras in the BA toolbox, and I wouldn’t expect these activities to be demanded as part of the job role. I feel very strongly that building dashboards for operational use is not business analysis!
Data structures and storage
BAs need to be able to consider abstract entities, their attributes, and the relationships between them. This is a great way to reveal business rules and requirements that a system will need to meet. This work can include creating entity relationship or class diagrams. However, I don’t believe BAs should go as far as designing database structures, worrying about foreign keys, or defining table names.
Software design and development
Much of a BA’s work is likely to involve the implementation of new technology, and so we need a great understanding of system development lifecycles and methodologies. This means familiarity with Agile principles and common practices, an understanding of how development teams are typically structured, and familiarity with the high-level steps needed to get new software “live”. Every organisation has its own way of doing things, so getting familiar with specific practices where you are is really important.
There are a number of non-functional requirement categories that may require some technical exploration, such as performance, capacity, access, and availability. When I consider these areas though, I would rarely be trying to express these requirements in technical terms – rather, I want to ensure that stakeholders and developers are on the same wavelength regarding expectations, constraints, and trade-offs. Different domains and industries may have varying need for specific technical definition.
Interface design is a blurry area. Creating wireframes and mock-ups of interfaces is a great way to elicit requirements, but I don’t believe BAs should be trying to define what how an interface should look or function. There are experts out there that can do that! However, we can work to define requirements around accessibility and useability that can be factored into UI/UX designs, and BAs definitely have a role in aligning system interactions with wider business processes.
We don’t need to be able to code, and we don’t need to configure (or maintain!) off-the-shelf products either!
I don’t believe system testing is part of the BA role. We help the business confirm that new technology meets its needs, but we’re not here to verify that each feature works before it’s put in front of users. We are often heavily involved in supporting (but not performing) acceptance testing – helping the business design its approach to testing, identifying test scenarios, and managing the inevitable wranglings that spin out of the testing.
Hosting, integrations, and infrastructure
We need to understand current models of how systems can be deployed and licensed (e.g. SaaS) as these can have implications for the business case and sustainability of any technology options. When we’re helping the business choose solutions, we need to consider how these will be supported, maintained, and paid for over time. There may also be legal or practical implications about where data is held or how it is shared.
I wouldn’t expect BAs to know or understand much about servers, networks, or how systems talk to each other. I know some BAs work on projects involving the creation or use of APIs; while we may need to understand the opportunities or constraints an API might present, I’d argue we don’t need to understand how it works “under the bonnet”.
Hot tech issues
In the IIBA UK discussion, we talked about three different hot topics in technology. I’ve described my thinking on the technical knowledge we need in each of these below:
Cybersecurity
BAs should absolutely be part of how organisations approach cybersecurity – particularly because the weak point is always people rather than technology! We can help design processes and interactions that strengthen security and reduce risk. We can also ensure solutions are chosen that meet regulatory or industry standards. However, I don’t think we need to understand the intricacies of encryption protocols, two-factor authentication, or how a firewall works!
Blockchain technologies
A year ago, blockchain seemed to be talked about constantly – it seems to be less of a hot topic right now though. I think it’s worth BAs understanding the core concepts about how blockchain technology works, its pros and cons (e.g. power consumption!), and typical applications (e.g. cryptocurrencies). But no more than this.
Artificial Intelligence
A huge topic, and an area that’s developing further every day. There’s a real risk that whatever I say today will rapidly become irrelevant or embarrassingly wrong! BAs need to get up to speed with the opportunities and challenges AI (and particularly generative AI) are likely to bring. AI has the potential to transform how business analysis itself is conducted, so it’s crucial we’re alive to what’s happening.
I don’t think we need to become master of prompt writing – although that could change rapidly – and we probably don’t need to know more about how machine learning or large language models operate “behind the scenes” at anything more than a high-level.
BA technical knowledge – in conclusion
We need to know enough about technology to have useful conversations with those that create or supply it, and our role typically involves us acting as a sort of “translator” between IT and business stakeholders. We need to be aware of emerging trends, and how these may affect the business, customers, and our own work as business analysts.
The business analysis world – professional bodies and the like – seems largely to share my perspective. IIBA’s certifications don’t demand any deep knowledge of technology. The International Diploma in Business Analysis (from the Chartered Institute for IT) can be obtained with little more technical knowledge than being able to produce a class diagram. They do offer an optional module in modelling information systems though.
My hunch is that while employers do understand technical knowledge and skills may not be part of business analysis, they are simply trying to build an ecosystem that gets things done; if having a BA mining databases with SQL or performing system testing helps them do this, they’re going to hire for it.
One final comment – while I’ve expressed some reasonably forthright opinions here, I’m less hung up about what BAs should or shouldn’t be doing, and more interested in where we’re likely to add the most value and how we remove obstacles to achieving this. Certainly in large organisations, there will be plenty of tech experts who can provide the deep knowledge of technology; there are fewer people who can understand the people, process, and strategic perspectives that the technology needs to support.