In general, what is business analytics? If we break down this phrase word by word, it is the analysis of business requirements. It is not design, it is not programming, it is specifically the analysis of requirements. The main task is to help the client understand what they actually need. However, clients and end users often present what they think are effective solutions to a problem as requirements. In other words, they believe they have already found all the solutions and want them implemented. The effectiveness of this is quite questionable, as it leads to project overload with requirements, which often contradict each other, and significantly increases its cost. In exceptional cases, the project becomes completely unfeasible.
A classic example of this kind is provided by Harry Hillaker, the chief designer of the F-16 Falcon fighter jet. His group was tasked with designing an aircraft capable of speeds of M2–2.5, which was (and likely still is) a highly non-trivial challenge, especially if the accompanying goal was to create a “cheap” lightweight aircraft. Consider that the force required to overcome air resistance quadruples when the flight speed doubles, and imagine how this circumstance affects the weight of the aircraft. When the design team asked the Air Force customers why they needed a speed of M2–2.5, they replied: “So the aircraft can disengage from combat if necessary.” When the real need became apparent, the designers were able to solve the main problem and present a workable solution: a maneuverable aircraft with high thrust-to-weight ratio, providing good acceleration and maneuverability instead of high maximum speed.
The conclusions from this lesson are equally valid in the field of software development. By understanding the true meaning of the requested feature or requirement from the client, the business analyst will be able to penetrate the essence of the problem, and if fortunate, the architect will propose a solution that is of higher quality and more economical compared to what the client insists on. Increased attention to the essence of the requirements simplifies prioritization: the most significant requirements for the client become decisive.
How should one proceed? In the Agile Manifesto, there is a principle that fits many cases very well: “Collaboration is more important than contracts.” From a practical standpoint, this involves conducting workshops and meetings where business analysts work together with architects to analyze the client’s needs, helping them answer the questions “Why?” and “Why?”. Keep in mind that finding answers to these questions can be quite a challenging task, because during the requirements analysis, the discussion often involves implicit assumptions and tacit knowledge. At such meetings, it is advisable to avoid discussions about technical solutions, as they shift the focus from the client’s subject area to programming.