In my first ever article on this site, I wrote the following:
Hi there. My name is Tony. I live in Leeds, England and I’m an Agile Business Analyst.
That was two and a half years ago, and things have changed since then. Over that time, I’ve slowly come to realise that I’m not a Business Analyst. I’m a Business Analyst Designer. It’s a job title I’ve invented because I couldn’t find any existing job title that quite fits the bill. In this article I’m going to explain what it means.
What is a Business Analyst?
One of the problems that our industry faces is that the job title of Business Analyst means different things to different people, and the role varies from company to company.
There are, however, at least two industry bodies that have published a definition of the role – namely IIBA and BCS.
IIBA’s BABOK Guide is in its third edition (version 2.0, published in 2009), and version 3 is in progress. It contains a description of the tasks, techniques and competencies that business analysts must perform or possess. In summary, the BABOK Guide says:
Business analysis is the set of tasks and techniques used to work as a liaison among stakeholders in order to understand the structure, policies, and operations of an organization, and to recommend solutions that enable the organization to achieve its goals.
Two key concepts within the BABOK Guide are solutions and requirements. A solution is defined as:
A set of changes to the current state of the organization that are made in order to enable that organization to meet a business need, solve a problem, or take advantage of an opportunity.
And a requirement (slightly adapted) is:
A condition or capability [of a solution] needed by a stakeholder to solve a problem or achieve an objective.
In examining the tasks described within the BABOK Guide, it is clear that a business analyst’s life revolves primarily around requirements. Business analysts elicit, analyse, prioritize and document requirements.
With regards to solutions, business analysts assess (proposed) solutions, recommend solutions and validate solutions. What they do not do is design solutions. From my reading, solution design is done by someone else.
The alternative definition of the business analyst role is BCS’s Business Analysis, currently in its second edition (published 2010). It too defines a set of competencies and tasks. Its definition of the business analyst role is:
An internal consultancy role that has the responsibility for investigating business situations, identifying and evaluating options for improving business systems, defining requirements and ensuring the effective use of information systems in meeting the needs of the business.
Again, the role revolves primarily around requirements – eliciting, analyzing, documenting, validating. And again there is a distinction between requirements and solutions.
Business Analysts are Not Designers
If I take the above definitions to their word, then it seems to me that business analysts do not do any design work. They define. They identify. They elicit. They analyze. They decide. But as for the creative process of designing business processes and IT systems, that is apparently down to someone else. It’s either done by the stakeholders, with the BA helping them along (eliciting/analyzing/prioritizing/documenting), or else it’s done by the “solutions team”, with the BA validating/recommending.
Actually, I’m being a little unfair here. Both books do make reference to design activities, but only if you’re reading carefully and actively looking out for them. The BABOK Guide refers to creative thinking, decision making, problem solving and systems thinking as being underlying competencies of a business analyst. It refers to process modelling, scenarios and use cases and data modelling as important techniques in the BA’s arsenal, all of which (to my mind) are elements of design. BCS’s book has similar references.
The BABOK Guide also devotes a chapter to Enterprise Analysis. This describes the work that is done at the start of a project to understand the business objectives (“business need”) and to determine a business change (“solution”) that best achieves the objective. To my mind this is all about design. It talks about understanding desired outcomes, identifying gaps, generating options and selecting a preferred solution. But it does seem to imply that such design work is only done by the BA at the start of a project, and also possibly only by an enterprise business analyst with special enterprise skills.
I am a Designer
I see myself first and foremost as a designer. I engage with stakeholders and listen to their objectives. I make sure I understand the business domain, and the as-is business processes and IT systems. I listen to their proposals and ideas for how to achieve their objectives. Then, I work collaboratively with them to design a business change that meets their objectives. The business change sometimes includes IT system change. It always includes business process change. Usually, I design multiple options – some cheap and simple, some expensive and sophisticated.
The design work starts at a high level (much like enterprise business analysis). But it continues throughout the process. I apply creative thinking to every detail of every feature – constantly generating alternatives and (collaboratively) selecting the one that works best.
The tasks I perform are very similar to those described in the above books. I just do them with a slight twist. I don’t attempt to “elicit requirements”. I recognise that stakeholders might not know what they want, and that it’s my job to come up with designs to meet their objectives. I recognise that stakeholders sometimes think they know what they want, but that it’s my job to work out alternative designs that might better meet their underlying objectives.
Just to save confusion here – when I talk about design, I’m talking about business process design and IT system functional design – the user-visible behaviour of an IT system (for more details read this article). I am not talking about doing IT technical design – I’m not too interested in what programming languages or server hardware are used to deliver the system.
Most importantly, I hold myself accountable for my designs. They are my designs. If they don’t meet the stated objectives, that’s my fault. I don’t blame the stakeholder for giving me bad requirements.
Actually that’s not quite true. I’ve discovered that the best model for success is joint ownership of the design – between me and the stakeholders. We agree together that the design meets the objectives, and we take the flak together if it doesn’t. There’s no them and us.
I’m Also a Business Analyst
Being able to design business processes and IT systems is an important part of my role, but it’s not enough. I’m not the sort of designer who relies on someone else to go and “elicit the requirements” from the stakeholders. I engage directly with the stakeholders myself. It’s the only way I can understand their objectives and design them a business change that satisfies those objectives.
So, I need business knowledge. I need to be able to communicate effectively with business stakeholders. I need to act ethically and foster trust. I need to manage scope. I need to prioritize. I need to manage change.
In short, I need the competencies of a business analyst, and I also need to execute many of the tasks of a business analyst. Some of them I execute with a “design” twist.
I am both a business analyst and a designer. I am a Business Analyst Designer.
A New Job Title
Surely there’s no need for yet another job title in the IT industry. There are enough job titles and enough confusion out there already, something that two separate industry bodies (IIBA and BCS) are working hard to resolve. Why make it worse?
Here’s my problem. Currently, the industry seems to recognise two separate roles – that of the business analyst, and that of the (IT) solution architect/designer. The definitions of the business analyst role provided by the IIBA and the BCS seem to support this separation. But the way I work cuts across both roles – I am both a business analyst and a designer.
I would love to refer to myself as a business analyst. But the way I work is (I think) sufficiently different from the way in which the IIBA and BCS describe the role that it just doesn’t fit for me.
And the solution architect/designer job title doesn’t fit either. Typically, the solution architect/designer expects to receive some “requirements” against which to design. But that doesn’t work for me because in my view there’s no such thing as a requirement. I engage directly with business stakeholders to understand their objectives, their desired outcomes.
So, I chose the job title Business Analyst Designer to convey the sense that I am both a business analyst and a designer.
There are other job titles that fit the role I do. David Morris tells me he uses the term Business Design Analyst, and also considered Business Designer. Brian Shea prefers Architect to Designer. A colleague of mine refers to himself as a Business Architect, but only in the UK – apparently Europeans don’t recognise it. The title does matter, and is clearly a subject for debate. But it’s the role that’s really important.
A Real World Example
The business analyst/solution designer conundrum was summed up for me in a job interview a couple of years back. The hiring manager had placed two separate job adverts – one for a BA and one for a Solution Architect. I asked him what he was really after. He replied something like “well, I don’t want just a business analyst – I want someone who is going to design solutions for me. But I don’t want just an architect, I want someone who understands business and can engage with the stakeholders.”
He ended up hiring me for the role. Hopefully he got what he wanted – a Business Analyst Designer.
Parallels with Building Design
In a previous article I compared software design with building design. I observed that a building architect works much in the same way as I do – engaging directly with stakeholders to understand objectives, but also being responsible for the design of the building to satisfy those objectives. Not designed to the finest level of detail, but in enough detail that the stakeholder knows what they are going to get.
In the building industry there is no concept of a building analyst who “elicits the requirements” and a separate building designer who receives the “requirements” and designs a “solution”. It’s a single role.
An Opinion
In this article I have talked about the way I work. I am not saying everyone should work this way. I am not saying this is necessarily the best way to work. I’ve just noticed that it works well for me, and on the particular projects I’ve worked on. It’s my opinion, nothing more.
In particular, I am in no way wanting to discredit or diminish all the good work done by the IIBA and BCS in advancing the industry by working to define the business analyst role. I don’t agree with everything in their definitions, but I still find them of immense value.
I am particularly looking forward to the publication of version 3 of the BABOK Guide – the IIBA has apparently spent quite some time debating the relationship between requirements and design, and I have had some interesting and enlightening conversations with Julian Sammy at the IIBA on this topic.
Are You a Business Analyst Designer?
I think there are other Business Analyst Designers out there. Steve Blais is keen for us to Stop Gathering Requirements. Thomas Frisendel recently talked of The Changing Shape of Business Analysis. David Morris believes that We are All Designers Now. In response to David, Julian Sammy gives a more balanced view and declares himself to be Requirementortionist!
So, are you a Business Analyst Designer? Or perhaps a Business Analyst Designer by another name? Whether you are or not, I’d love to hear your opinion, so please feel free to leave a comment.
Requirements Engineer.
Analysis is critical to our role for the purpose of understanding what is being requested. However, understanding is not the end-game. The end-game is to define the capability of a solution via detailed stakeholder requirements. Stakeholder requirements model the solution of a specific problem. This differs from architecture, which models enterprise level solutions. That said, since enterprise modeling is considered design, I would think solution modeling should be as well.
On a side note, stakeholder requirements can then be decomposed into more detailed requirements for delivery to the development team, be it by the Requirements Engineer or someone on the development team.
Tony Heap:
Excellent article. It establishes that you are an analyst and also a solution designer. I consider this article to be both analysis of what a BA is or should be, and a recommendation of two independent roles or a single joint role (analyst and designer rolled into one).
In your case it may be true that you have preferences and talents to fuse two roles into one but there is a distinction of the two talents (analyst and designer) and people possessing only one skill / talent should also be able to take up and perform the specialized single role (and add value). That is, no one should be disqualified for NOT being versatile and equally capable in a wide range of skills and talents (here tow of them).
IIBA and BCS have done well in distinguishing and separating the two skill sets of analyst and designer but they seem to be “blurring the distinction and blending them” for some extraneous reasons. It appears that “only analysis” is “NOT sufficiently enriched and prestigious” for a profession or a society. If so, the title itself should be changed to represent what is sought or claimed.
I do see the benefit of NOT fragmenting two “inseparable parts of a job” but if there is a “practical, educational, managerial and economical advantage of separating certain skills”, it should be done and deployed. Such specialization does NOT in any way inhibit or prevent all-rounders to emerge and offer services of superior value more efficiently and elegantly.
The prestige and usefulness of a BA, confined to what IIBA and BCS definitions spell out, does NOT diminish for not including solution design or IT design. On this and to this extent I do not agree with: “there is no difference between requirement, analysis and design” or “everything is design”.
I see that you have not referred to “International Requirements Engineering Board IREB” which is in the same business as IIBA and BCS (they have collaborations of cross credits for their certifications). Please consider including IREB to harmonize the efforts of these bodies while they may have and maintain their distinctions.
Putcha,
The very concept of requirements blurs the distinction. As Steve Blais likes to say, “requirements are analyzed into existence” from all the information the BA gathers from stakeholders.
Hi Tony,
Great post. I really admire that you’re taking the time and energy to think hard about what roles fit your interests and skills. And for taking a path that is a bit less traveled, at least in the BA world.
I agree with you that there is a role for a person that can do both requirements analysis and functional design. It doesn’t work for all organizations or projects, but can be a great fit for some.
Looking forward to reading more of your posts!
Peace,
Brian
Duane:
That is a possible view. If it helps it may be used. But there is a danger of creating solutions without a need. When creative “analyst designer” discovers needs and evolves solutions, I believe that the distinction still exists but is not expressed because the two phases are fused. In an engineering application there must be clarity and distinction of these phases. In “virtuoso performance” which is closer to performing art or sport that distinction may not appear explicitly .
Let something reliable and useful emerge….all improvement is welcome but the methods must be workable irrespective of who applies them as long as they meet the pre-requisites.
Putcha,
Keep in mind of what I’m referring to as design, which is the definition of detailed stakeholder requirements. The analysis of all the gathered information results in requirements, and thus (IMO) design. If you don’t regard the end result of requirements as design, I have no response to that, as you may be right. I just don’t see it that way.
I agree with Tony’s position that “it’s all design.” But I also believe that the design should be uniquely presented to our two customers, the business and the solution team.
Duan:
I should have made this clear. The definitions of design I go by are:
plans, drawings, etc., that show how something will be made
http://www.merriam-webster.com/dictionary/design (noun form)
According to ISO 9000,
3.4.4 design and development set of processes (3.4.1) that transforms requirements (3.1.2) into specified characteristics (3.5.1) or into the specification (3.7.3) of a product (3.4.2), process (3.4.1) or system (3.2.1)
NOTE 1 The terms “design” and “development” are sometimes used synonymously and sometimes used to define different stages of the overall design and development process.
NOTE 2 A qualifier can be applied to indicate the nature of what is being designed and developed (e.g. product design and development or process design and development).
From the above I take that, Design is NOT the product. It is a description of making the product.
If “design” is something else for you. Then we have no common ground for discussion.
Putcha,
The ISO definition is a fine one. I include the *specification* of requirements as a first level of design.
Duane:
I am glad you find ISO definition to be a fine one.
I am trying to see how your statement “I include the *specification* of requirements as a first level of design” works or helps.
I agree that is indeed so, because “most requirement specifications” do include “some means of meeting the requirements”. Then the whole exercise would become “implementation” without much “design”.
To avoid such “design-less implementation” it is worth getting at “REAL requirements” of Robin Goldsmith and apply Roger Cauvin’s test of real need, “Does the statement of requirement tell you WHAT TO DO?” (not his exact words).
I consider *designing is discovering what to do to meet the need* and “design is description of what to do and how”
Happy specifying of requirements and great creative designing….
Putcha
I attended a keynote by Kupe the other day. His title preference is Business Advisor. I like advisor much more than analyst.
With that in mind, I’m switching from Requirements Engineer to Requirements Consultant :).
I will have to say that,based on this discussion, that I am not a business analyst or a designer or any hybrid: I am a Requirements Analyst , no bones about it. There is still good demand for the skill, and I expect that will continue for some time.
. I recognize that this discussion and future expectations of business analysis is wider than just information systems, but they are so ubiquitous, they can dominate any business design or solution. That is important because I am wary of analogies of physical things to software, like the building and architect example used. Software is still so new, and so different than anything else, that comparisons fall flat. Getting good requirements for software is important because it is not tangible, difficult to envision… Unlike a house or a bridge or etc
. maybe that will change some day, but I would not bet on it in the foreseeable future.
. If you can indeed do it by offering business design options, and succeed, power to you. But I still think you will miss opportunities to fully meet the business needs if you don’t elicit, analyze, and document requirements. It can be done, I do it every day.
David:
I agree with you. There is a need and value for BA and RE skills and services.
However, if some professionals can integrate other skills and provide superior services to some real clients / customers, that is welcome too.
I agree with you on the need to define what is architecture and design for information systems (in addition to building on “building architecture”) . Those who may be interested may see http://www.iso-architecture.org/ieee-1471/defining-architecture.html The definition and the explanations are refreshing. They still miss one vital point “PURPOSE”. There is no mention of purpose in the definition of architecture. Can there be architecture without purpose?
Maybe it is all about skills… And the debate about specialists versus generalists. … If you are genuinely capable in multiple skills, I see that as good and rare. Myself,I will do a little PM with my requirements work,but I wouldn’t sell myself as a PM.
… And existence and need for skills changes over time. My RE skills have done me service longer than what I was first paid for – PL/1 programming (!).
. but back to topic. A comment back on LinkedIn said “sounds like business consulting”. When we think of expanding the scope of classic BA, are we moving into the space dominated by MBAs and business consultant firms like Ernst & Young? Businesses have been implementing change and realizing value for a long time without us folks being involved.
Yes, David
Many people still mistake Business Analysis to be what Business Management professionals do early in their consulting services.
I hope soon enough an apt name for BA and RE profession would emerge and “what they do” will be distinguished from what others (business management professionals or IT developers) do and defined.
The “seamless” integration is NOT really helpful. It just gives a homogeneous lump of everything which can do nothing useful. Any useful system or process has distinct separable elements which are suitably interfaced and integrated to operate harmoniously. The usefulness comes from integration of unique capabilities, not generalizations without any details.
Putcha
I share your feelings. I get more and more calls for new positions labelled as “business analyst” but what they are actually looking for is for a business intelligence analyst or data scientist…There should be a body of standards for job names 😉
Johanna:
I agree with you. That is something IIBA, BSC or IREB should be able to do because of their very nature and strength of membership. It can be done with analysis and feedback from the professionals and employers.
If they say there is no value in distinction of separate skill sets and specialization …. that would be good new knowledge.
Dear All,
I wholeheartedly agree that the title Business Analyst is often misunderstood or “twisted” even to fit into what the client/employer/project thinks they want or need. I think the wide variey of backgrounds and skill sets which we all bring to roles often influences this too. I myself came from the “sharp end” of client/customer facing and operational role. I firmly believe this influences the way we ask questions, listen to and interact with stakeholders.
I suppose it is up to us to understand what is truly needed or being asked for, whether they be business stakeholders/ interviewers/developers/solution architects/project managers/etc., regardless of what is initially stated.
I look forward to watching the debate “rage” on and thank you for starting it!
Anne
Thanks everyone for your comments.
I’m not going to attempt to argue with anyone that their viewpoint is wrong – there are clearly different ways of working and everyone has their own preferences. As I said in the article, I’m trying to put a name to my way of working – it works for me and I suspect it could work well for others too if they have the right skills.
@ Putcha – thanks in particular for drawing my attention to the IREB – I wasn’t aware of them. I’ve had a brief skim through their website and, as you say, it looks to be largely in line with IIBA and BCS.
By NOT arguing that others are wrong, you are giving a better chance to the others to explore if they could be wrong. I found a lot of what you said is acceptable. A few others who believe “its all design” without any distinction, seem to now take note of ISO 9000 definition of design and its distinction from requirements.
So, its all vocabulary and precise meanings of the words which is at the bottom of all concepts and discussions.
What appealed to me in your post is that I too am an analyst-designer. It helps me to know some design aspects to refine and make statement of requirement precise and “solution-free and design-free”. Others who do not know the difference may be excused for mistaking design for requirement. I have an exercise for professionals to detect this trap. similar to Roger Cauvin’s Test .
Glad to know you look up IREB.
Cheers and best wishes,
Interesting article,
I’m a Business Analyst, I sit with clients, I collect requirements, propose ideas of how things can be implemented.
I prepare Business Requirements Document, with use cases and stuff.
But my boss keep asking me to include screenshots of proposed solution in the document along with use cases, I reply that this is the role of System Analyst.
Am I right or wrong? 🙂
I avoid including screenshots with *business* requirements because stakeholders will assuredly focus on them instead of the requirements. Moreover, it is more design than you want to get into prior to approval of the business requirements. In those cases where the business does in fact require a certain screen design, them by all means include it.
Do include them, though, in any documents subsequent to the business requirements approval.
And in my opinion, design does not make a person who “sits with clients” a systems analyst. It makes you a more robust business analyst.
Tony,
I enjoyed your article and wanted to share a bit of history. When we started the BABOK Guide (in 2007) we didn’t have any boundaries around “business analysis” and needed to figure out how to define the role/discipline. At that time, lots of the people who were doing business analysis work had come from the business side of their organizations (financial services, insurance, telecomm) and were a little afraid of the word Design. Business people were frustrated with IT groups because IT groups were designing solutions without any understanding of user needs. The most important message we were trying to advocate was the focus on understanding business needs and making sure IT solutions met these needs. Every time I used the word Design in a BABOK draft, it was edited out by another writer who kept saying BAs don’t design software.
At this point, I think we can use the word design more easily without implying that we are doing a technical design. BAs do design – we design user interfaces, we design procedures, we design interfaces, we design business solutions!
Hi Barbara,
That bit of history is really interesting, thanks for sharing! As I mentioned in the article, I’m looking forward to BABOK v3 – the early signs are that design does get a look in!
In the states, we frequently use the title Business Systems Analyst to indicate someone that is very similar to the Business Analyst Designer definition Tony references. As the iterative/Agile concepts became more and more entrenched, I think the role Tony has been describing here on his blog over the last few years is the natural response from the BA profession to defend against becoming marginalized by the iterative/Agile approaches.
Analysis and design are distinct and different (see the dictionary meanings and ISO 9000 definition). If those words are used their meanings and definitions are necessarily implied.
A single person may play multiple roles. The quality of any role he or she plays may be higher because of his or her awareness of other specializations. Then it is welcome but optional.
The value and worth of what is done in a given specialization (analysis or design) is how well it is done within its defined scope but NOT whether something else is done by the same person (irrespective of the value in the other specialization).
Versatility may be of value and desirable but it cannot substitute competence in each component of a composite work. There is minimum essential limit of well each specialized activity must be carried out in all practical situations.
Priority is to do every part of work well. In a surgery team, the anesthetist must do his / her work well and interface with other member well. It does not matter if he or she does NOT perform any surgery. His place cannot be assigned to another great surgeon if he or she does not know enough anesthesia. That is the point.
22MAY14
Hi Tony,
I come from a little different school of thought on what a BA should be/shouldn’t be doing, but I still think this was a very interesting read. Me personally, I’m fascinated with the portfolio side of things and have little interest in the “how”. I like to work on attempting to help my organization work on the right projects for the right reasons at the right time. We appear to be at the spectrums of what “typical” BA’s do, which is a pretty broad and gray area in general, so I’m sure we’re both still okay calling ourselves BA(designer)s. 🙂
The “designer” title to me implies that you’re focused on the “how” and not the “what”. Problem statements, requirements elicitation, feasibility analysis, cost/benefit analysis, stakeholder analysis, process flows, activity diagrams, JAD sessions, use cases – all tasks I think of when I think of an analyst and none have to do with the “how”, just the “what”. I personally tend to think of analysts as the ones that ensure the “what” is properly solved before the “builders” come in to help determine “how” to implement or fix that “what”.
I know we BAs gain valuable expertise from our experience in seeing many systems designed and built that gives us ideas and opinions that help to build effective systems and many BAs go the architect route. Have you thought about transitioning into an architect role?
Hi Matt – thanks for your comments.
The trouble with the words “what” and “how” is that everybody seems to have a different understanding of what they mean! By your definition (“problem statements, requirements elicitation, feasibility analysis, cost/benefit analysis, stakeholder analysis, process flows, activity diagrams, JAD sessions, use cases”), I am, like you, very much a “what” man. I produce (design) businss processes and I produce (design) use cases – the subtle difference is that I recognise that those business processes and use cases are not pre-existing and ready to be “captured” or even “elicited” from the heads of business stakeholders – rather, I am to design them, collaboratively with my business stakeholders, and also taking input from the technical team, who are in a good position to inform us on technical constraints, and also often make useful suggestions on the “what”.
As I mention in the article, I do business process design and IT system functkional design (i.e. use cases) but I don’t do “technical” design – although I have done that in the past (and I did call myself an architect!)
So to me it sounds like we are violently agreeing on the role of a BA!
Hello,
At last, I have found the person who have the same situation as me!
I am working as a designer for two years, and now as BA, with design skills.
Let’s up keep in touch!
Welcome to the “team” Azfar – it’s good to hear of other BAs with a designer mindset. All we need to do now is convert all the others 🙂 My suggestion is that *all* BAs need design skills – not technical design skills, but *functional* design skills (working out what an IT system is going to do for its users) and also businss process design skills. I think a lot of BAs *do* have these skills, but they don’t call it design, they call it “requirements elicitation” or something similar. Once we start calling it design, we are in a better position to realise that we can, and should, consider options for how best to meet the busienss objectives, rather than relying on our shakeholders to do it for us (by gathering/eliciting their “requirements”).
It seems the industry has responded. You are no longer a Business Analyst Designer. You are a Product Manager.