“The essence of mathematics is not to make simple things complicated, but to make complicated things simple.” – S. Gudder
When we say the term business analysis, usually the main associations are exhaustive documents about business models and data analytics, and sometimes, if you allow yourself to be a bit exotic, you will think about a few diagrams in form of graphs or flowcharts (how wild, right?).
In my few years of experience as a developer, I was invested in solving problems and, as almost every developer, was addicted to the daily process of logical thinking and the general feeling of accomplishment once you solve a problem, however trivial or not it may be. When you think of business analysis, somehow you don’t get the feeling that you’ll be invested in a lot of creative solution design.
When I decided to change my career, I was worried – will I know how to live a day without these things? I spent years developing logical skills, mathematical skills, growing into an engineer and now I found myself thinking – will all those skills go to waste?
However, I’ve found that approaching business analysis can be quite an interesting mental exercise. Contrary to being a developer, where problem-solving is your main occupation (a very general phrasing), by being a business analyst your main occupation is defining the problem.
Once I realized that I am not that far away from my usual thinking process, my fetish kicked in.
SIDE NOTE: I know the popular phrasing of problem in IT nowadays is CHALLENGE, however, being a mathematician at my core, I am not scared of the word, since I solved like a billion of them in my freshmen year only, therefore I will not adhere to the modern standards in this part.
A problem is mainly and only an equation – meaning that, in most of the cases, it is solvable. Not only is it solvable, but it is also solvable in multiple ways and can have even more than one solution. Isn’t this comforting to hear? So, no need to use the tacky word challenge.
In the following text, I will try to compare certain aspects of business analysis to some typical mathematical aspects. So let’s start with some basic math.
The n + 1 proof
At the very beginning of your abstract mathematical journey, they teach you that, to prove a certain theorem (or in plain English – a statement) you need to prove that it is true for all known cases in the world (so, for every n that belongs to the set of N, which is the set of all-natural numbers).
Ok. To actually (mathematically) prove that, you need to find a (creative) way to show that it is true in the (n + 1) case. What is the (n + 1) case anyway?
Well, since you said that it should be valid for all n from the set of N, and the number n can reach infinity, your claim should also be valid in case your buddy n decides to level up to infinity + 1.
If you’re already a bit lost, no pressure. I have a shortcut.
Since all of this mentioned above seems like a lot of hassle, I’ll tell you what I do. You don’t need to go through all those cases in your head – you only need to find one that doesn’t work. Just one n, to put you out of your misery. One n that says your statement, well, is false.
In business analysis, we call this the edge case.
Whenever contemplating a certain business case, either with the customers or together with the team, once someone proposes a possible solution, I immediately rewire my brain from trying to find a solution to trying to break a solution mode (I do this to my proposed solutions too).
An edge case is not only an exception – it is a proof that your proposed way just does not work for all n from the set of N. In the math world, but that is also a deal-breaker, and to be honest, I wish it was the same in designing IT solutions. However, in IT, sometimes we accept solutions that only work in most cases, but afterward we scratch our heads when the unthinkable happened – the edge case has emerged in Production.
Mathematics dwells in perfectionism and we certainly cannot transfer the same rulings to the real world. However, as I mentioned above, a problem can have multiple solutions, and let’s try and find that buddy n that does not break once an edge case happens.
Suffering through solutions
One time during my studies, a few days after attempting an exam, the professor approached me while I was standing by the elevator.
“I cannot believe what you did!”- he said.
The exam I took was mainly about solving integrals. I was satisfied after I gave in my papers, even thinking about a good grade. Of course, that lasted approximately 15 mins – everything fell apart once I talked to my colleagues about the solutions and figured mine seemed nothing like theirs.
However, sometimes in math, if you apply a different approach to a problem it might seem that you’ve got a different solution. You see, since the result is a function and functions sometimes do not look alike but BEHAVE THE SAME (so, they’re the same), I still had faith that my solution could be correct.
I mean, I checked it multiple times. Line after line. Page after page…
“What? Page after page? How long did your approach take? I solved it in like two rows with a simple substitution.” – said my friend after the exam.
Well, I did not. I solved the task but it took me 3 pages. 3 pages of raw mathematical calculus. Even the darkest math kinksters would shudder at that sight.
“Once I saw your task, I immediately thought it must be wrong. However, as your professor, I am obliged to inspect it. I was hoping that you would make an error at some point so I wouldn’t have to go through all of it, but no, you did it. You solved it correctly. But man, did I suffer through it!” – the professor said while storming off into the elevator, leaving me behind, probably because he could not bear the sight of me anymore. I understood since I basically put that man through torture.
To draw a parallel line here – imagine the professor being a client and me being a business analyst, where the task from the exam was his business problem – what would his user experience be? From 0 to 10, probably much below 5 (and it’s a stretch), if we map that talk by the elevator to a feedback meeting for instance. The product works, but the client is suffering while using it (2/10).
The point is, it is not only important that you find a correct solution to your client’s problems, but it is also important that you try and optimize their way of working. Every working solution does not mean it’s acceptable. If the client needs to click and scroll multiple times for information you know they’ll be using constantly, you need to rethink your design. As a business analyst, you are required not only to identify the problem and figure a way out, you are required to understand the product, but also all the possible pains of it.
Bonus tip: Use your development team as allies on this one, they are far more advanced in matters of removing nonsense from solutions.
Understanding by magic
One long summer during my studies, I attempted to learn mathematical theory for the very first time. For those of you who do not know how mathematical theory looks like – first question: how does it feel to be God’s favorite? Secondly, mathematical theory is just like a description of a theorem (statement) and its proof. Or counterproof. Only not in sentences, but in mathematical symbols. When you first see it, it kind of looks a bit schizophrenic.
Day after day sitting by the book, it just wouldn’t go in my head. Luckily, one of those days my brother came along who already graduated from a similar faculty, recognized my agony, and gave me some advice.
Little did I know, that to learn mathematical theory you first need to learn how to learn it. You need to learn it by heart, but with understanding.
Let’s focus a bit on the understanding part.
When you see a bunch of symbols, your mind naturally tries to disregard as much as possible of it, in order to preserve memory. But this won’t help you much in the understanding part. Symbols in the equations don’t appear by magic, so you certainly cannot even try remembering them by heart without asking yourself where does every single symbol come from? And why? It’s not magic, it’s math – and math is precise and can always tell you where something comes from and what is the purpose of it. Once I realized that it made much more sense to me.
Looking at this from a project perspective – let’s say you’re dealing with a service placed somewhere in a complex IT ecosystem. Imagine that all the symbols mentioned above in math. theorem are little services that somehow communicate with each other inside this architecture. Applying my first method would mean you are greatly skilled in your service domain knowledge, but generally, you’re not sure where your service is actually placed in the ecosystem and what is happening around it.
As a good business analyst and business developer, you need to understand the purpose of all those services, when and how they communicate, and to what purpose. You cannot isolate yourself only to your own domain, since your service actually communicates to the outside world and intersects with the others. If you do, you are at great risk of designing solutions which are not true, not complete, and not satisfactory.
A problem can occur somewhere outside your service model, and sooner or later, it will become your problem too. It’s the same in math – one equation after the other, at one point you’re going to figure out that the symbol you so easily disregarded, now is the key factor to the solution.
To conclude, just like with business analysis described by exhaustive documents, you could look at math the same way. But why should you? Math was never meant to be that way, nor should the business analysis be. That’s just boring. Abstract thoughts of certain processes – be it the way your application responds to a certain API call triggered by an outside service, or be it the longitude of a tangent – in a similar way they coexist, trying and reaching out to you to find the most elegant solution.