Freigeben über

The difference between business architect and business analyst

  • Artikel

[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.]

Technorati Tags: business architecture,enterprise architecture,business analyst,information technology

Comments

  • Anonymous
    April 06, 2012
    The comment has been removed

  • Anonymous
    April 06, 2012
    The comment has been removed

  • Anonymous
    April 06, 2012
    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?

  • Anonymous
    April 08, 2012
    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

  • Anonymous
    April 08, 2012
    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.

  • Anonymous
    April 08, 2012
    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.

  • Anonymous
    April 09, 2012
    The comment has been removed

  • Anonymous
    April 09, 2012
    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?

  • Anonymous
    April 11, 2012
    The comment has been removed

  • Anonymous
    April 12, 2012
    Fascinating perspective.  You have given me much to think about.

  • Anonymous
    April 17, 2012
    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.

  • Anonymous
    April 18, 2012
    The comment has been removed

  • Anonymous
    April 18, 2012
    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.

  • Anonymous
    May 02, 2012
    The comment has been removed