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.