Business Analysts: SME’s or Generalists?
By JB on Jul 3, 2007 in Business Analysis | Print
Welcome! This site specializes in providing tips and tools for Business Analysts and systems development in general. If you're new here, you may want to subscribe to my RSS feed. If you'd prefer, you can also receive my posts directly to your e-mail. Thanks for visiting!
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!

6 Comment(s)
By B Kuhn
on Jul 3, 2007 | Reply
Great article - you articulated your points very well. I would agree that there is no single “right” answer, and that organizations use job titles differently.
In addition to your point on the dangers of having too much domain knowledge, there is a similar danger in having too much technical knowledge (desire to start defining how the solution will be designed/implemented).
My suggestion would be to become an expert in requirements first (facilitation, communication, ability to work with multiple requirements models, writing ability, etc…), and then learn enough to be able to communicate effectively with stakeholders, developers, testers, etc… Think about it this way - you probably have SMEs that can provide the domain knowledge you need, but your organization probably doesn’t have requirements experts - therefore you need to be one.
B
By Craig Brown
on Jul 6, 2007 | Reply
Jonathan,
Thanks for that.
I just re read over the BABOK and in the context of that doc I think your technical expertise assisst you in the assessment of solution proposals. It also helps you communicate what the solution design means for the lay people in the business. So yeah - it’s a useful skill to have, but not critical.
Cheers
By Yuan Y
on Jul 11, 2007 | Reply
Thanks Jonatha, this is just the kinda of discussion I would like to be involved.
I believe that technical expertises of a BA can benefit a agile project more than traditional waterfall project.
It allows BAs to do quicker turnarounds from both the developer and the business, ensuring expectations are clearly described to developers in their kind of language, and fairly good estimation of development efforts, etc can be feedback to the business in reasonable shorter amount of time.
Just my thoughts, I am only a graduate BA tho.
Cheers,
By Rajeev Singh
on Jul 30, 2007 | Reply
The most important thing to remember is to be able to keep a seperation between the “what” and the “how”. With a background of a developer it is very tempting to discuss the “how” or jump straight to it. Not having a development background provides that advantage, I agree.
Technical skills are important but only uptil the point where an Analyst knows the schema, if there’s one, understands the overall architecture of the solution, etc. The moment an analyst starts to guide the developers or even the business into details of algorithms, the downfall begins.
By Lisa Anderson
on May 21, 2008 | Reply
Well written points in your blog.
It is hard to find a blend of “enough” technical knowledge with just the right amount of analytical problem solving. I agree that more technical knowledge can lead one down the dangerous path of providing design rather than requirements. It can also lead a BA to making assumptions of the subject matter that could also backfire.
Take a look at a recent blog post on our site which discusses the fine line between SME and BA.
http://requirements.seilevel.com/blog/2008/03/ba-as-sme.html
By JB
on May 21, 2008 | Reply
Thanks for the comment and the link, Lisa. I find myself struggling at times even in my current projects to find the appropriate balance - to make sure that I’m eliciting and not authoring the requirements.
By the way, the Seilevel blog and message board are a few of my favorite reads.