Note: I uploaded this post through my dev.to account but wanted to give many thanks to my teammate, Buss Smith, for the collaboration!

“What do you mean, you don’t code? I thought you worked in IT?” Business Analysts have heard these remarks since the dawn of the IT era. To a lay person, they are honest queries. Ask a Developer why he or she didn’t choose to become a BA, and you might get an answer something like this:

“And deal with office politics? No thanks!”

Ask that question if reverse to a BA and you’ll maybe hear:

“And become a robot? No thanks!”

OK, these are stereotypical replies - stigmas that paint Devs as nose-to-the-grindstone, introverted geniuses, and BAs as overly conversive, in-the-weeds necessities. There is certainly a huge degree of creativity in the development world, and writing requirements can certainly become robotic. But is there any truth to our make-believe replies? Probably. The fact is really that Devs enjoy writing code, and BAs enjoy facilitating that effort however we can, be it through writing, translating, communicating, or yes, even politicking. Successful projects obviously need both facets.

But should BAs write and/or understand code? Should we understand how to read code? And if we can read and write code, why aren’t we developers? These questions can be fairly significant conundrums for the average BA, and to a certain extent, for project leadership. The underlying fact is that most BAs choose to be BAs because we don’t want to code. That said, BAs, by nature, are really conduits between functional entities (Business Owners, End-users, etc.) and technical entities (Architects, Developers, QAs, etc.). It behooves a BA to know at least the basic functions of all the players in a given project. Simply said, a BA identifies, documents, and communicates opportunities for improving a business process in a high-level, functional fashion. In many organizations, the responsibility of validating the technical feasibility of the requirements that the BA communicates falls upon the Developer, which can for obvious reasons hinder that Developer’s ability to do what he was hired to do: code. Who then, can act as that all-important intermediary?

Our experience shows that clients today are asking for a BA to be more technical, but what exactly does that mean?

Meet the Systems Analyst.

Today’s Systems Analyst possesses the ability to not only elicit requirements from the business but also the ability to understand how information flows at a high level between systems. A technical Systems Analyst can understand system interactions, data flows, and easily take these complex requirements and be a conduit with this information to the business.

A traditional Business Analyst relies heavily on technically sound teammates to accurately gather requirements for a given task especially when the solution is not front-end or directly customer impacting. So solutions that involve true system-to-system, back-end interactions can prove daunting when gathering requirements for the traditional BA, resulting in adversely affected project scope, timing, and cost - essentially the triangle of Project Management.

Conversely, the Systems Analyst typically does not need to engage technical team members as often. Dependencies are minimized, allowing Developers to concentrate more on what they hired to do - code!

An easy way to start down the path of being more technical is to be more curious. Typically Business Analysts are asked to define the 'what' of a problem. Leaving the 'why' on the business and the 'how' on the technical team. But if you leave the "I'm not technical" thoughts behind, you can start to better understand. Pick the Devs’ brain as to how they come up with solutions and how those solutions work. Don't be afraid to ask the questions, they realize you're not a developer. Ask for one-on-one time to sit down and truly understand the technical requirements. Sure, this might take time away from some of their coding initially, but further down the road could save the technical team a ton of time because the analyst’s better understanding of 'what' is truly being defined.

Another way to better grasp technical solutions is to have at least a minimal idea of the architectural structure in place for the systems being used. Systems Architecture is a daunting term for Analysts, and can send them into ‘I’m not touching this!’ mode. Don’t let the term scare you. Architecture, from an Analyst’s perspective, is simply a description where the data you are analyzing is coming from. If you have a high-level understanding of where the data in the solution is originating, how that data is sent, and the logic used to effectively transmit that data, you’ll find yourself asking more pertinent questions, and more importantly knowing who can best answer those questions. And isn’t being able to decipher ‘what to ask and to whom’ a key to success in the Analyst’s world? We certainly think so, whether the solution is functional or technical in nature.

Some of today’s larger companies have the luxury of employing both traditional and technical analysts, but that is a minority. That landscape is changing. Hiring a Systems Analyst who can easily navigate today’s technical world while maintaining a traditional approach to requirements gathering and creating a true, functional relationship with the business is a huge asset to any IT department. It, therefore, behooves any traditional BA to dig deeper and acquire the skills to become a Systems Analyst.