Do we need Business Analysts?
-
While BA's can be useful, they should be used appropriately as an adjunct help to the developers. I wrote this about 1-1/2 years ago, and still believe this is true - from years of experience, having done it, and having seen it in action. The trick is finding the experienced engineers capable of project management and technology management with sufficient people and business skills. There are those out there who can, and within that population, those who will. I have seen on several occasions how non-technical management makes a mess out of technical projects. Some just take longer, cost more, and result in mediocrity at best; some were complete failures. Soup to Nuts[^] As for Agile... Agile Principles from a Traditional American View/[^] Rethinking the Software Development Life Cycle (SDLC)[^]
-
I have to agree with you. I've never worked with a BA who was worth their salary, but I'm sure there are some out there. My Agile story is when "we're going to try Agile on this project!". Then everyone except the technical people go away, and come back six weeks later with a 60+ page requirements document written by the BA. Sigh. No, that's the opposite of Agile. Of course, the document was so poorly considered, we had to do agile-like cycles of development/review/etc anyway. Only six weeks later.
-
It was something of a red herring for me to call it a waterfall model, because there isn't much point in designing or coding until the requirements are reasonably firm. After that document was written, a meeting was held to review it before development began. Yes, limiting the interaction between users and coders is important once development begins! SMOP = simple matter of programming? :)
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
I have to agree with you. I've never worked with a BA who was worth their salary, but I'm sure there are some out there. My Agile story is when "we're going to try Agile on this project!". Then everyone except the technical people go away, and come back six weeks later with a 60+ page requirements document written by the BA. Sigh. No, that's the opposite of Agile. Of course, the document was so poorly considered, we had to do agile-like cycles of development/review/etc anyway. Only six weeks later.
The two times I recall being handed a spec I threw it out and wrote something better.
-
The (flawed) business reasoning behind the proliferation of PM's and BAs is that because they work for less money, overall cost can be lowered for development by using less (and more expensive) software developer/engineer positions. The (again, flawed) thinking is that these non-technical PMs and BAs are offloading on a one-for-one person-hour the PM/BA type work from the developer. Of course, this (flawed) thinking comes from the business types who have no clue how software engineering actually works.
Interesting, I hadn't thought of it that way -- the average salary decreases by hiring more resources.
-
IMHO: No At my previous company, we didn't have BAs - and when I joined my current company we didn't have them either. But that changed, a few years back, when a new head of IT came in and decided he needed to replicate the structure from his old place. We now have dozens of BAs and are constantly recruiting more. What this has achieved over the last 5 years, is: - Software Developers being down-graded to coders. To be honest, some are not troubled by this. They're also not troubled by sitting, on their own, in their bedroom for a whole weekend, playing computer games! ;) - A layer of obfuscation. Having someone who neither understands the business nor the technology as the 'go between', inevitably results in Coders not developing what the business actually needs. - Lack of ownership. Coders no longer feel responsible for working with the business to understand how a requirement can best be developed and delivered. - A disconnect. Where we once had software developers working directly with business users to solve a problem, we now have the person who truly understands the problem, not talking to the person who can solve it. What's even more puzzling is that we are trying to be Agile! I've never been convinced that Agile is better than other approaches - but I don't see where BAs fit in!
This goes back to the 90's. "My" BA would tell me what he got from the user; then he would ask me to explain it back to him. I quit that company for lack of a bigger picture. BA's, in effect, think and act like you work for them.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food
-
Thank you. That is kind.
-
IMHO: No At my previous company, we didn't have BAs - and when I joined my current company we didn't have them either. But that changed, a few years back, when a new head of IT came in and decided he needed to replicate the structure from his old place. We now have dozens of BAs and are constantly recruiting more. What this has achieved over the last 5 years, is: - Software Developers being down-graded to coders. To be honest, some are not troubled by this. They're also not troubled by sitting, on their own, in their bedroom for a whole weekend, playing computer games! ;) - A layer of obfuscation. Having someone who neither understands the business nor the technology as the 'go between', inevitably results in Coders not developing what the business actually needs. - Lack of ownership. Coders no longer feel responsible for working with the business to understand how a requirement can best be developed and delivered. - A disconnect. Where we once had software developers working directly with business users to solve a problem, we now have the person who truly understands the problem, not talking to the person who can solve it. What's even more puzzling is that we are trying to be Agile! I've never been convinced that Agile is better than other approaches - but I don't see where BAs fit in!
In my opinion, it works best when you don't have business analysts, project managers, or even programmers / coders. Managing projects and analyzing the business needs is the responsibility of software engineers. You get better end results when the people writing the code are deeply involved in understanding the business needs.
-
IMHO: No At my previous company, we didn't have BAs - and when I joined my current company we didn't have them either. But that changed, a few years back, when a new head of IT came in and decided he needed to replicate the structure from his old place. We now have dozens of BAs and are constantly recruiting more. What this has achieved over the last 5 years, is: - Software Developers being down-graded to coders. To be honest, some are not troubled by this. They're also not troubled by sitting, on their own, in their bedroom for a whole weekend, playing computer games! ;) - A layer of obfuscation. Having someone who neither understands the business nor the technology as the 'go between', inevitably results in Coders not developing what the business actually needs. - Lack of ownership. Coders no longer feel responsible for working with the business to understand how a requirement can best be developed and delivered. - A disconnect. Where we once had software developers working directly with business users to solve a problem, we now have the person who truly understands the problem, not talking to the person who can solve it. What's even more puzzling is that we are trying to be Agile! I've never been convinced that Agile is better than other approaches - but I don't see where BAs fit in!
Hard no. Allocating resources to BA's is a mistake. They do not add value for the end user and they increase the technical cost, while reducing the individual ownership for everyone involved. I've seen enterprises run successfully with and without BA's, and without them there is less churn, more individual responsibility and less sunken costs in reports and metrics for internal use only. They do not add value and they do not contribute to getting the work done, so why waste the resources. Hire more support and customer training positions instead for a much better ROI.
-
While BA's can be useful, they should be used appropriately as an adjunct help to the developers. I wrote this about 1-1/2 years ago, and still believe this is true - from years of experience, having done it, and having seen it in action. The trick is finding the experienced engineers capable of project management and technology management with sufficient people and business skills. There are those out there who can, and within that population, those who will. I have seen on several occasions how non-technical management makes a mess out of technical projects. Some just take longer, cost more, and result in mediocrity at best; some were complete failures. Soup to Nuts[^] As for Agile... Agile Principles from a Traditional American View/[^] Rethinking the Software Development Life Cycle (SDLC)[^]
I feel like you're describing an FA instead of a BA. BA's basically mess around by "identifying" abstract business objects of value, typically for internal reporting to a board or a director. Then they make requests for implementing a business layer that respects and reports on those objects. This is done to give the board members a false sense of security. In reality, however, business objects are figments of someone's imagination made concrete, for no clear reason other than to show graphs or metrics. This in itself can create value if your brand narrative relies on fancy graphs and is mostly B2B oriented.. but the exact same result can often be achieved by measuring actual objects, so I fail to see the point of mucking up a code base for imaginary points of interest.
-
Hard no. Allocating resources to BA's is a mistake. They do not add value for the end user and they increase the technical cost, while reducing the individual ownership for everyone involved. I've seen enterprises run successfully with and without BA's, and without them there is less churn, more individual responsibility and less sunken costs in reports and metrics for internal use only. They do not add value and they do not contribute to getting the work done, so why waste the resources. Hire more support and customer training positions instead for a much better ROI.
-
I feel like you're describing an FA instead of a BA. BA's basically mess around by "identifying" abstract business objects of value, typically for internal reporting to a board or a director. Then they make requests for implementing a business layer that respects and reports on those objects. This is done to give the board members a false sense of security. In reality, however, business objects are figments of someone's imagination made concrete, for no clear reason other than to show graphs or metrics. This in itself can create value if your brand narrative relies on fancy graphs and is mostly B2B oriented.. but the exact same result can often be achieved by measuring actual objects, so I fail to see the point of mucking up a code base for imaginary points of interest.
I certainly would not tell you how to feel. You are entitled to your opinions and feelings, and I respect that. But in looking back over 40 years in software engineering in several vertical markets, and still being active and full time, so in fact and in theory, I was not describing a Functional Analyst. At the core of modern software architecture is creating abstract entities (e.g. classes) that may or may not describe real, concrete entities. So your run into business objects being figments of one's imagination does not logically follow. Business analysts that have little or no domain experience and do not understand how software is actually made are a waste of time. A senior-level software engineer can learn the BA aspects of the SDLC and manage the direct involvement with the business side (both process and people) much easier than a BA can learn the technical side. In my career, for example, I learned the business side and customer-relations side of software engineering quite easily, and breezed through getting an MBA. My point is that BAs and PMs that do not have the technical expertise and experience in software engineering are a net negative to successfully completing a software project with quality, reliability, sustainability, extensibility, with good performance, on time and on budget. Too often, in my experience and IMHO, the BAs and PMs are the bane of a developer's existence and a barrier to making a good product that developers must waste time trying to overcome. That said, the best BAs and PMs I have known are those that fall into at least one of these categories: 1 - Recognize their limitations and rely on the senior software engineer(s) to turn their business ideas into software ideas at the requirements and design level, and do not try to manage the architecture, design, development, quality assurance, and deployment aspects of the SDLC. 2 - Are willing to learn, put their ego aside, and take the time to learn about the much more complex world of software engineering.
-
I certainly would not tell you how to feel. You are entitled to your opinions and feelings, and I respect that. But in looking back over 40 years in software engineering in several vertical markets, and still being active and full time, so in fact and in theory, I was not describing a Functional Analyst. At the core of modern software architecture is creating abstract entities (e.g. classes) that may or may not describe real, concrete entities. So your run into business objects being figments of one's imagination does not logically follow. Business analysts that have little or no domain experience and do not understand how software is actually made are a waste of time. A senior-level software engineer can learn the BA aspects of the SDLC and manage the direct involvement with the business side (both process and people) much easier than a BA can learn the technical side. In my career, for example, I learned the business side and customer-relations side of software engineering quite easily, and breezed through getting an MBA. My point is that BAs and PMs that do not have the technical expertise and experience in software engineering are a net negative to successfully completing a software project with quality, reliability, sustainability, extensibility, with good performance, on time and on budget. Too often, in my experience and IMHO, the BAs and PMs are the bane of a developer's existence and a barrier to making a good product that developers must waste time trying to overcome. That said, the best BAs and PMs I have known are those that fall into at least one of these categories: 1 - Recognize their limitations and rely on the senior software engineer(s) to turn their business ideas into software ideas at the requirements and design level, and do not try to manage the architecture, design, development, quality assurance, and deployment aspects of the SDLC. 2 - Are willing to learn, put their ego aside, and take the time to learn about the much more complex world of software engineering.
While I do understand your take on the matter, and don't mean to undercut it in an unrespectful manner, I am gonna challenge the notion that classes could be based on either real or abstract entities. I'm 20 years deep in OO-design and the major problems I keep coming across with class-based designs, all originate from classes being based on non-concrete entities. As an iron rule within my own team, I demand that all classes are directly based on either concrete entities or the pre-defined abstraction layers we've all agreed upon (so services and data models are OK, helper classes or business objects are not OK). Over the years, this has been the magic sauce that made my team come out on top with regards to velocity and code quality. I'm playing with the idea of writing something on the topic eventually, because I think it's a relatively novel POV within our sector. I do like to use a quote from the matrix to highlight the underlying sentiment: When it comes to abstractions, "The problem is choice".
