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!
To keep up with the latest on Practical Analyst, you can subscribe to the RSS feed, follow Jonathan on Twitter, or view his profile on Linked In.
Latest posts by JB (see all)
- Jim Rohn – February 20, 2014
- Elicitation Tip: When the Stakeholder Asks for a Specific Implementation – February 19, 2014
- Paul Oldfield – February 11, 2014