The traditional business analyst role needs to change if service-oriented architecture (SOA) is to successfully advance in organizations, according to two analyst reports released this week. At the same time, despite different backgrounds and responsibilities, analysts and enterprise architects must work together more closely.
Business analysts need to serve as the communications conduit between IT and the business side in SOA, said Theresa Lanowitz, an analyst with Voke Media Inc. Lanowitz released a report today on "The Role of the Business Analyst." The potential rivalry and possible cooperation between business analysts and enterprise architects in SOA is the focus of Ron Schmelzer, senior analyst with ZapThink LLC. in a ZapTake released Wednesday.
While their overall focus differs somewhat, both analysts clearly see the evolution of the business analyst as crucial to SOA success.
The changing role of the business analyst begins with a recognition within the organization that SOA is not business as usual, said Lanowitz, who focused on the business analyst role in application development in her report.
"In a SOA environment there has to be awareness that this is not business as usual," she said in an interview with SearchSOA. "This is going to drive our business. This is going to drive our competitive differentiation. So we've got to make sure that we're doing everything in our power to get it right. That this is not a one-off thing."
Bridging the communications gap between the business side and IT throughout the application development lifecycle is one of the key roles the business analyst can play in SOA, Lanowitz said.
This helps span the gulf between business people doing process analysis on the one hand and IT developing SOA separately, which was the subject of a report earlier this month by Neil Ward-Dutton, research director, Macehiter Ward-Dutton.
The business analyst should become active in the back-and-forth discussions of SOA requirements between the business and IT, Lanowitz said.
"One of the big things that's emerging with the business analyst role is that they are becoming the conduit of communications between the line of business and the IT organization," she said. "They are the point person sitting in the middle. They are also the keeper of the true vision of what is going to come to fruition for the line of business. They'll go back and forth and act as that conduit of communication."
In her survey, she found that successful organizations are building business analyst groups representing a wide spectrum of the departments within the business so that a variety of points of view are taking into consideration in planning SOA implementations.
"One of the things we found was that to build a really effective business analyst group, you should really hire your business analysts from a variety of places in the organization," Lanowitz said. "Some coming from development. Some coming from QA. Some coming from operations. Some coming from the line of business. Some coming from the field where a lot of these software applications are actually used."
The way to align business and IT, which is the stated goal of SOA, is to make sure all points of view are heard, beginning with the requirements gathering stage of the SOA lifecycle.
"What we found is that if you have this well-rounded business analyst group, they will understand how the company works from a variety of perspectives," Lanowitz said. "So you get a lot more cross-functional communications."
The business analyst who comes from the field organization knows how to communicate with people in the field, she said in offering an example of how this works.
"They understand the pressures that they are under, the sort of deadlines they have to meet," Lanowitz said. "We found that organizations that had business analysts from a variety of places had more optimized communications back to those previous lines of work where the business analyst once resided.
Business analyst vs. enterprise architect
The clash and possible reconciliation of traditional roles is the focus of Schmelzer's ZapTake titled "The Business Analyst vs. the Enterprise Architect." Despite the title, he concludes that they could all get along.
Both the business analyst and the enterprise architect play roles in developing requirements and then the architect "shepherds business requirements into services and then manages the realization of those services through the IT development organization," Schmelzer writes.
This can lead to confusion as to whether the business analyst role is being eclipsed or is competing or even impeding the enterprise architect in SOA, the ZapThink analyst said. But he quickly adds that this is not necessarily the case.
"Even if we focus on the role of an IT business analyst, it is clear that the scope of the work and nature of their skills differ in significant ways," Schmelzer writes.
The enterprise architect role is "to translate business requirements into capabilities that can be cost-effectively implemented, predictably managed, and reliably controlled," Schmelzer said. The business analyst focuses-in on requirements generation and the communications conduit role, which Lanowitz highlights.
Enterprises should consider structuring the business analyst and enterprise architect roles holistically, in Schmelzer's view.
Bringing business analysts and enterprise architects into a closer working relationship would take advantage of their different skill sets, he argues, pointing out that business analysts "often lack the technical skills to do the modeling part that is so necessary to making good architecture work." So the architect would have a primary role in modeling, for example.
Also the focus of the two roles is different. Business analysts tend to focus on "discrete business needs to be addressed in short timeframes," Schmelzer writes. But to achieve the SOA "goals of reuse, reduction of redundancy, and business agility," the enterprise architect needs to look strategically at the big picture.