Being a "Technical" Business Analyst

There are projects like re-engineering from code or analyzing data to get some results. These are examples of projects when the BA must have a technical background. But I'm not going to talk about the obvious. Instead, I am going to address the "real" BA activities, like the elicitation - requirement analysis - specification trinity. I want to briefly talk about a) whether it is an advantage to have a technical background, and b) what is the biggest challenge a BA with technical background faces.

What does it mean to have technical background anyways? The developers read the specification (e.g. user stories) and implement the technical solution that fulfills the specification. For that, the developer needs some abstraction capability, the ability to write and implement algorithms, and knowledge about the software architectures.

Any decent business analyst who is worth their salt would have the first two skills. After all, the algorithm is just a kind of workflow, and abstraction is what we BAs do when analyzing the requirements, don't we? And the third one is not that hard - for the BA it is enough if they understand that most software consists of three layers - the user interface, the service layer that implements the business logic, and the persistence layer where - surprise! - the data is persisted. (Side note for the non-techy reader: the user interface is exposed to the users, they might even "hack" it as it runs on their computer, while the service layer runs on a remote machine, and therefore it is safer. That's why the business logic should be implemented on the service layer, and never on the UI layer.)

Apart from the above three aspects, we also have the terminology. For example, the BA says "role", and the developer likely says "entitlement" or "user's right". But we do not have to worry about that much, the developers are quite good at translating our words to theirs, as long as we don't pester them with the business terminology. They are used to it.

So what makes the difference then, being or not a business analyst with a technical background? Well, if we follow the predictive approach (e.g. waterfall), then I would say not much. In these projects, the architects are supposed to read our use cases and transform them into a working solution. But if we choose the adaptive approach (e.g. agile), then we are supposed to break the "use cases" (the close agile equivalent is the epic or the feature) into user stories. And that's when the technical background comes in handy. We are supposed to follow the INVEST principle - the stories must be independent (I) of each other (meaning that one does not have to read another story to understand the current one), and small enough (S) to fit into one sprint (if we use scrum) - and it is easier to follow these principles if we have the technical background.

Let's see an example. Suppose we have a complex application, which depends on several configuration parameters. Administrators are maintaining different parts of the configuration. They might create several versions of their configs and might want to test them before the changes are published by the responsible admin. There is always a published configuration and the main configuration, plus the custom configs of the other admins. The admins see the parameters of the currently selected configuration, so they can change the selection to see the values of that config. The tested configs of the different admins are merged into the main configuration, which will be published after a while so it becomes the live config. Some admins may be entitled to maintain more than just one part of the configuration. This admin application has many different pages and their visibility is controlled by the user entitlements. So this is the context and the goal of our project is to write the admin application supporting the admins.

The first requirement regulates how the admin application launches: "When the administrator logs in, the application must auto-select the configuration the admin selected last, so they can continue working with that configuration. If that configuration does not exist anymore, or the admin has not selected a configuration yet, then follow the appropriate business rule (see x1 attachment) to select the proper configuration. The visibility of the application's pages is controlled by the user's entitlements, only the pages the user is entitled to see appear. The home page of the administrator depends on the owned entitlements. The entitlements must be tested in a specific order (see x2 attachment), and the first found match determines the selection of the home page."

When we start to break apart this requirement, we find three sub-features. First, prepare the visibility of the pages. Second, select the home page. Third, select the initial configuration the user starts to work with. The first two sub-features are kind of atomic, and the third one contains two atomic tasks: persist the last configuration the user selects, and implement the selection itself.

Now the question is, will the non-techy business analyst break the third sub-feature apart? The answer is that perhaps they will, but not necessarily. They might argue that saving the last configuration is an integral part of the ability to select it the next time. They don't even want to create a separate story for that, they only say that the first decision to make is to select the last config if that exists. But the BA with technical background will break it apart for sure. The technical BA knows that when it comes to implementing the solution, then we have the process of saving the configuration selection, and another process of selecting the initial configuration. From a technical point of view, saving the configuration is not part of the selection process.

Both kinds of BAs know that there is/will be a requirement that regulates what should happen if the user selects a configuration. Eventually, the values that are shown on the application's pages must be loaded. But the non-techy BA does not consider the "save the selection of the last configuration" as part of this process. It is not related to the "refresh the content of the pages" workflow. On the other hand, the technical BA knows that this workflow is the best place to also save the config that is just selected.

Is it a problem that the non-techy BA won't break apart the third sub-feature? Well, as for the usability of the solution, it isn't. The developers will take care of that - will add subtasks for the story, one for saving the last config, and another for preparing the initial one. But it is a problem for the implementation process. It might be that the configuration selection feature is not yet implemented, and until then, the subtask of saving the last config is blocked, hence the full story is blocked.

Let's go one step forward. It was said above that preparing the visibility of the pages is an atomic sub-feature. From the logical point of view, it indeed is. The non-techy BA will write one story that regulates this requirement. But now the software architecture comes into the picture. This sub-feature has an impact on the user interface, the service layer, and the persistence layer too. We likely have UI developers, backend developers, and maybe even database developers (although in many cases the backend developers are also responsible for the database). These developers will implement their part, but they rely on the interface between the layers. Therefore, the three groups must define that interface. So they will add three subtasks for that story, one for each group, and they eventually will add the description of the agreed interface into those subtasks. So far so good, but what if the backend developers have no time to implement this subtask in this sprint, but only during the next? The story will be stranded, and although the UI part is done, the story cannot move forward. It decreases the transparency of the progress.

The technical BA is aware of this problem and will write two (or maybe three) stories, one for each group. Whoever starts their story first, still has to make an agreement with the others about the interface, and they implement their part independently of each other as they did in the other case. But it is much easier to control the workload of the teams because now the story will be set to "done" at the end of the sprint (at the latest). The price is that now it is harder to tell whether the whole sub-feature is done or not - we have to check the status of each "component user story" for that. The solution is the proper implementation of traceability, which is a must for each BA anyhow. For example, the BA will maintain an artifact that contains the textual description of the requirements and links it to the user stories that implement that requirement (and of course adds links from the user stories to the requirement artifact too). Now if the question is asked whether the sub-feature is implemented, the BA goes to this artifact, then checks the status of the bound user stories.

The non-techy BAs may adopt this mindset easily. They do not have to, but it helps the team if they do, and also it is less error-prone because the developers will have to make fewer decisions.

Let's continue with the biggest challenge of the technical BA. Simply put, they must refrain from the temptation of specifying the implementation. They should not write ever that "implement an endpoint that is called with the id of the specification and returns with the following data structure", or that "implement an endpoint that returns with the id of the initial configuration the UI must auto-select". No UI stories like "upon start, call the initial config endpoint to retrieve the id of the initial configuration" are allowed either.

Instead, we have a UI story "Upon start, the initial configuration must be auto-selected", and a backend story "Implement the business logic of selecting the initial configuration of the logged-in user by following this logic: ...". The UI developer will wonder "how do I know what must be the initial configuration", and will conclude to get it from the backend, so they will meet.

First, this way the developers will feel better, as their task is more interesting - they are free to define the best interface, and they do not oblige to use the "id". They are allowed to make technical decisions. And second, this is the keyword here - even if the BA has a technical background, that knowledge is weaker than that of the developers who sharpen it daily, so the technical decisions should belong to those whose knowledge is stronger.

And I daresay that forgetting what I already know (I mean, never adding implementation details to my stories) is likely harder than learning the above mindset for a non-technical BA would be. I'm pretty sure that the above considerations about breaking apart the requirements are already very familiar for many of them, while I'm still wrestling with my temptation of adding implementation details to my stories.