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
Thank you Eric for this nice post. It will definitively help my students understand which type of BA they want to become!
Glad to know you liked it!
I also find this model useful to help students with a technical background to figure out how they can use their current skills as a solid foundation to other BA styles.
I am a combination of the last 3, that is to say, I am a Business Systems Analyst. As the field grows, so do the definitions. BSAs have been around for quite a long time now and are often confused with other types of analysts. I have addressed the differences in my Blog at http://www.amazingbusinesssystemsanalyst.net
It’s a great career…
It is indeed a great career! The good thing is that you can take so many directions over time that it never gets boring 🙂
Wow, great post and just what I needed! My goal is to move into a BA position (currently under review for a Junior BA position) with basically no prior experience in this role. I’m hoping my experience, knowledge, and solid track record within my current role will give me the advantage to move into this field internally. I would say my interests fall heavily within the Strategic and Business Process Analyst. Very good to know! I look forward to reading more of your posts!
I’m glad you found it useful! Even without specific BA knowledge, you have probably already performed BA tasks that will contribute to your success. You might want to read one of my older posts about the best way to become a good Business Analyst, it might motivate you to continue in this direction!
Article très intéressant! Il persiste effectivement dans le marché de l’emploi, une mésinterprétation ou à tout le moins, différentes interprétations de ce qu’est le rôle de BA en TI. Je crois que c’est à nous de nous adapter et d’assumer -honnêtement- son profil d’analyste en s’appuyant sur ses forces et en ne craignant pas d’admettre ses faiblesses quitte à y remédier. Au bout du compte, c’est la complémentarité -et la dynamique bien sûr- de l’équipe qui favorise la réussite d’un projet.
Thanks for the post!
Nice definitions. Like you, I’m a combo Business Process Analyst / System Analyst. Works nicely in my current role as I can talk both to management and developers in their language so they understand what’s what. And, with my technical skills (in SQL), I have the ability to look at how data is being written to tables or extracted for reporting and let developers know exactly what is wrong. Having a financial background, this has been extremely handy while programmers worked on period closings and financial reporting.
Thanks for the comment Sue!
I agree with you on technical knowledge; having data analysis skills can really make your life easier as a BA (which is incidentally my #2 tip to new BAs: http://www.ericthebusinessanalyst.com/junior-business-analyst-manifesto/)!