The Err of Business Analysts

First, let me say, I'm sorry to the Business Analysts (BAs) who may stumble upon this post, I'm sure you will have lots of disagreements with my assertions.

I read this article on InfoQ this morning and it made me start thinking...again...about business analysts. I'm not particularly interested in the argument over the terminology of business analyst vs. business architect, but, if we're going to accept Malik's definition of those two roles, I'll take a business architect over a business analyst any day. Personally, the term business analyst makes me shudder.

I've been a developer for about 18 years and I have worked in a number of different IT organizations including: small and large shops both with and without BAs and with BAs who held different types of roles. In my many adventures, I have come to very much dislike the role of business analysts, especially IT-based business analysts. Again, sorry to some of my friends who fit in this category--it's not you I dislike, it's the role. And the same holds true for business-based analysts depending on what their true role is. The real problem that I have seen with BAs comes down to Customer Affinity. You really do want your developers to be interested in and excited about "the business, it's processes and rules". The more involved and educated your developers are about the business domain and vision, the better prepared they will be to design software that fits that vision. I thought Eric Evans said it well, when he stated in Domain Driven Design, "...if programmers are not interested in the domain, they learn only what the application should do, not the principles behind it. Useful software can be built that way, but the project will never arrive at a point where powerful new features unfold as corollaries to older features."

The problem with introducing BAs is that they are roadblocks to customer affinity for the developers. The typical reason for creating a business analyst role is at the root of the very problem. Typically a business analyst is used to do a lot of the research work to understand the business and then to document the requirements so that the developers can focus on development -- essentially the same as saying, "let's not waste the developers' time learning the business vision so they can focus on developing the requirements." Unfortunately, there is intrinsic value in the work required to understand the business and the best way--perhaps the only way--to find that value is in the back-and-forth discussion that has to occur to translate business vision and needs into software. Unfortunately that value gets lost in communication, even by the most meticulous and skilled BAs. Even the use of BAs in an agile environment (where face-to-face communication is valued over meticulous documentation) leads to failure. The in depth discussions that result in the back-and-forth questions and answers yields value to the BAs but gets lost in translation to the developers. No amount of communication with the BA will ever make up for the lost opportunity to learn the business vision from the business experts.

This is because of the communication gaps that we all must jump. If you're not familiar with the term "communication gaps", I'd recommend taking a look at that link and in fact the whole section on communication in Alistair Cockburn's book Agile Software Development. Communication is difficult, we all git it wrong, all the time. We can never fully be sure that someone else truly understands our point of view or that we have fully understood another's. When you inject a business analyst between a business expert and a developer you now have to jump two communication gaps, business to BA and BA to developer, greatly increasing the risk of loss of fidelity and almost ensuring a loss of vision. Further more, rather than shortening those communication gaps, over time, between the business and the developers you end up widening them in some cases as miscommunication is increased.

The problem with BAs is that they are responsible for understanding the vision for the business from the domain experts rather than being responsible for the vision itself. This is why IT-based BAs are the worst type of BA -- in my opinion. They have IT responsibilities, not business responsibilities. They fall squarely into this pitfall of the double communication gap. Only slightly better than the IT-based BAs are business-based BAs (BAs who report through the business management, not through IT) whose primary responsibility is to communicate with IT. This is because their primary responsibility is still going to be trying to understand the vision from the domain experts rather than being a domain expert themselves.

Of course, the best scenario would be a scenario where the business owner and the software developer are the same person. Then you have zero communication gaps. But scenarios like that are not very common. And this leads me to believe the best scenario is to not have BAs at all. Unless BA stands for Business Architect and you accept Malik's definition of that term. I don't care what term we use, but the optimal scenario occurs when business departments hire individuals who are responsible for driving the success of that department (or parts of that department)--which inevitably means developing a vision, current and future, of what success means for that department. And then, secondarily, this person is also responsible for helping IT to understand that vision. Helping IT understand that vision should be the smaller portion of their job (although a very important one). It is requisite that those filling this role are very capable communicators, but that value is lost if they are not primarily responsible for the success of their department.

Customer affinity is a tremendous value, and in my experience business analysts, even great ones, are an obstacle to customer affinity.

On a side note, this is one of many reasons why I love working at Pluralsight. The developers work directly with the Partners who hold the vision, current and future, of Pluralsight. Much of that is funneled through one of the partners, Keith Brown, who has been involved in the code base. And so, not only does he have the business vision, he also understands the code -- in some cases better than the developers. It is a unique and beneficial blend, and further, if we have any questions we are free to speak with anyone in the company, including the partners, for any clarification. It allows me to get excited about the business and enjoy my work more and it gives me greater confidence that I am writing the software the business wants.