Hi Steve, Yes, I’d agree with your statements on general IT knowledge. As an example, last night we were loading up Netflix on the Wii and I starting thinking about just how this works. Who hosts the TV content? How do the following parts of the system interact: the Wii box in my living room, the Netflix CD we needed, the pieces and parts of “the cloud”?….Luckily my husband is an architect so he had some of the answers…that to me is just enough general IT knowledge combined with systems thinking and is often enough to be successful in collaborating with developers.

As to your third paragraph above…it deserves a complete discussion and I think that would make a great topic for your next post here at Bridging the Gap! 🙂

Me? I prefer to work on what’s required of the solution to meet business needs/goals and allow the true tech team (those creating the code, et al) to design the final solution.

I have seen too many projects where the due dates are driven to by the business requirements providers because their view of what needs to be done is limited to what they think they will see on-screen AND the “BA” assigned acts more like an order taker than an elicitor of the business requirements. As with many others, I would really like to begin to see BA’s brought to the table earlier in projects to help uncover complexities and challenges that are typically considered scope creap later on only because none of the early planners didn’t think about it. What’s so wrong with bringing more information early on to get a better, more accurate scope of a project?

I’d like to push on this one piece of the dialog a bit further:

Steve: “having technical knowledge will help us communicate with those responsible for the technical development”

Alan: “Having a technical undertstanding allows the analyst to work with developers in a collaborative mode rather than a confrontational role to achieve the best business solution given the circumstance.”

While my first BA role was in an organization where I had deep technical knowledge of the systems, all of my other roles involved systems I had no way of learning the technology behind those systems except by talking to the developers. I would argue that my systems thinking, general knowledge of how IT systems work, and willingness to ask questions and brainstorm solutions made me more successful than my technical knowledge. In fact, when I do have specific technical expertise, I find myself more likely to be confrontational because I might know for a fact that something a developer is saying is wrong. Without that expertise, I might sense it but I’ll be able to ask questions instead of propose answers.

So, just to clarify, are we talking about general IT knowledge (like at the level of client-server interactions and system integration points) or are we talking about detailed technical expertise (at the level of how to write a specific line of code)?

Faras, I do believe I’ve been what you are considering a 360′ BA without the ability to write SQL or simple code. So often we see the BA role dependent on the strength of the other roles in the organization. In this case, it depends on the strength of the technical lead. With a strong technical lead in place, the burden to understand actual software architecture and coding possibilities is less important than to understand general technical concepts.