The Great Debate

Being children of the 70's, neither Eva or I thought much about IT careers in high school and college. So last week I asked her, in hindsight, what classes, activities or education from her youth indicated that she was destined to be, like me, a systems analyst. Oddly, we both had the same immediate response: debate.

First let's talk about systems analysis. A systems analyst gathers business goals, objectives and needs, then translates them into computer systems that help to achieve those goals. The systems analyst is usually responsible for the overall implementation and support of the system as well. You can draw an analogy with an architect who elicits requirements for a building from the owner and then translates them into designs for the contractor to build. The role demands excellent interpersonal skills, business knowledge and a technical background. This description of the systems analyst from the Bureau of Labor Statistic is reasonably good and shows that the pay levels are excellent and job prospects for the next 5 - 10 years remain good. In addition, the related role of business analyst is emerging as an alternate path that provides more entry level opportunities and requires less technical skills overall. For either position, the key is to remember they are first and foremost analytical jobs, not technical.

Which brings us back to the original topic - debate. In retrospect, we can now see how debate both encouraged the development of, and clearly demonstrated, the analytical, interpersonal and communications skills that are the hallmark of a good analyst. Here are some lessons learned from debate that helped us as analysts:

1. You don't choose the topic in debate, it is given to you. Likewise the systems analyst normally works in a number of business domains over his/her career. In fact, learning new things becomes one of the perks of the job. Some analysts do "go native" and specialize in one topic, but where's the fun in that.
   
2. You don't get to choose your position on the topic either. Just as the debater must argue all sides of the topic, the analyst must come to understand the perspective of all the stakeholders, whether VP or intern. Further, the analyst, like the debater, must understand that it isn't about his/her opinion.
   
3. You must thoroughly research a topic and organize the information so that it is easy to find. First, it means the debater and the analyst must resist the urge start with an opinion and work backwards into supporting documentation. Plus, you must be able to discern between good evidence and suspect. Second, both must think carefully about how information and data are categorized, organized stored and retrieved. Even though my database of choice is now SQL Server, not 3x5 cards, it still informed the way I think about information.
4. Your argument must be a logically structured set of assertions, supported by the evidence. The analyst is not generally in a debate, but must regularly make the case for a system or course of action. Argument structures like plan-meets-needs or comparative advantage provide the analyst or debater a reusable framework to build a case.
   
5. During the debate you flow the argument and rebut with evidence to the contrary. Creating a flow chart of the debate gives a quick visual map of the argument, which lays the foundation for analyzing and refuting your opponent's argument. The analyst also use models, like flowcharts, to document and validate the requirements of the system. Also, the analyst questions assumptions and challenges assertions with the same critical thinking skills the debater uses to refute an argument.
   

The point is, we were both preparing to be systems analysts without having a class in systems analysis or knowing that such a role existed. As more work becomes analytical in nature we need to have programs that help students develop those capabilities in general even when we aren't training them for a specific job.

Wax on, wax off.

Tags: systems analysis, business analysis, IIBA