No problem!  The duplicated post were removed and the formatting fix (good enough)...

Based on your description I agree with you that you are an IT Business Analyst - at least according to my definition.  One of my main goals is to challenge us all to be a bit more careful when using terms that define the role/titles of the analyst.

First of all I wanted to respond to many of the comments and feedback posted on the Snapshot of Business/Systems Analyst Profession page related to the fact that the definition of the business analyst did not include any business-only activities aimed at improving the business without IT.  I have to agree with many of those who commented.  We need to recognize that there is a clear (maybe not in all cases) distinction between the business analyst (who analyses the business for the sole purpose of improving the operations and business model of a given organization) and the IT business analyst (who, generally, is not concerned with changing the existing business processes and models but is more involved with identifying those parts of the business process/model which can be automated in order to improve the efficiency of the business).  Sorry for the long sentence...

Another thing that I wanted to point out is that on the IT side there are a few broad types of organizations/projects as they relate to the use of analysts:

• Very small organizations or projects may not even have a dedicated analyst.   In these cases it is not uncommon to find the "Programmer/Analyst" title.  This is the one-man-band.  I've been there done that.  In the morning put on the suit and met the client to discuss their requirements then came back to the office made a couple of napkins sketches and had lunch.  After lunch I sat down and coded what the client wanted.  The next day I QAed my work and then went back to the client and told them here it is.  I know it's an extreme example but I think it makes the point.
• Mid-sized projects/organizations may have analysts which are more of "Business Systems Analysts".  They gather the requirements, create the design and functional specifications but they don't write the code.
• Large projects or organizations need to be able to scale and the one-man-band does no longer work.  These are the instances where one will find the "IT Business Analyst" (aka Requirements Analyst) who gathers and documents the requirements and creates the conceptual UI design.  The they have the "Systems Analyst" who takes the requirements and turns them into functional or systems specifications.  In these organizations you may even find dedicated "Business Process Analysts" (aka Workflow Modelers) who also participate in the system development effort.

The last thing I wanted to mention is that most analysts can't do it all from the beginning to the end.  Most consultants working for small companies are very entrepreneurial in nature and actually enjoy doing it all.  90% of the analyst constituency can probably focus really well on only one area - maybe two.

The diagrams I created probably need to be modified to show more clearly that the cut between the various roles is not as clear as the diagram makes it show.  It was just an exaggeration to drive the point home.

The reality looks more like RUP style diagram with overlapping activities and competencies among the various roles:

OK...  I'm done for now... ;-)

- Adrian

Hi Craig,

I agree with you on the key role that requirements play for all analysts - after all they are "required":

• Business requirement documents are, of course, requirement centric,
• Functional specifications must be based upon the requirements,
• The Code must fulfill the requirements,
• QA & UAT efforts must verify requirements have been met.

My thoughts on the BA roles were not meant to be just a philosophical point of view.  I didn't try to capture what the BA roles should be but, from experience and observation, I tried to provide some clarity on the roles and titles which are common in our industry.  Having worked on small, medium, and large projects (and organizations) I have noticed a significant difference in what's expected of the analyst.

I also wanted to provide some clarity on the "reality" of confusing job titles. 

For smaller organizations and projects, the analyst classification that you provided will probably work well.  However, in very large organizations and projects the reality is that the role of the analyst tends to be a lot more fragmented as very few analysts can handle all the tasks from business modeling to technical design.  In order for such organizations to scale they need to be able to define (and train) very specific roles which can be performed by ordinary analysts. 

For example, given a very large project, it would be very hard for any company to recruit and retain 100 analysts who all have strong understanding of the business model, great communication/soft skills, outstanding analytical and problem solving skills, expertise in business process modeling and simulation, knowledge of systems modeling techniques (UML, etc.), ability to create functional/technical specs, etc.  The reality is that it is much easier to hire 25 business analysts (the specific - business only - title), 25 business process analysts/modelers, 25 IT business analysts, and 25 systems analysts.

- Adrian