Business Analysts: Domain Experts or Generalists?
JB | Jul 03, 2007 | 13 Comments | Print
Welcome to Practical Analyst, a site specializing in practical insight for business analysts and project professionals. If you're new here, you may want to subscribe to my RSS feed or follow me on Twitter. Thanks for stopping by!
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!
Related posts:
Filed Under: Business Analysis • Featured
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
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
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,
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.
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
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.
Hello Jonathan,
As you might expect, I favor Strong facilitation/knowledge transfer skills, in the area of Business and Functional Requirements. Doing Requirements Discovery sessions with a new client every couple of weeks, it is a given that I will not know the domain in detail when I start, but will know a lot when the session is done… then I will forget most of it when I go to the next client. Other than that, it is important to keep up a general knowledge about technology, it is good to be aware of where your requirements are heading.
It is certainly likely that a BA employee will pick up and retain domain knowledge over time, but domain shifts are still possible. I joined a finance/lending company as an employee some years ago with no prior domain experience. I worked a lot on projects to improve their loan origination process and systems, but would also fit in projects from Asset Recovery (um, repossessions) to HR Time and Attendance. Each time I started with no detail domain experience beyond what anyone else might know. So, it is all about the process you use to elicit, document, analyze and validate requirements.
This does presume that Requirements are the main aspect of a BA position. I know companies ask BA's to do more than that, but if you are not doing Requirements work at all, I would say you are not a BA.
Suggestion for next topic: BA job postings that ask for specific vendor/software experience. Is that really part of being a BA?
Interesting article (just found it through a tweet from Kavitha Poovaiah).
I found the reference to domain expert a little confusing. To my mind this should refer to the BUSINESS domain, not the technical domain. I think technical knowledge can be useful (I come from a development background) but I tend to put this to one side at all times to avoid confusing/impacting the solution exploration.
To me, the more useful differentiation is between an analyst who focuses on a particular business domain as opposed to one can apply themselves to any domain. As a freelancer, I would put myself in the latter category but I see there is greater value in becoming more specialised.
In this case you can sit on 'both sides of the fence' by understanding the business requirements but also pointing out pitfalls and opportunities through your domain knowledge.
This article descibes the various breeds of business analyst – http://businessanalystmentor.com/2009/03/17/trend...
Thanks for the comment, Alex.
Honestly, I am still fleshing out how "I" want to define the various "domains" of BA knowledge/skill – which may be non-standard anyway, so you're right I'm not sure that my usage of "domain expert" in this context is the best.
I think I'm pretty close to getting my stuff together, though, and if I can get some time this evening after the kids are down & before I crash, I'll try to post my thoughts.
Re: the differentiation "between between an analyst who focuses on a particular business domain as opposed to one can apply themselves to any domain" in career terms – I think that's part of where David wants to take the conversation. I'd certainly be interested in hearing everyone's thoughts on that as well.
Maybe a topic for a round of posts on our respective blogs?
Hi Jonathan, I tend to agree with your points here (and wish I had run across this post before I published my own on a similar topic)! I do wonder though if we should separate domain knowledge of specific systems from general technical knowledge. In my interview process as of late, I get a lot of questions about how I help stakeholders see the possibilities of technology. In order to do that, you have to have a sense of the possibilities in your environment, whether it's web or a client app or whatever.
Laura
I hear what you're saying on the domain shifts, David. I think there's a certain degree of technical know-how that you just pick up by working with systems in general over time, too. Regardless of the industry, you're well served by having a fundamental understanding of architecture, and the way systems work.
The analysis skills are the ones we can't do without, though.
I hear what you're saying on the domain shifts, David. I think there's a certain degree of technical know-how that you just pick up by working with systems in general over time, too. Regardless of the industry, you're well served by having a fundamental understanding of architecture, and the way systems work.
The analysis skills are the ones we can't do without, though.
I think that's a great suggestion for an upcoming topic, too. I think the vendor/software experience has a lot to do with multiple factors including – consultant vs. perm. BA for a company; consultant in a specific field or technology vs. general business analysis/project management consultancy, etc.
It is a conversation I think it'd be interesting to have. Just need to get my thoughts together on it, first.
I think of specific systems expertise and general "possibilities of technology"-type knowledge as different rungs on the same ladder.
And I absolutely think it is incumbent on the BA to be able to break down the possibilities of technology in terms that business folk can digest. And to be able to do that, obviously, we have to have some of that knowledge ourselves.