What is the Difference Between a Business Analyst and a Systems Analyst?

Do you find the systems analyst profession and business analyst and business systems analyst profession to be different? I have been doing research and it seems this all points to pretty much the same profession–bridging the gap between end user’s and IT professionals, software developers, software engineers, etc. I suppose it depends what company you work for where minor things may change.

Let’s look at this question from multiple perspectives.

Is There a Line Between Business Analyst and Systems Analyst?

The line between business analyst role and systems analyst role is not a clear one and I’ve found that the business systems analyst role sits right in between. As a profession, we might choose to distinguish the roles, giving the business analyst domain over the business and functional requirements and the systems analyst domain over the details of the system implementation.

We’ll look at commonly applied definitions for systems analysts and business analysts and then discuss the role that misleading job titles play in answering this question.

What Does a Systems Analyst Do?

In general, I’ve seen systems analyst roles that require a stronger technical skill set and often involve systems design responsibilities. Systems analysts tend to dig into the details of how a requirement might actually be implemented in code. This is still “bridging the gap” but it is bridging the gap at a different level of detail. They tend to start “bridging” with a set of good business requirements and stop when they’ve spec’d out a system design plan.

What Does a Business Analyst Do?

On the other hand, a business analyst might start “bridging” further up the stream in terms of business needs and problems and stop “bridging” at the functional requirements specification or at what the system will do and leave it to a systems analyst or a senior developer to determine how to do it.

How are the Business Analyst and Systems Analyst Job Titles Used?

But then job postings with requirements and qualifications that don’t meet the professional guidelines come along and skew the answer. For example, early in my career, I held a “Systems Analyst” position that was really mostly a business analyst position with a few light systems analyst responsibilities. Last time I checked, that team was still made up of “systems analysts” even though they hold many BA responsibilities. I’m sure this is not an isolated instance. (And this is why I’m often a proponent of tweaking your job titles in your business analyst resume). Then there is also the “BSA” or “Business Systems Analyst” role, which blends both professions into one role.

>>Find Out More About Business Analysis

Click one of the links below to learn more about the business analyst profession:

Books and Courses You Might Be Interested In

Comments

‘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.

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.

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.

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, 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.

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.

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.

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.

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.

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!!

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.

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.

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, 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

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!

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

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

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.

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.

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.