The business analyst & the business systems analyst

In the past, I have asserted that when gathering high-level business requirements, one must aspire to be design agnostic. This is because the consequences may be severe if an inappropriate solution influences a requirement set.

Eventually, there will come a time when a solution must be defined. As a project progresses through the design stage of a system development lifecycle, the methodology, tools, 3rd party applications and approach have already been agreed upon. At this time, requirement documentation becomes much more detailed.

The BA vs. the BSA
So what is the difference between a business analyst (BA) and a business systems analyst (BSA) anyway? I've worked at a few different companies and seen the two terms used synonymously. But from company to company, there is a vast disparity in meaning.

For me, the distinction lies with whether the analyst is more closely aligned with the business side of things or with the IT side. Business analysts interact with the business to understand what is needed. The BA then liases with the design team (or through a BSA) to transfer knowledge of the business' objectives and needs.

Contrast this with business systems analysts who create specifications (to fulfill the business requirements) and interact more closely with the development & design staff. A BSA will generally tend to have more technical expertise than a typical BA.

Determine the skill set needed
Because of the varying composition of project teams and skills, individuals in BA or BSA roles may be asked to perform many different types of duties (as well as aspects of a BA and BSA role.) Rather than debate whether someone is a BA or a BSA, focus on how he or she has been involved in past projects.

During the different stages of a system design lifecycle, what was the role that was played?

Does the role require someone to be involved at the inception stage of a project or is the majority of the role to provide IT teams with specifications?

Does the role require a significant amount of client interfacing or does the role require significant technical knowledge?

What gaps in the team is one trying to fill?

Spend time understanding what is needed rather than what to call the role.