In my experience there is much confusion related to the roles played by the systems analyst.  If you take a look at the recent industry job posts you'll see a number of different titles given to the business analysts: business analyst, systems analyst, IT business analyst, requirements engineer, etc.

I've just finished a blog entry on this topic in an attempt to somehow provide some clarity on this topic.  Having said that, this blog entry is just a start so I invite you to join the discussion.  I would love to hear your thoughts!

Here is the post:

Business Analyst Roles AKA “In Search of the Business Analysis Holy Grail”

Since I hope to get feedback from the community, please use this forum thread to post comments and/or questions related to this subject.

Thanks much,

- Adrian

You are correct the term "business analyst" is the major source of confusion since outside of IT the term means something else.  If we could reset the clock (as an industry) and start again I would probably keep the "business analyst" term to mean the specific non-IT role (business improvement, etc.)  and instead of using the IT Business Analyst term we should use maybe something like "Requirements Analyst" or "Requirements Engineer".

This would result in something like this (in theory):

• Business Analyst (business only - no IT)
• Business Process Analyst (deals with process modeling - maybe business only or may have technical skills)
• Requirements Analyst/Engineer
• Systems Analyst/Engineer

The term "Engineer" generally implies a more structured, disciplined, and empirical approach to the task.

The Reality = it is probably unlikely that the term "business analyst" will cease to be used in the IT world.  Even this community portal uses the term business analyst to refer to IT Business Analysts (requirement engineers).  I think the best we can do for the time being is raise the awareness of the problem so that at least recruiters, trainers, employers, etc. do a better job when defining the roles and responsibilities of the analyst.

- Adrian

Hello Adrian

First off, thanks for spreading the word about my blog entry. I would like others to examine it and share their opinion. A fine piece of work you've shared with us as well. I especially liked the second diagram. I'm a diagrams person myself; just about every page of my notepad at work is riddled with squares and circles and arrows. Your second diagram succintly summarized the main points of your entry.

I do have a comment about the "IT Business Analyst" slab though, which is the theme of this reply. The role starts at "Determining which tasks/steps to automate" and ends only half way down "Implementing the features of the new IT system". It's the start that caugt my attention more than the end. I'd like to know your rationale behind the slab's starting point. Maybe you've guessed why I'm focusing on it...Right! I consider myself to be an IT Business Analyst. And I'll tell you why.

First off, I come from a business background; I have an MBA in Finance. To bolster that, I have a hardcore interest in entrepreneurship followed by corporate finance. One my hobbies is digging into business history, and I subscribe to not an IT magazine, but INC., which is a entrepreneurship publication released every month.

At work, I'm expected to build relationships with and harness answers from the business for our IT projects. In that you accurately said "The analysts in [the IT BA] role generally begin their work once a given IT project has been initiated." That's exactly what I do! Projects come up and I'm assigned to one or two (or even three), and the first thing I'll do is shadow the business user in what s/he does (assuming I haven't worked on the previous release). From then on, it's me and the business. I'll understand the system as-is, understand how the project scope is going to make the their jobs easier, and continue on to elicit, understand, and advise them on their specific requirements. I think this is why our experts and peers have added the word "business" as part of many of our titles. After all, we develop systems to assist the running of the business.

The reason "IT" precedes "BA" in the title, is of course because we now have to communicate those requirements to developers. More than that, there is the expectation of us that we have some idea of why they develop the system in the way they do. What system limitations exist; why is a particular requirement unfeasible; why do they code the way they do; how can we use technologies already built to serve again? I think business analysts need to understand these IT aspects of the project so they know what the hell happened to their requirements when they handed them to development! Not to mention, when we understand the technical side, we have something concrete to communicate to the business when they wonder what the hell happened to their requirements when they handed them to us!

Hence, I believe most of us are IT BA's. Equally so, I think most of us are Requirements Engineers as well. Most of us are also Business Systems Analysts and Business Process Analysts. The pattern that emerges here in that whatever we call ourselves, or whatever role a recruiter or a client seeks us out by, we all place an equal emphasis on service to the business. All of us inherently are here to serve the needs of the business. What does indeed differ mostly amongst this array of terms, in my opinion, is the degree to which us analysts get involved on the technical side. If you're more skilled/proficient on the technical side, you're now more of a Systems Analyst for seekers. If you tend not to enjoy the technical side but gravitate more towards project management, recruiters use the term Business Analyst. Even though I'm more proficient on the business side than with stored procedures and orchestrations, I still prefer to be termed as an IT Business Analyst, because I cannot complete the chain without IT.

Please, I'm always open to opinions and comments from everyone. Adrian, thanks again for your valuable insights.