[Author’s note: within an hour of posting the following article, Kevin Brennen of the IIBA dry-roasted the post on his own blog. You can find a link to his entry here: Business Architecture is Business Analysis. I have made an attempt to fix a few of the most egregious errors in the post, and to follow up with an addendum (below).]
One distinction that I believe we should make, as the field of business architect takes hold, is the difference between a business architect and a business analyst. There are real opportunities for confusion here. In addition, there are some folks who believe that there is a good career growth path from business analyst to business architect. In this post, I will provide my opinions about the relationship.
Definitions
Business Architect – A role within various types of enterprises (business, government, non-profit) that is focused on collecting information on the strategic positioning of an area of activity (line of business, business unit, department, team, etc.) and creating a clear picture of the capability gaps that may impede that area from reaching it’s full and required potential.
Business Analyst – A role either within an information technology division of an enterprise, or within a non-IT team serving as a key point of contact with an IT division. This role is focused on understanding the root cause of a specific business problem in order to develop the IT requirements needed to address that problem.
(Inevitably, someone will ask me where I got those definitions. I made them up. I reserve the right to be wrong.)
Comparison
Both of these fields analyze the business… but that is where their similarities end. Let me repeat that: Business Architects analyze the business. Business analysts analyze the business.
| Business Architect | Business Analyst | |
| Why | 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. | To develop and document the detailed knowledge of a business problem that an initiative has been chartered to address. |
| How | Analysis of future-looking strategies, capturing of capabilities, and modeling of inter- and intra- business relationships needed to discover the key capability gaps that a business must be prepared to face, along with the development of cross-functional roadmaps to address them. System requirements are NOT captured. | Interviews with existing business stakeholders and SMEs to elicit business rules, understand processes, information, and systems in use, and detailing the consequences (intentional or not) of making a business change to address a specific issue. The primary result of this activity is the document of System Requirements. |
| When | Ongoing process that is triggered by periodic strategy cycles within a business | As-needed activity that is triggered AFTER a problem has been identified and requirements for a solution are needed. |
| Who | Business or IT Generalists with a strong understanding of business functional issues, interdependencies, and business structural concerns. Must be excellent at capability analysis. Must leverage modeling and rigorous analysis skills. | Business or IT Generalists with a strong understanding of information and application interdependencies, requirements analysis, and system development methodologies. Must be excellent at IT requirements elicitation. Must leverage modeling and rigorous analysis skills. |
| What | Business motivational models, Value Streams, Scenarios, Capability models, Heat Maps, Funding Maps, Risk maps | Business Requirements, Business Rules, Use Cases, and Detailed Business Process descriptions |
Perhaps this simple table will do a good job of explaining why these roles are different. 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. 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. (One of the software developers I hired at Acadio had a degree in archeology.)
In fact, I have never seen a business analyst successfully transition to the role of business architect. 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.
I am not going to make a lot of friends with this post. I respect that. Just sharing my opinion and my experience. Hopefully, I haven’t lost friends along the way.
[Follow-up note from Nick: I have met Kevin as well, and I respect the work that he has done, especially on the BABOK. His blog post responding to this one was not a big surprise in hindsight. However, I hadn’t expected such a complete rejection of the points. So I took a few minutes to review the BABOK v2 document. I hadn’t noticed this aspect of the guide before… guess I hadn’t been motivated enough to think about it: the BABOK defines the tasks of Business Analysis, not the role of Business Analyst.
To whit, the BABOK v2 specifically states:
“A business analyst is any person who performs business analysis activities, no matter what their job title or organizational role may be. Business analysis practitioners include not only people with the job title of business analyst, but may also include business systems analysts, systems analysts, requirements engineers, process analysts, product managers, product owners, enterprise analysts, business architects, management consultants, or any other person who performs the tasks described in the BABOK® Guide, including those who also perform related disciplines such as project management, software development, quality assurance, and interaction design.”
That is a very expansive definition.
Let’s put in a terms of a metaphor. What if the role of “physician” were defined in the same way. Would it look like this?
A physician is any person who performs the activities of diagnoses, treatment, surgery, prescription, pharmaceutical distribution, wellness evaluation, or their related activities. Physicians may include not only people with the job title of physician but also registered nurse, nursing assistant, pharmacist, pharmacy technician, physical therapist, physician’s assistant, psychiatrist, psychologist, chiropractor, personal trainer, and massage therapist or any other person who performs the tasks described in the Physician’s Desk Reference.
Do you see the problem? The BABOK itself points out one of the key reasons for defining the profession: to define “the skills and knowledge that people who work with and employ business analysts should expect a skilled practitioner to demonstrate.” 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?
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. According to this definition, I’ve been a business analyst for 20 years. In fact, I stopped playing the role of business analyst over a decade ago.
Here’s a simple test to see if you are a Business Analyst or something else: if your employer decides to completely erase his IT budget, and spend NOTHING NEW on IT systems, how busy would you be? If you answer “I’d go to part time” then you are sitting squarely on the line between business analyst and some other role. If you answered “I’m out of work,” then you are a full time business analyst.]
Thank you Nick, that is inspirational. I would rather have friends that stimulate thought, challenged assumptions and provide intellectual stimulation.
I have always wondered where the term Business Analyst came from considering so many of the roles that have been described in so many Enterprises actually required Systems Analysts, with a strong solution background rather than those who were in a position to understand the business from a wealth of subject matter expertise.
I will use this, with your permissions, in my discussions with young graduates who are looking for career paths in Business Analysis and Enterprise Architecture.
kind regards
Sian
You have my persmission, Sian. Please remember that my words are my own opinions, and not representative of any official position of my employer or my employer's partners.
Hi Nick
Nice summary and distinctions. I'd always thought an analyst takes things apart, whilst an architect works out how to put them back together again. 🙂
Will admit I'm not happy at your assigning business-analyst solely as a bridge between business and IT. As we've discussed perhaps all too often, there's a lot more to information-management than just IT, and a lot more to business than just its information. In my opinion, a business-analyst may need to be able to cover any part of that scope, otherwise there's a real danger of falling into the IT-centrism trap again. It may well be common that the _role_ of 'business analyst' is considered an 'IT role', but we've seen the damage caused by doing so with enterprise-architecture: we don't need to make the same mistake with business-analysis, surely?
Hi Tom,
Took a lot to respond. I posted a rather long blog post to address my thoughts.
blogs.msdn.com/…/analysis-synthesis-and-scope-business-architecture-vs-business-analysis-part-two.aspx
Hope that answers your question. Note that I'm still happy to update the description of the different roles in this particular post. If you want to offer specific changes, I'll consider. I admit to being too close to my own thinking to see the errors you are seeing.
— N
I wonder if gathering requirements, identifying process problems and improving on the process, finding a solution to a problem must always be IT related.
I have met quite a few situations where after talking with the stakeholders, business folks, my advice as a business analyst was (or would have been had circumstances allowed for that):
1) Do not replace your software, you don't need a software
2) Change some things completely unrelated to IT
Definitely most of the time I am working on software projects, however as I see it this is not a must .
When you do "business analysis" you are not necessarily tied to IT.
What is business analysis?
"Business analysis involves understanding how organizations function to accomplish
their purposes, and defining the capabilities an organization requires to provide products
and services to external stakeholders. It includes the definition of organizational
goals, how those goals connect to specific objectives, determining the courses of action
that an organization has to undertake to achieve those goals and objectives, and defining
how the various organizational units and stakeholders within and outside of that
organization interact."
It might be me, but if we accept that business analysis is the above, then I don't see why a business analyst would be out of job if the boss said: No IT from tomorrow.
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".
But business analysts are not tied to IT – I actually met one who does all the usual business analyst stuff then applies it to construction works.
Please, I certainly wouldn't call it 'errors' – it's just a different way you've sliced the view, so my view is just as likely to be 'wrong'. 🙂
Anyway, many thanks indeed, will reply on the other post.
Hi Roland,
Your definition of Business Analyst is very similar, if not identical, to the definition that many people would give for business architect.
Given that definition, I can easily see why you are percieving overlap.
I had an interesting bit of feedback on both posts from Kevin B at the IIBA. On twitter, he noted the following:
"my biggest problem is your insistence that BAs aren't responsible for solving the right problem. I'd call that malpractice."
I cannot count the number of times I've heard a presentation from a business analyst that provided details about a proposed initiative. In many many cases, the first thing I say, when the time is appropriate to speak, is: "Why is this work being done now?"
If I had a dollar for every blank stare I've gotten as a result of that question, and $5 for every angry response of "we did our scenario-focused requirements analysis, and we think …" blah-blah-blah
This is where an enterprise architect goes. We want to know that someone has asked, and answered, the questions "why this?" and "why now?" If those questions have been asked, and answered, just point me to the place where it is written down, and signed off by the executive whose strategy they are citing, and I will shut up.
In years of trying, I have seen this kind of supporting documentation perhaps twice.
Why? I've asked business analysts why they don't answer this question first. Their answer: My boss says that this is important, so this is what I'm working on. I'm here to make my boss successful and to deliver on the value my team provides. This is how my boss, and my team, defines value, so this is the initiative I'm proposing.
That logic is accurate. It is complelling. It reflects reality.
On the down-side, that kind of thinking produces —
— mis-aligned resources.
— high costs at the enterprise level
— sub-optimization (making one area more efficient at the expense of other areas)
— crowding out of changes needed for strategy
I'm not speaking with dysfunctional business analysts. I'm speaking with talented, intelligent, well-educated, often certified analysts with years (or decades) of experience.
It is not the role of the analyst to question whether the problem should be solved at all. That is the role of the business architect.
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.
In an organisation where EA, BA, PMO functions are still evolving, I found this a very useful post. I would be interested in how you feel the Business Analyst and Solutions Architect roles inter-relate?
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 en.wikipedia.org/…/Physician_in_the_United_States (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: http://www.iiba.org/…/CM.aspx).
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._
<overly strident statement>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?</overly strident statement>
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.)
Fascinating perspective. You have given me much to think about.
I have entered my reply to you Nick several times, but the engine never let it through.
I will try to send it today again.
Hi Roland,
Three options:
A) normally, long replies have a problem. If you hit the POST button, scroll to the bottom of the page and see if your text is still there. If it is, hit POST again. I'll get it. If I get the same text twice, I'll delete the duplicate, so no worries.
B) If you want, e-mail me your comment and I will post it without edits.
C) As I said, long replies are the problem. Some folks have replied on their blogs and then simply put a link to their blog in this comment box. That nearly always works as well.
Happy to add your contribution to the discussion. My apologies for the software. I didn't get a lot of choice.
— N
I know the evil's of blog engines, no need to apologize for it 🙂
Mailing it to you, because it is a bit longish, probably that's the problem.
I work with SharePoint, but come from a management consulting background. I consider myself a Business Architect because I start always start client engagements by analyzing gaps between strategy and execution. I then do a tool analysis and either pass the project to a colleague with a different technology focus or, if SharePoint is the best tool, pass the work to our solutions team. There is always a Business Analyst on the solution team. The analyst works within the confines of solving the specific, pre-defined, problem.