prev »

Posted by Kevin B. on Apr 6th, 2012 10:51pm

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.

Posted in General, BABOK Link to this Post

2 Comments Jump to Latest   Add Comment

This is a cross-posted response to Nick's blog at

Hi, Nick. I enjoyed reading your (edited) post - I was too late to see the original. Some food for thought, below. It's a bit longer than I intended, but then, you wrote a provocative piece - for which you have my thanks!

My comments fall in two categories: Comments on the article, and comments on comments - mostly in the order they were written. Nick, if you have a hankering to pretty up the formatting in the text below, feel free.


Physician and Business Analyst: Logical Fallacy of False Analogy.

From (2012-04-11 2115EDT)

"The American College of Physicians, uses the term physician to describe all medical practitioners holding a professional medical degree. The American Medical Association as well as the American Osteopathic Association both currently use the term physician to describe members."

If you had chosen 'Medical Professional', I'd agree with almost everything in your analogy. So far, the Tasks in the BABOK® Guide seem to be complete - we don't have a task like 'diagnose illness' that is forbidden to a chunk of the profession (in Canada and the US, at least, most nurses and most medical technicians (ultrasound, XRay, etc.) are explicitly and legally forbidden from performing diagnoses).

I'd be interested in your take on "Engineer" or "Scientist" as an analogy, and whether they break down under scrutiny; I suspect they are more appropriate for your discussion.


Scope of the Profession, Employers

"How can an employer expect a specific level of skill if it that bar is so low that a dozen different roles are expected to perform it well?"

Related to the analogy above, this is misleading. There are dozens of kinds of engineers. No employer is going post a job for an Engineer without describing the role and responsibilities in more detail - if by stating "Electrical Engineer" or "Nuclear Engineer" or "Civil Engineer".

As you noted, the BABOK® Guide describes Tasks, not roles - but IIBA has worked with the business analysis community to develop role descriptions. They are in the Business Analysis Competency Model Version 3.0 (free for IIBA Members, but I'll quote some bits below:

This standard puts Business Analysis roles and titles in many contexts, relates the underlying fundamentals - the Tasks - to the high level descriptions that many employers and HR people are looking for. The model is tightly aligned to the BABOK® Guide, but with a different perspective and purpose.

For reference, Business Architects are described on p. 13 as:
- Generalist Business Analysts (rather than a Specialist or Hybrid), with
- the Enterprise as their context (rather than a project/process/product, or department/business function).

Other roles in the same context include Business Relationship Manager, Strategic Business Analyst, Management Consultant, Strategic Planner, and BA Practice Leader.

On p. 18, Business Architects are profiled as Advanced Generalist Business Analysts, as follows:

Description: This individual works to build and facilitate a business architecture that leverages enterprise capabilities and efficient usage of process, technology, data and people to align these capabilities. The business architect defines current and future business models and influences the interconnections between the business processes, technology, data and people, and facilitates the execution of these components to drive business performance throughout the enterprise. He or she sees patterns in process, data and technology that are common across the enterprise and facilitates efficient execution of the business operation by leveraging these patterns.

Context to BA Generalist Profiles: This role requires an advanced level of analysis of the big picture while maintaining a level of detail appropriate to the context of a variety of situations. A person in this role needs to be able to identify critical driving forces of process, data, people and technology at the highest levels. This role also requires an ability to operate with comfort in ambiguity and to identify relationships and connections between disparate concepts, processes, drivers, details and data, as well as identifying simple patterns in the seemingly complex.

This seems to be quite consistent with the role you're describing.


Business Analysis and Technology Focus

Business Analysts often have an IT focus because information technologies represent a vast and powerful set of solutions to business problems. There are other ways to solve business problems; therefore there are business analysts that focus on other domains. From personal, anecdotal experience, I was thrilled to meet business analysts at Disney, who were focussed on solutions like traffic flow (humans in lines, not bits on a wire).

Your 'why' and your last paragraph ("Here’s a simple test to see if you are a Business Analyst…") both appear to ignore the reality, that technology - and particularly information technology - is a significant part of many business solutions. I'm fairly certain that few business architects would claim that technology has no place in solving business capability gaps or creating new business capabilities. BAs - architects and analysts - both care about the business capabilities, whatever they are, and about helping find ways to solve business problems.

Depending on the context of your role, a solution might look like a controlled organizational change (project, initiative, program, etc.) or an changed feature set in an existing product.

…Let's unpack that last statement.

A. An organization is a (large, complex) solution to a (large, complex) problem: collecting a coherent set of capabilities (or features) together to create a sustainable solution (the organization) to affect the context of the solution (the organization, and the world).

B. A product - like an smelting plant or a mainframe - is a (large, complex) solution to a (large, complex) problem: collecting a coherent set of capabilities (or features) together to create a sustainable solution (the product) to affect the context of the solution (the organization, and the world).

C. A project is a controlled way to alter the capabilities of an organization (even when those capabilities are represented by the features of a product).

D. Strategy is a controlled way to alter the capabilities of an organization (even when those capabilities represented by the features of a product).

Business analysis can be applied to any aspect of controlled organizational change. The tasks really are that general. There are an infinite array of techniques for performing these Tasks; the most appropriate Technique depends on your context.


Comment from Tom Graves: "I'd always thought an analyst takes things apart, whilst an architect works out how to put them back together again."

You're right: useful business analysis demands analysis and synthesis. Depending on the role, one may be more heavily relied on than the other.

If I had a time machine and enormous influence over the profession, I'd go back to the late 1990s to try to preemptively change the name of the profession - but 'Organizational Analyst and Synthesist' just doesn't roll off the tongue. :)

Response from Nick: Now I need to grok TWO MORE great posts! This learning thing just never stops, does it?


Comment from Roland Hesz: 'I don't want to say that a good Business Analyst will become a good Business Architect with no problem. Especially if said Business Analyst concentrated on the "write programme specifications".'

As with any profession, there are a lot of roles to fill in a variety of contexts. My mother taught high school history, then taught special education (high school, then elementary), then taught teachers to teach special education. She was still a teacher - but not all teachers could do what she did, or would want to. Similarly, a project BA may not have the inclination or ability to take on problems with an enterprise scope - and the reverse is also true. I'm an Enterprise Business Analyst, but that doesn't mean I should (or even can) do a great job with detailed analysis of data requirements.


Reply from Nick: "So, Roland, if a person follows your definition, and if they are able, and willing, to face a business leader and say "our objective should be to eliminate your department," then they are a business architect. Anything less is less. I've NEVER met an actual, functioning, business analyst who can do that."

Your argument rings false because the kind of BA you're talking about - the ones who work in projects - have rare access to business leaders, and when they do _those leaders often run the department the BA works in._

If recommending the elimination of your own job is a key characteristic in business architects - well, you're a rare and selfless breed, above the petty wants and needs of mere mortals. Poll your peers. How many of them have fired themselves?

Perhaps a fairer scenario for a business architect would be a merger where both companies have an enterprise architecture capability - and the other company's department is better. It takes a lot of courage to stand up and say, "and when this is over, fire me."

One question I ask at business analysis conferences is, "Who here has successfully cancelled a project?" Roughly 5-10% raise hands, and they tell the same story - the one you sited in your downsides.


(Note: The BABOK® Guide version 2 isn't perfect, and doesn't describe business analysis perfectly. For example, it does have a bias toward the project context, and strongly iterative methodologies (like Agile) are harder to see in the text than we would like. I'm a member of the core team working on version 3 - which is still well over a year away from publication - and that's one of the things we plan to address. On the other hand, despite our extensive efforts to tear the thing completely apart - including attempting a complete redesign from the ground up! - we have _not_ discovered anything that is fundamentally incorrect. Sure, there's many ways to improve the tome, but the foundations are quite solid.)

Kevin, a lawyer has all the capabilities of a business analyst (do you agree?), but there is no question that they are distinct professions. The distinction is based on their differing objectives.

Regarding the distinction between business analysis and business architecture, you said, "I just can’t see that as a sufficiently profound difference to call them distinct fields of study." That speaks volumes.

Having said that, I'm in the camp that a BA has the capability to migrate to an architectural role, particularly as an enterprise architect. But in my opinion, the typical BA (even a senior) would need to add MBA type credentials to their resume.

By the way, a BA would also make a fine lawyer, after receipt of a Law degree.

You justifiably accused Nick of "downplaying the actual complexity of the IT BA role while playing up the complexity and importance of business architecture." Perhaps you are guilty of the reverse :).

If you would like to add a comment, please Sign-In.
version 2.33.8 ::
Desktop View