There, I said it.
This isn’t a new position for IIBA, of course, but it’s one I think is worth stating outright these days. In particular, I was prompted to put down some thoughts about this and explain why we take that position by this post from Nick Malik.
I’ve met Nick, and I respect much of the work he’s done, but I believe his comparison of business analysis and business architecture is seriously flawed. The assertion that “the distance from a business analyst to a business architect is as great, or greater, than the distance from an engineer to an accountant” is profoundly wrong. I was a little annoyed at first, but the source of the problem became clear to me as I thought about it.
Towards the end of his post, Nick says “In fact, I have never seen a business analyst successfully transition to the role of business architect.” What’s very clear from Nick’s post is that he has never been a business analyst himself (or at least never seen himself as one). 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. Everybody’s job looks easy when you’re not doing it.
Nick’s list of things a business architect does all, in fact, trivially map back on to the fundamental business analysis tasks identified in the BABOK® Guide. Those tasks aren’t pulled out of thin air, or aspirational. They’re based on extensive research into what business analysts do, feedback from hundreds of actual practitioners doing those things, and they serve as the basis for a certification program that thousands of BAs have passed through. If I were to take Nick’s list at face value, and agree with him that these are distinct professions, it would mean that IIBA has been certifying business architects instead of business analysts. I’d hope we’d have noticed. ;-)
For the moment, I’ll leave aside Nick’s assumption that a business analyst is an IT role. Only about 50% of business analysts work in IT, based on the data we have, and many work on purely business problems. However, since this post is already going to be way too long, I’ll set that aside for now.
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. A VP may have a different set of responsibilities from a team leader, and may need some distinct skills and knowledge, but they’re both managers. The same is true here. Going through his list of what a business architect does:
“To uncover the gaps between strategic needs of a business unit, and their abilities to meet those needs, and to charter initiatives to fill those gaps.”
The BABOK® Guide has an entire knowledge area dedicated to these activities (Enterprise Analysis). Nick is right that business analysts are often brought into a change initiative after it has been started, but as BAs know, that practice is often a key point of failure for those projects. In my experience there is frequently a significant mismatch between the strategic needs of the business unit and the scope of the project chartered to meet those needs, and as a business analyst I frequently spent a lot of time working to bring the scope in line with those real needs. Sometimes that meant going back and proposing an entirely different project.
But that’s the traditional project, an environment that is becoming less common for business analysts as time goes on. Many business analysts in IT work in agile environments where they act as a product owner, setting the direction for a product assessing what it does against the strategic needs of the organization, and figuring out what features need to be added or changes need to be made. Even in the traditional environment, a business analyst will frequently define the roadmap for how a product needs to be enhanced to meet the needs of a business unit over multiple iterations.
On the surface, the Architect and Analyst roles sound very different in the list Nick gives, but they’re not really comparing similar things. The Analyst section is all about how the Analyst gathers information, and the Architect section doesn’t touch on that question at all. Im practice, you capture capabilities and model business relationships, by, yes, eliciting information from stakeholders. And I’m far from clear on the difference between “discovering the key challenges a business must be prepared to face” and “detailing the consequences of making a business change”.
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.
I think this is wrong on both sides of the comparison. Strategy may be performed as a periodic process triggered by specific cycles, sure. It may also be triggered as a response to an external event. Or performed in response to the identification of a problem that needs to be solved.
On the other hand, business systems analysis can be performed following the initiation of a project, or as an ongoing process enhancing a specific system or set of organizational capabilities. I know lots of BAs who’ve been working on iterations and improvements of the same system for a decade, and not in response to a specific problem but as ongoing improvements.
Actually, most business analysts I’ve met have started in the business and moved to IT–they got into the profession because of their business knowledge and their role on the team is specifically to provide that information. Also, I can’t fathom why Nick left modelling skills off the BA list. I would never hire a business analyst without strong modelling skills.
I’ll grant this list, but I don’t think it changes my point. I have learned and used dozens of analysis and modelling techniques in the course of my career. What I did depended on the problem I’m trying to solve. I’ve never encountered a good business analyst at any level who couldn’t come up to speed on a new technique pretty quickly, as they all leverage the same core skill set.
On a personal level, I have been a management consultant, IT business analyst, project manager, IT manager, and association executive. Learning to manage teams and organizations was and is a much greater challenge to me that learning business architecture. Business architecture leverages skills I already developed as an IT BA and consultant.
Unlike Nick, I’ve met a lot of people who’ve been both a IT business analyst and a business architect. I have yet to meet anyone who has done both jobs who believed that they were different professions. I’m sure they’re out there, of course, as I know my experience isn’t universal.
Not every IT business analyst can or should aim to be a business architect. There are skills to learn and it does demand a somewhat different mindset–and there’s over a million jobs out there for IT BAs and maybe a few thousand for business architects. But we have a lot more room to get better at what we do in any role if we acknowledge the overwhelming similarity in what we do and the skills needed to do it effectively, and take the resulting opportunities to learn from one another.