Asking what a business analyst does seems like a pretty straightforward question, but it rarely yields a straightforward answer. Unlike many other IT jobs, companies often don't have clearly defined requirements for their BAs.
When hiring programmers, companies list the languages and technologies programmers will be expected to know and even specify the certifications they want them to have. But what kind of qualifications are companies looking for in their business analysts?
Steve Kubick, a business analyst for AutoZone for the past two years, says that in the course of networking with other BAs, he's "never found another person that can give me a definition of what they do as a BA that matches mine."
While Kubick works with different divisions of AutoZone, many of the BAs he's met who work for other companies dedicate their efforts to a single department or single system. Some concentrate on examining systems and suggesting technical tweaks to improve performance, while others rarely consider specific technologies.
This "identity crisis" is common among BAs, conclude Forrester Research analysts Carey Schwaber and Rob Karel, who found it difficult to define the duties of a "typical" BA even after reviewing 29,000 job listings and interviewing more than 300 BAs. They identified two major categories of BAs, business-oriented analysts and IT-oriented analysts, and six archetypes within those categories.
Forrester analyst Mary Gerush, who authored a newly published report that builds on ideas discussed by her two colleagues in their report, says that business-oriented BAs tend to possess more knowledge of business processes and policies and interact more with business executives and stakeholders than their IT-oriented peers. IT-oriented analysts possess a deeper knowledge of technology, and some even do hands-on tech work such as design or development.
Schwaber and Karel contend that the business analyst role will morph into what they call a business technology analyst, someone who feels comfortable implementing suggested changes to business policies directly within supporting software. While that move may eventually come, Gerush thinks companies are more interested in leveraging the existing skills of their BAs than in requiring new skills of them. Better defining the BA role is a logical first step in achieving this aim, she says.
"The landscape is very complex. There are so many different titles and permutations: functional vs. non-functional, hands-on vs. process," says Gerush. "People are really trying to understand the role and all of its variations so they can position their analysts in the best way to achieve their outcomes. They are starting to invest time and energy in gaining some structure and some focus around this role."
As roles like developer, system architect and project manager became better defined over the years, says Kathy Klotz, a business analyst for Konverge, BAs inherited some of their residual tasks. "That can be overwhelming, so what happens is people play to their skills," she says, resulting in the wide variance of duties seen among BAs.
Jay Michael, a business analyst for Colfax, agrees that the BA role is fuzzy at many companies. "Unless they've worked with me directly on a project, people within the company don't know what I do," he says. "I usually describe what a BA does by telling people I am a bridge between business systems from the end user to functional implementation of technical solutions. But when you tell somebody that, they look at you like OK, what do you really do?'"
Though Michael studied electrical engineering as an undergraduate, he switched to business and went on to earn an MBA degree. He then went into a management training program at a manufacturing facility where he ended up working closely with IT because of his own interest in technology. He called it a "forerunner" of becoming a BA because he would talk to managers about what they wanted from IT and then convey their needs to the IT department.
He also worked as a consultant for Arthur Andersen before joining Colfax, where he says the role "has evolved" to fit him. "The company was implementing an ERP system and needed help with it. At first, I was like a systems administrator, but my role has become broader and more business oriented."
Like Michael, Kubick's academic and work experience equipped him with an unusual collection of skills. A developer for a half-dozen years, he began documenting requirements because, unlike many of his IT peers, he is "very much a writer." In fact, he has a master's degree in English. As part of an 18-month project to revamp some software, he worked with members of both the business and IT teams and began "wearing the hat of a BA" before he officially became one.