1145534_3d_maze_4

I’ve been involved in some interesting and spirited discussions over the years as to whether a Business Analyst (BA) is most effective when also a subject matter expert (SME) in the technology and systems in use, or whether the BA need only be disciplined in the general principles of business analysis; chiefly, how to identify customer need, and be an effective facilitator of knowledge transfer.

Personally, I don’t think there is a single “right” answer, and I’ve argued from either side at one time or another. What I hope to do here is to list some points/counterpoints that may help you think through your position, or even evaluate how your technical/systems knowledge helps or hinders your performance as a BA.

To get started, allow me first to provide just a little bit of context on my professional background. With a previous employer, I worked in the same area for a number of years and got a shot at just about every role in our IT shop before being asked to serve in an application architect/business analyst hybrid role. It was a great opportunity for growth and really got me excited about being a BA, but at the same time I think it gave me a distorted view of the classical business analyst role. There weren’t many in the company that knew more than I about the applications I was working with, so it wasn’t rare for me to write what I thought the requirements should be and just get them ok’d by the stakeholders.

Since then, I’ve found myself in a role where I’ve developed a good grasp of the business environment, but don’t have nearly the same systems expertise. This has forced me to rely on and hone my business analysis skills – communication, elicitation, facilitation, etc. Instead of a disadvantage, I think it has actually helped me produce deliverables that are more representative of business need.

Here are some advantages I found to having deep technical/systems domain expertise for a Business Analyst:

  • Adds to a BA’s confidence and credibility with stakeholders and IT folks.
  • Allows a BA to diversify his/her role and add value in different ways.
  • May be helfpul in a smaller IT environment where a BA may be called on to wear more than one hat.
  • Deep domain expertise allows a BA to potentially weed out impractical solutions earlier in the project lifecycle and make more solid solution recommendations to the business.

Looking back, I think I was able to provide value in more different areas when I worked in the hybrid arch/BA role, but I don’t think I was nearly as good a Business Analyst as I am now. I think this is why:

Deep domain expertise can prove an irresistable temptation for a BA to overstep the bounds of his/her role. This is a biggie. It seems as if everyone with a bit of domain knowledge wants to play solutions architect. A BA who is also a domain SME will inevitably be tempted to write requirements with bias toward a certain solution, allowing requirements to describe as much “how” a solution should look, as “what” the solution needs to provide. Most organizations will do better if the BA will just do as good a job as possible of being a BA and leaving design and architecture to the architects.

One thing I wanted to be careful of when writing this, though, is not to sound as though BA’s should not to try to learn about the technical environment. I think it is always a good thing to learn and know more about the technology and systems we work with. I think my main points are that, a) technical knowledge is great, if you don’t attempt to reach beyond the scope of your role to use it, and b) a Business Analyst can be successful without deep technology domain expertise.

Finally, here is what I think a BA should strive for in terms of a mix. I hope this will be especially helpful for new or aspiring BA’s.

  • Deep knowledge of business landscape. This is more important for a BA than the tech side. Some business solutions will have a very small or even no IT requirements.
  • Growing knowledge of technology landscape. Seek to learn, and to retain information about the technology and systems in use.
  • Strong facilitation/knowledge transfer skills. These are the distinguishing attributes of a successful BA.
  • Self-enforcement of role boundaries. As you become more familiar with the technology, fight the urge! Don’t try to be a designer, tech arch, developer, and business analyst. Just be a business analyst.

So, what are your thoughts? Which skills are most important for a BA? Is technical knowledge dispensable? What is the appropriate business/technical knowledge mix, if there is one, for a Business Analyst? As always, I’ll look forward to your feedback!