When I was looking for a job a few years ago, I thought it would be an easy thing to do. Searching for “Business Analyst” on major job websites would take a few minutes, and I would have plenty of interesting positions to choose from. I was shocked to see that it wouldn’t be as easy as I thought; almost half of the positions were not about what I thought was Business Analysis!
Some were asking for a Master degree, others for an High School diploma; some required expertise with some specific modeling tool, or knowledge in a programming language. I thought to myself : was I really a Business Analyst at all?
A few years have passed, and I still see this confusion in organizations. Some BAs are analyzing business processes while others perform code reviews (I’m sometimes doing both!) Is this normal?
Over time, I came to the conclusion that Business Analysis cannot be seen as a unique concept. We often refer to the brigde analogy when talking about the Business Analyst (as being a bridge between business & technology); like there are many bridge types, there are also many types of Business Analyst.
The easiest way to understand it is on a business/technology continuum; a Business Analyst will always bridge both worlds, but he can be more on one side than the other. What does this mean in the real world? Let’s see some examples; for those of you who are still looking for the quiz, here it is (well, sort of)!
The Strategic Analyst
The Strategic Analyst focuses on the organization as a whole, and works with the high management to understand how the organization can support the business objectives. He analyzes and defines business strategies, identify strengths, weaknesses, opportunities and threats (see what I did here?) in the organization and evaluates the feasibility of these strategies.
The Strategic Analyst usually doesn’t go deep into details, and prefers to focus on the big picture. He helps to define the organization projects portfolio, and prioritizes the most important initiaves to ensure that corporate objectives are met. He is usually involved in the first stages of a project.
The Business Process Analyst
The Business Process Analyst works to understand current business processes in the organization in detail. Understanding a business process means much more than modeling it with various formalisms; it also means understanding its performance metrics (efforts, delays, waiting times), the politics supporting it, the cost of each of its activities, etc.
This is critical information for the Business Process Analyst, as it will allow him to optimize the current processes using various techniques, and identify many requirements (aka use cases, user stories and other variations) that could lead to a system implementation. Like the Strategic Analyst, the Business Process Analyst is involved at the beginning of a project.
The System Analyst
The System Analyst (also known as the Functional Analyst) uses the high level, business process-based requirements elicited by the Business Process Analyst as his main input. User interface mock-ups, decision tables, system to system interfaces, logical data modeling and business rules documentation will help the System Analyst to describe how the system should behave in order to support the business processes.
Deep knowledge of the system behaviors and functions is critical for the System Analyst, which was not the case for the previous types of BAs. Pure technical knowledge might help him, but the key skill of the System Analyst is the capacity to describe the link between the business process and the system behavior (which is different from describing the technical structure of the system).
The Technical Analyst
The Technical Analyst is the one linking the business and system requirements to the bits & bytes of the system. He focuses on documenting the physical database structure, the modules that will have to be implemented and the way the business rules should be coded to ensure the system performance, stability and maintainability over time.
While some developers are good at executing what they’re told (which is not a bad thing at all), others are very good at thinking about how the system should be built to support the requirements before actually doing the job. The latter are usually good candidates to become Technical Analysts.
Which of these types of Business Analyst are you?
Being conscious of this reality, it is easier to understand why there’s so much confusion about the Business Analyst definition, and why it can be hard to find a Business Analyst job posting that really fits your profile (or simply understand what the heck BAs in your organization are doing).
If you’re starting a career in Business Analysis and feel like an impostor, first try to find which of these types of Business Analyst fits you the most. You might already be a good Business Analyst, only lacking some knowledge in other types of business analysis. It can help you identify your current strengths and weaknesses, and give you some insight about your future career choices.
As for myself, I’m more of a Business Process / System Analyst. I’m not technical at all, but over time, I developed some technical skills in order to be more independent to understand system behaviors (who’s ready for a code review session?) and do some data mining (an SQL query a day keeps ignorance away!). The cool thing about knowing this is that I can look for opportunities that help me focus on my strengths as a BA, while developing my other business analysis competencies.
Do you like what you’re reading?
Do you recognize yourself in one of these types of Business Analyst? Do you think that there are other types? Share your thoughts on the comments below!
Credits: colinbroug @ freeimages.com