Nick Malik, an Enterprise Architect at Microsoft, wrote a blog post differentiating business analysts from business architects and he received a swift rebuke of his stance. Malik contended that business analysts do fundamentally different work than business architects but Kevin Brennen of the International Institute of Business Analysts (IIBA) strongly disagreed and pointed out the resemblances between the roles.
In Malik’s original blog post, he claimed that while both roles analyze the business, that is the only similarity between them. He proceeded to outline the purpose, technique, timing and characteristics of each role. According to Malik, business architects use advanced models and tools in an ongoing effort to identify gaps in business capabilities and they initiate efforts to fill those gaps. In contrast, business analysts work on existing initiatives and leverage stakeholder interviews to develop the system requirements that will be applied towards an IT solution. With this assessment in place, Malik punctuates his point by drawing a clear line between the roles.
There is nearly nothing about these roles that are actually the same. These are fundamentally different roles. Yes, there are people who can play both roles.
…
In fact, I have never seen a business analyst successfully transition to the role of business architect.
This position was quickly challenged by Brennen of the IIBA in a post entitled "Business Architecture is Business Analysis.” Brennen took little offense at the definition of the business architect but had fundamental problem’s with Malik’s assertions about the business analyst role.
It’s not that he’s wrong about what a business architect does. It’s that he’s comparing his actual experience as a business architect to what he thinks business analysts spend their time doing. Nick's also, consciously or not, downplaying the actual complexity of the IT BA role while playing up the complexity and importance of business architecture.
…
Before we get into this, I’m not asserting that every business analyst can or should be involved in business architecture. It’s one kind of business analysis, but there are lots of other career options for BAs. I’m just vehemently disagreeing with his claim that they are distinct professions.
Brennen then addressed each of Malik’s role comparisons and highlighted where he found the argument deficient. While Brennen accepted that business architects and business analysts may work at different levels of the organization, he didn’t consider this fact to be something that changed the essential aspects of the work involved.
There is one real difference I see here: a business architect works in the realm of strategy, and business systems analysts are engaged with tactics. I just can’t see that as a sufficiently profound difference to call them distinct fields of study.
Malik responded to Brennen’s arguments by updating his original post with further clarification. Among the updates, Malik amended his definition of business analysts to include their assignment to non-IT teams. He also reiterated that both roles have a primary focus on analyzing the business itself. In addition, Malik softened the language around the inequality of skills between the roles.
If you look at the people and their skills, there is some overlap. Certainly, smart people with excellent analysis skills can do many things. But we are not talking about the people. We are talking about the actual role.
…
Note that this is my personal experience, and I am willing to consider that there are many folks who have made that transition. I have watched many struggle, and fail, on that road. Given what I’ve seen, I consider this a very difficult transition.
A new concluding point was added to the post. Malik looked at how the Business Analysis Body of Knowledge (BABOK) described the tasks of a business analyst. He lamented the fact that the broad set of tasks assigned by the BABOK do not help differentiate the analyst role.
This is a problem with the BABOK, not the analysts themselves. Including such a wide array of roles in the “definition” of a business analyst creates a situation where no other profession can define a role that cares about similar concerns without overlapping with this definition.
In a follow up post, Malik continued to draw distinctions between these two roles.
The business analyst role is much more tactical than the business architecture role. Traditionally, the business analyst is required to understand the problems of a business area and to document the requirements of the business in solving them. The business analyst is NOT accountable for developing the solution, or even the vision for the solution (The solution architect does that). He or she is accountable for understanding the problem and documenting the requirements that the solution must meet.
The business architect role is a more recent innovation. This role emerged out of the need to insure that departments and divisions are using IT resources correctly by asking for the right problems to be solved. From there, the role has expanded to a non-IT-focused value proposition. The business architecture role is important. Without the business architect involved, we may do an excellent job of solving problems that the overall enterprise does not need solved, when the real enterprise-level problems are going unaddressed or under-resourced due to the long list of demands from the existing businesses.
Malik decided that while these two roles could conceivably be performed by a single person, the preference would be to have distinct, but complimentary jobs defined. He highlighted the need for clear accountabilities between the roles and encouraged the continued growth and clarification of the business architect discipline.