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!
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.
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?
A very good article indeed. It definitely puts to light the confusion that not only BA's like me sometimes get hung up on but most especially the companies that employ them. Just like a number of BA's I know, I started as an applications support analyst and progressed somewhat naturally into the role of a BA after a number of years. It was somehow a natural progression as I gained more experience on the systems I was responsible for and the business processes that those systems in turn support. In my experience, the emphasis was more on the technical knowledge and expertise and less on the BA skills, tools and processes, so in this case, I guess I was a specialist. As I got involved in process improvement projects with different systems being implemented, the focus changed from technical know-how to more of business process knowledge which I guess turned me into more of a generalist.
I think BA's should be more of a generalist as it will allow them to focus more on the business domain and not 'jump the gun' by already having pre-conceived ideas about the system or solution impeding the BA process to go through its steps. Of course, having the technical experience or background is an advantage as it enables the BA to communicate with the technical domain experts in the later stages of a project. However, I don't think that BA's should be expected to be systems experts themselves as well. Unfortunately (or fortunately), however, it seems as though this is becoming more prevalent. I had a look at a few job sites to check out available BA positions and I was a little surprised by some of them requiring more technical and systems expertise than I expected. I guess the current financial situation is to blame as companies consolidate roles especially in departments usually considered as cost centers like IT.
Great article!
On the job market, it seems demand leans towards Business Analysts with industry expertise/Subject matter experts.
However in my experience and having had a similar background to Jonathan at a large technology consultancy firm, it is my opinion that having technical know-how and Business Analsis skills make the best BA's.
What I mean by this is the BA needs to understand quikcly WHAT needs to be done – to have great soft skills to be a representative of users, to champion their needs while following a relevant process to deal with these needs AND understand the HOW this can come about with technology.
Let's face it, many almost all projects are technology projects, or have a large technology aspect to them. I have worked with BA's that came from the user community originally and although they are excellent, often there needs that extra level of understanding to gain credibility from IT also and when it comes to solution design.
So my blueprint for an ideal Business Analyst is a generalist, who has the technology understanding and knowledge of best practice, particularly at an enterprise level. Like those who have come from technology consultancies etc.
I, as one of these people, beleive that most business problems are identical: whatever systems are involved, whether it is integration or consolidation or whatever of systems it is almost always the same issues, of cost of hardware purchase and maintanance and data.
However as I said at the top of my comment, the market prefers BAs as SME's in that particular strain of that particular field, rather than any BA or technical ability or qualifications.
I have a feeling this is somewhat different in the United States and would like to hear about BA experiences there.
My recent post Business Analyst Book List
my comment
http://www.upmaan.com/2010/06/15/are-you-a-genera…
My recent post Are you a Generalist Business Analyst