Comparison of Business Analyst and Business Architect Roles Sparks Lively Debate
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.
Business Analyst and Business Architect
With nearly ten years in practice and soon to complete a PhD in business architecture I have had the pleasure of working with business analysts whose contribution has been priceless.
I am sure Malik never meant to cause any offence - the fact is none of us can legally call ourselves architects with the exception of the one and only Paul Bodine of Chicago who formally practiced as a real architect.
In short we have more than enough to keep up with demand and a great future for those that keep their eye on the ball.
Good luck and keep learning.
Re: Business Analyst and Business Architect
The problem with having fine lines between the roles and jobs is that in the real world, there is no fine line. The analysis bleeds into the architecture. The technology bleeds into the business. Most "BA" requirements end up being "technical" requirements as they are technology dependent. You have to have someone that can live in all the worlds. The, problem, as the posts state, is those are few and far between. The only realistic way is for there to be 2 (or more) people. From what I can tell from my ages old Systems and Analysis and Design Methods book is that ... that is the way to do it. Not sure where things fell of the rails.
BAnal v BArch debate
- "analysis" and "architecture" as concepts (in whatever role)
- business analyst v business architect roles (in whatever job)
- business analyst and business architect jobs in the ideal world envisaged by the author
- business analyst and business architect jobs in the real job market - in a particular geography.
Observation: my public enterprise and solution architecture courses attract a wide variety of people. Two kinds of delegate tend to struggle more than others.
1) Infrastructure people who have little insight into business processes and business data.
2) "Business analysts" formerly employed in IT roles who have retreated from addressing technical issues.
Shane Hastie on Distributed Agile Teams, Product Ownership and the Agile Manifesto Translation Program
Shane Hastie Apr 17, 2015