The difference between business architect and business analyst
[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