I’m often asked about the difference between business analyst and systems analyst roles. In reviewing job profiles, the roles can seem very similar. In this quick video, I describe how both roles are defined so you can decide what career path you want to pursue.
For those who like to read instead of watch, here’s the full text of the video:
Hello, my name is Laura Brandenburg from Bridging the Gap. Today, I want to talk to you about the difference between business analyst roles and systems analyst roles because we get a lot of questions about this at Bridging the Gap about whether they’re really the same, or are they different, or how those titles in those job roles are used within the profession. I want to empower you to understand the nuances within the profession and the path that you might, personally, want to take as you form your career plan for your business analysis career.
Job Titles
First, just a note about business analyst job titles. They are used extremely inconsistently within our profession.
What I’m going to share with you in this video is about the roles and the standard definition of those roles. How you see a specific job title in your local market and the job postings on your job board, even within your company, might be different from what I share with you today. You always want to look at the responsibilities below the job titles to make sure that you’re understanding the role that a specific organization or employer is looking for you to fill.
What Does a Business Analyst Do?
First, let’s just talk about what a business analyst does, somebody in a business analyst role. Typically, that role is defined as someone who is enabling change, who is responsible for the requirements, the development of the understanding of the business needs to help create a solution, envision a solution to solve a business problem, or to add more value to the business.
Most typically, a business analyst will analyze the process and also analyze the software that’s going to help us improve or implement that process.
In the software, we look at both functional requirements and data requirements. What does the software do, how does the software store information? It involves the heavy relationship with the business and the technology teams, and it’s what Bridging the Gap between business and IT to make sure all those stakeholders have a common shared understanding of what the software solution will be to address a specific business process or business problem.
What Does a Systems Analyst Do?
What does a systems analyst do? How is that a little bit different? What we typically see is that the systems analyst role focuses more on the technology aspect of the solution. You wouldn’t have a systems analyst on just a business process change.
Where a business analyst might work on something that doesn’t actually involve a software change because they just might fix the business process, systems analysts only come in when there is a software change. They’re probably going to go a couple of layers deeper into the software requirements and not just considering the what of the software of how the software needs to function from an end user perspective, but also looking into how that software is built, how the software is configured, potentially, how multiple systems are going to work together to accomplish a specific objective or meet a specific functional requirement.
They’re going to be peeling away the layers of that system and that technology to make sure that the solution, again, meets the business need, but they’re focused more in on the software aspect of the solution, probably not on the business process side. They might be doing more data modeling, more data design, how does data move between systems, how are the systems connected, working and integrated together to meet a feature.
Sometimes, even doing some level of technical coding or programming; sometimes the job title is used in that way, but they are definitely understanding how the code is written, how the code works, and, potentially, just collaborating with other professionals who are actually doing the coding itself.
That’s the difference between the two roles. That business analyst role being more business focused on the business process side, and the systems analyst role being more technically focused on the technical side.
Many Business Analysts Are Also Systems Analysts
Now, many of us play both roles. In my first job as a business analyst, I also had a lot of those systems analysis responsibilities. I wasn’t spec’ing the integrations between the systems, but we had heavy data modeling requirements that required us to understand how that database was built, how the application cleared the database in order to build some specifications that were more technical specifications. You can have a blend of both.
We started with, “What does the product need to do?” “What are the end features that the product needs to do?” In some organizations, you will see a combination of the roles, and that requires a lot of business and technical acumen.
In other organizations, you will see two roles where you have a business analyst and a systems analyst. What’s important, then, that there are tight connection and collaboration between those two individuals. What tends to happen is the business analyst, then, has their requirements, and the systems analyst create their requirements, and there’s an extra layer of requirements documentation in between those two roles as part of that hand-off.
You need to make sure the translation process of what the business wants and what the end problem that’s being solved is making its way through to the more technical specification documents. There should be a lot of connection and collaboration between those two individuals.
Where Do You Want To Go with Your Career?
Where do you want to go with your career? It’s up to you.
- If you like the business side more and you want to be more in connection with business users and solving business problems, you might want to gravitate more towards the business focused role.
- If you like the technology, even if you don’t want to code anymore, you have a deep technology background, that you want to leverage that technical understanding without having to write the code, systems analysis could provide a great career path for you.
What’s Next?
I always like to say you get to create the career that you want and business analysis, as a profession, just creates tons of opportunities for you.
If you’d like to learn more about starting your career as a business analyst, go ahead and click below. There’s a link to a free training on your Quick Start to Success as a Business Analyst. There are additional resources about what a business analyst does, what process to use to be effective, and what are some of the key skills that you need to be successful in today’s competitive job environment.
I hope that you will join us. I’d love to help you take the next step in your business analyst career.
Again, I’m Laura Brandenburg, from Bridging the Gap. We help make career professionals start business analyst careers.
Hi Laura Brandenburg
Thank you for the information . It is very helpful
Crystal,
You are welcome. Congrats on your new opportunity and I’m so glad the article has helped you. You are right, they can be 2 separate roles, but often we find them combined. Or, it could be that it is a BA job under an SA title, which is also very common and was my early career experience. It really depends on the job responsibilities.
The courses page lists all the courses we currently have available. Some are only available right now as self-study.
https://www.bridging-the-gap.com/business-analysis-training-courses/
Get in touch via the contact form with what you are looking for and we can make some more specific recommendations for you.
Laura
Hi Laura,
I haven’t been here for awhile, just really busy with study and volunteer job these few months.
I just got a job offer as system analyst trainee for a big finance/ insurance/ banking company, the initial contract is 4 months. I was just doing online searching try to find out more article about the difference between business and system analyst. Then I am here 🙂
Although system analyst requires a lot of tech skills, such as a good programming foundation– which I don’t have! but after a few hours online research, most of article point out they are actually have quite similar approach as not much organization really separate these 2 roles ( wish I HOPE it is the case in my company as well)
Just want to say thank you so much for all of the article online, which helps me a lot! especially the local IT organization volunteer idea which is the milestone for me to launch this job!
Thanks again and I will come back to study more your online resource soon. Just wondering do you have any training class commerce soon? would like to be equipped some BA/SA knowledge before start the role.
Cheers,
Crystal
Hi Pierre, Nicely put. Indeed as businesses and technology solutions have gone more complex, business analysis has emerged as a specialty instead of a small responsibility within a larger programmer or programmer analyst role. That’s an important part of our history that we lest not forget!
For readers interested in personal stories from BAs growing up in the profession through this blended SA/PM role, you might check out the interviews with Steve Blais and Rick Clare, both of whom came from this background.
https://www.bridging-the-gap.com/essence-business-analysis-steve-blais/
https://www.bridging-the-gap.com/elevating-the-role-of-the-business-analyst-interview-with-rick-clare/
There is a historical dimension to this as well.
Back in 1981, I took a ‘programming’ course and the team roles then were ‘programmer’ (what we would call a developer or software engineer today), operator (who loaded the tapes and took backups) and systems analyst. The SA, then, was what we call a BA, an BSA, an SA and a PM!
Over time, we have seen specialisations develop in IT, with the BA and SA roles diverging somewhat.
If the organisation is small, a BA/SA would look at both the business and the technical side of the problem in equal measure.
If the organisation can afford, the BA can focus more on the business side, while keeping an understanding of the technical challenges. The SA can worry more about the technical side of existing systems and proposed architecture, while still keeping an eye on the business needs.
Pierre
Caroline,
That sounds like a great approach and that it would help individuals on both sides stay involved and informed without the burden of too many extraneous meetings. Thanks again for sharing. I am sure some others are facing challenges in this area and will appreciate hearing how you’ve worked through them.
Laura
Hi Laura
On our most recent project we found that the best time to bring our SAs into our business discussions is when we have an initial draft of the requirements and are doing a walk-thru with the business. Bringing the SA’s in before this point is usually very frustrating for them because we are still going back and forth with the business on issues. “Just tell us what you want” is usually their complaint!
We’ve also found its a necessity (for our sanity!) that the BA’s sit in on solution discussions. We can ensure the requirements are being met by the solution and can be traced. We’ve found it a good thing to keep watch for scope creep in case one of our SMEs gets too excited when they hear what the system CAN do. “You can do that TOO? Wow – that’s great! You can put that into the solution for us, can’t you?”
Your point is well taken – it is more of a gray zone, or a middle ground than I made it sound in my first post!
Thanks
Caroline
Thanks, Caroline, for your detail on how the role works in your organization. Do your SAs have the opportunity to shadow you in your conversations with the business? And do your BAs stay involved in some of the solutions discussions? In my experience in what would be considered a BSA role in this context, many trade-offs happen in the middle of that space, and some shared knowledge and input might be beneficial.
Laura
I thoroughly enjoyed reading all the comments above which illuminate and give insight on the dilemma of BA vs SA. I faced a similar dilemma when I recently joined an organization that never had BAs before. It has been a struggle to define the BA role in the context of the BSAs, SAs and business SMEs in the organization. The business team breathed a sigh of relief when BA’s started helping them defining their process and requirements but the BSAs (and some more business oriented SAs) felt like their territory was being usurped even though we tried to be very tactful. We quickly learnt that you can’t please everyone all the time and some tough decisions had to be made and lived with.
We’ve found that in order for us to be successful the BAs need to focus on the “what” needs to be done (down to the system interface level) and the SAs need to focus on the “how” the solution supports the “what” – from the system interface on down, sometimes into the code. That distinction typically translates into the BA working on business requirements from process down to the functional requirement level and the SA taking over at that point with system design.
To define this interface more closely – our BAs will flesh out some system behavior with the business in terms of sketches of screens/detailed use case steps and business rules. Our SAs take over the process of fleshing out the solution in more detail and typically lead the development team in their technical design/development process.
One downside of this arrangement is that we sometimes find our carefully traced functional requirements changing as the more tangible solution discussions highlight better ways to accomplish some detailed requirements. When this happens its usually because the BA got caught in the trap of defining the how and not the what!
We are still working through this arrangement of the BA and SA roles and how they work together. As we do, we would appreciate any thoughts/comments that any of you might have on our interpretation of the BA vs SA roles. As an aside – we are a mid-sized organization with a small IT group in the midst of a changing platforms to more “contemporary technology”. The BAs started in IT but are moving into a “process group” that is central and not affiliated with any business area.
Thanks
Caroline
Tom, This article (discovered via a Tweet by Julian Sammy) highlights the historical use of the systems analyst title and provides a nice history of the role as well.
http://www.educationerd.com/2009/12/20/the-ratio-of-analysts-to-programmers/
Hi Landon, In my understanding, the financial analyst represents a different profession entirely and the business analyst title is often used for positions that involve analyzing a company’s financials, especially during a merger and acquisition process.
Laura
Excellent discussion; I have a question to raise; doesn’t the title “business analyst” have the additional connotation of primary job tasks possibly analagous to those of a financial analyst?
I won’t muddy the waters by stating my two titles, one more official than the other…
Historically, the Systems Analyst “owned” the application and told the programmer how/what they wanted changed. They often did all the user interfacing on larger projects. This is back in the 1970’s now. When I started paying attention again it looked as if the SA had split into two and become a PM or a BA. That is why I went out and got a CAPM. The I realized the stuff that was really interesting to me seemed to all be in the BA portion so I am busily trying to become a better BA.
Huzzah Meyer!
Again that notion of managing expectations!!!
That is a huge – and vastly undocumented – part of our role. I would also add that BAs/ BSAs should be prepared to highlight benefits and risks to clients be they related to:
– a process decision
– a tool set purchase
– their decisions around importance of requirements
In the end, the client will make the decision but I am 100% with you on helping to set expectations and offering (sometimes unsolicited) advice. Please ensure the advice is backed up with numbers!!
Cheers
PT
From my observation, the customer’s technical maturity is a big factor. Mature organizations want BA to collect and document requirements. Consideration of solutions is done by “solution architects”. In this model a BA who strays from strict requirements processing will risk trouble. But is smaller or less-mature organizations, expectations about BAs are very different. Such organizations see requirements as pretty obvious and care much more about the solution. When we consider the effects of trends on the differing requirements, we see that the BA title is regarded as more recent that “systems analyst”. So, manage your customer’s expectations or learn fast.
Just for clarification, Kevin was right, I am referring to systems as in the “Systems thinking” reference he provides. My point is specifically that BAs are SAs in this sense. Elucidating the deeper structures of office behavior (as in BPM) is precisely the activity of analyzing the systems that support the business (whether the technologies are English and telephones, multi-part carbon paper forms, or wikis).
It is the BAs (SAs) responsibility to dig beneath the individual events and surface details to find the essential properties, document them, and explicate how existing (or sometimes potential) technical solutions succeed or fail in providing the necessary properties to achieve the organization’s goals.
Good discussion all. — Bob
Kevin, Yes, I agree Bob is saying something different. I mistakenly referred to Bob when I meant Trond. My mistake (and now corrected).
Kevin, I typically think of a role as a set of responsibilities. While I can see that the competencies required by how we’re broadly defining BA vs SA would be very similar, the responsibilities might be very different. How do you define “role”? I do see your point though on how I was thinking too narrowly about “systems” and that this can be understood to as a much broader concept than an IT system.
Paul, I have to say that my heart jumps for joy in reading your comment. And I essentially agree that it doesn’t really matter and that no matter how we slice and dice the roles, each position is going to be unique.
I think many professionals are looking for a role to sort of hang their hat on, to be able to say “yes, I can fill that role” instead of “I can do this laundry list of things, what do you need”? The second set of statements and questions takes more diligence, preparation, self-awareness, and makes it much harder when applying for positions. But in the end, you are much more informed and probably waste less time applying for positions based on a title that doesn’t reflect the role.
Thanks for your comments!
Laura
All,
As with many things in life, when you try and place a neat “package” or “definition” around it the world passes you by. In truth, when someone asks me what I do I say I am a business systems analyst. I then begin to tell them that I am “jack of all trades and master of none”. What this means is, I have enought business background to guide an organization through an analysis ( at a sufficient level) but may not use the latest BPMN notations ( as per Voltaire “perfect is the enemy of the good”). I can then use various techniques to identify Use Cases to enable some or all of the steps in a business flow in an IT system.
Further to that, I can facilitate JAD sessions, gather functional requirements, mock up screen shots and put a package together for coders to code.
For any business, I can do some or all of these things and so I always ( always) look at the contract description before I bid and I always make it clear to my employer what I can and cannot do for them. There may be times when I need to bulk up on a skill or learn that new notation that this client is adamant about but I am for “the good” and not “the perfect”.
I think that if we describe to clients what we can and cannot do for them then we’ll avoid the hassle of worrying about titles.
Just thoughts from snowy Ottawa 🙂
Laura, I think Bob is saying something slightly different…that all BA work involves systems in the broad sense–a set of components or elements that interact in a number of ways to produce an outcome (see Systems Thinking: http://en.wikipedia.org/wiki/Systems_thinking). A system, in that sense, does not have to have an IT component.
If that’s correct, then I agree with him. We didn’t use that term in the BABOK Guide because people in IT equate “system” and “software”.
I”m not convinced that there are two different roles, though. I’d describe them as specializations of a single role. The competencies are the same, and the only real difference is in the technical skills you have. A business-focused analyst can learn UML and become an IT-focused analyst–it’s not like trying to transition to the role of project manager which requires a different mindset and skill set.
Bob, Kevin, Trond, Thanks for your comments. If I could summarize an answer to the reader’s question I’d say that Bob, Trond, and I are in agreement that there are two different roles here and that these two roles are sometimes combined into one position. I myself had held many “IT Business Analyst” roles which might just as well be thought of as “Business Systems Analyst” or simply “Business Analyst” (the title I prefer for it’s simplicity and the fact that there is a profession emerging around this title.
Bob, I would disagree that “Business Analysts” must be “Systems Analysts”. Kevin is the expert on this, but I know that there are BA roles that do not involve directly changing business systems, they are instead focused on business process changes.
I do agree with your conclusion however, when it comes to positions that “the distinctions [between the titles] can best be thought of as historical anomalies or dialectic variance based on corporate culture.” I think what we see is that organizations learn about the more “standard” definitions of a BA role and make efforts to move their position (whatever it’s called) to be more aligned with standards. And that’s at least one way how you get a variance amongst position titles.
Laura
Regardless of how the terms are used (and, as you describe, actual usage is inconsistent), it seems clear to me that Business Analysts must be Systems Analysts, that is professionals that analyze systems, specifically business systems.
Whereas it would be temping to try to distinguish BAs from SAs, perhaps by distinguishing non-technical (“business”) systems from technical (or “IT”) systems, any such distinction must at best be specific to the community adopting these patterns of usage, and will not be supported across all employers. In fact most business systems can be described as complex information systems (even if they do not use computers). Further describing businesses in terms of such systems is best handled by BAs.
To sum up, it is my opinion that the distinctions between “Business Analyst”, “Business Systems Analyst”, and “Systems Analyst” can best be thought of as historical anomalies or dialectic variance based upon corporate culture.
Seems I get this one about once a month. So, based on my research, there are at least five definitions of “systems analyst” in current use:
1) As a synonym for business analyst;
2) An IT-focused business analyst (in organizations that split the BA role into more than one specialist role)
3) A hybrid BA/developer
4) A systems architect (with no responsibility for requirements)
5) Help desk support
IIBA’s definition of “business analyst” includes 1 (obviously) and 2, as well as the BA part of 3. Because of the confusion around what the term means, though, you’ll find it hard to pin down a definition. The actual practical difference between the two would lie in the techniques they use–if you’re business focused you’ll care more about process models, where an IT-focused analyst will likely be more interested in data models and use cases. My own experience is that the difference only seems to come up in larger companies–smaller organizations don’t bother to separate them out.
Pingback: Tweets that mention Help a BA!: What is the difference between a business analyst and a systems analyst? -- Topsy.com
Laura, it sounds like we generally agree on this issue.
‘Business analysis’ is a study of what the business is supposed to do, while ‘systems analysis’ is a study of the business’ systematic behavior (hopefully, based on what it’s supposed to do) with a particular emphasis on its methods and tools; in other words, how it does things. This has led me to the conclusion that pure business analysis is insufficient for just about any information technology project, while systems analysis generally misses the foundation of the work required and therefore becomes an almost insurmountable challenge for analysts.
The solution? While both roles are perfectly beneficial to an organization, for IT projects it seems ‘Business System Analysts’ can be more productive in most cases.