D'Arcy from Winnipeg
Solution Architecture, Business & Entrepreneurship, Microsoft, and Adoption

Business Analysis – We’re Doing It Wrong

Wednesday, April 16, 2014 9:54 PM

Do you know what a Business Analyst does? They analyze business practices. Doesn’t that seem simple? And yet organizations the world over, and even the IIBA it would seem, consider them a super role that encompasses a wide variety of skills and capabilities:

Requirements Gatherer: Instead of utilizing techniques like value stream mapping to identify areas of business process that could be optimized/corrected, BA’s tend to be assigned the task of Requirements Gatherer. They meet with users and hear what it is the users want a system to do, what data should be captured, and even how system screens should flow. This usually leads to BAs also being assigned the role of…

User Interface Designer: I have personally been on projects where BAs were expected to own the user interface design of a system/application, and it seems commonplace to assume BAs would fill this role on projects. Very rarely have I seen where a BA actually understands the capabilities and limitations of the underlying technology being used. At this point some would point out here that technology shouldn't be needed to form a solution, yet in the majority of my experience this decision has already been made at some point. BAs are then left to generate user interfaces on technology platforms that they have no insight into – and nothing bad can come from that, right?

Test Writer: Wait, isn’t this a QA role? One may think that, but since the BA is gathering the requirements anyway doesn’t it make sense that they also write up the test cases for QA staff to run through?

There’s this idea that through the exercise of requirement gathering a BA will become an expert in the business, and that’s just not the case. Throwing a BA into a requirement gathering role is a systems level exercise because you’re capturing requirements of a system, not the details of how the business operates. There’s a huge gap here in identifying the proper roles needed on a project, and this is in part because not all organizations see the value in some of them. “We have a BA, isn’t that good enough?” No, you have a person that you’re assigning multiple responsibilities to when they may not be qualified for some of those roles. You may also not be getting the most out of a BA if you aren’t leveraging their core skills and abilities.

Part of the problem lies with legacy views from the Waterfall days. Big Design Up Front required people to gather requirements and fully design a system on paper before feeding it to developers (who were never included in those up front discussions). This type of application design *still* happens today, and even in shops that fly the Agile banner proudly!

So what should a Business Analyst do? They should analyze the business domain and key value streams an organization wants to improve upon. Technically agnostic, without any expectation of having systems-level knowledge. They don’t come up with domain models, they don’t do data models, they don’t even do screen shots. All they do is learn the business and identify opportunities to optimize/change/tweak to meet an organization’s goals.

At that point new roles are introduced to the flow:

Solution Architect
A technical person (but not a developer) who oversees all aspects of the realization of a solution.

UI/UX Designer
More and more I see how this is an important discipline. Note that this is *not* someone who knows Photoshop and is artistic. This is someone who is educated in the techniques of identifying how an end user structures their work and how to translate that into meaningful system user interfaces. This is an area I predict we’ll see huge growth in over the next few years.

System Analyst
A system analyst works with the Business Analyst to translate the needs of the business into a technical solution. All those requirement gathering exercises we talked about? This is where those happen – not at the Business Analyst level. The System Analyst should have a strong technical background and be able to make recommendations on how to best implement a technical solution. They work closely with the Solution Architect and the…

Technical Architect
Think of the TA as the leader of the software developers. This is someone who deeply understands the technical space and can speak authoritatively to the limitations and capabilities of the technical implementation.

Now, you may be thinking “Woah, there’s a LOT of people needed here. Are they all necessary?” Of course they are! For decades we’ve been assigning many of their responsibilities under one title: Business Analyst! How has that worked out for us? Have we gotten better systems? Are our end users happy? Are our developers excited to be part of a project that they had input to at the design stage, not just completing the potentially unrealistic requests of some requirement-gathering Business Analyst?

YES these roles are necessary, but they are useless unless all are stitched together with an attitude of collaboration and cooperation. No one group is more important than any other in the common goal of delivering the technical solution; all have their role to play.

The BABOK (Business Analyst Book of Knowledge) 3.0 is coming out soon, and includes the following definitions:

Design – A usable representation of a solution.

Requirement – A usable representation of a need.

“Usable” here scares me. Also they have two sections each titled “Requirements and Design Analysis” and “Requirements and Design Management”.

I fear that the current world view that Business Analysts are responsible for/own requirement gathering and solution design will continue and we’ll have the same issues as we do now on technical projects. Business Analysts are important and integral but we need to ensure we’re leveraging their skills and abilities in the right way in concert with other important roles.


# re: Business Analysis – We’re Doing It Wrong

Technically agnostic, without any expectation of having systems-level knowledge. They don’t come up with domain models, they don’t do data models, they don’t even do screen shots. All they do is learn the business and identify opportunities to optimize/change/tweak to meet an organization’s goals. paying someone to do your assignment 2/11/2016 11:23 AM | jack

# re: Business Analysis – We’re Doing It Wrong

CIPFA is the leading accountancy body for the public services providing education and training in accountancy and financial management. AAT Qualifications 12/7/2016 3:59 AM | Allen

Post a comment