#systemsanalyst

Learn about the Systems Analyst role, its responsibilities, skills, and the career opportunities in this dynamic field.

Back in the heady days of SSADM ( anyone remember that? ) and for a short while after, there existed a rare beast known as a Systems Analyst. These were generally intelligent individuals with a degree of common sense and some technical skills, who could ask useful questions of customers, propose designs, guide projects towards what was feasible and practicable, and bridge the gap between code and client.

These were supported by able Analyst Programmers, who worked at the sharp end to create what was needed but also - as the title implied - were expected to provide some thinking too.

Unfortunately, with SSADM being in effect the Maastricht Treaty approach to agreeing requirements and producing designs, their actual ability could never be fully applied, and on occasion they unwittingly ( and often unfairly ) took the blame for many inevitable disasters wrought in the name of 'process'.

Those roles were largely abandoned towards the mid-to-late 1990s, when business realised that multi-skilled personnel were both difficult to source and expensive, and that technical people tended to scare the more flappable business customers by asking such unsettling questions as "why?". 

It was much cheaper instead to employ battery farms of obedient code monkeys, and draft in Business Analysts - sometimes from the same dark realms within which Consultants lurk, waiting to prey on the unwitting - who could talk to the suits in their own language and not daunt them with any worrying technicalities largely due to their being completely ignorant about IT.

This struggled along with varying degrees of success, largely through developers ignoring the analysts and everyone pretending that what was delivered was actually what had been asked for or, in some cases, was even what was expected.

When the disaster ratio stubbornly refused to decrease, and it was discovered that anything more complicated than Notepad appeared to be delivered both laden with technical debt, unable to integrate with anything else, and already legacy before it was actually deployed, the industry looked at itself in puzzlement and decided Something Must Be Done (tm). At the same time, some of the older programmers reaching their technical ceiling of ability or at the end of any desire to move into either Management or Business Analysis were looking around for something new to do.

This led to the introduction of Technical Architects ( or Solutions Architects if they knew even less than that ), a role that to this day amuses and entertains generations of software professionals through its complete lack of any distinction or definition within the industry.

As a rule, these are ( or were ) highly technically skilled personnel who were either getting a little long in the tooth or distinctly bored with writing yet-another-database-system and so were instead elevated to supervise their peers. They were excused the need to deal with anything as trivial as details, but could instead loftily bridge the gap between the Business Analysts and Developers, whilst at the same time getting to draw hugely intricate, colourful and beguiling diagrams which no-one understood and which the coders would again ignore as either being a) unfathomable b) unfeasible c) hugely over-engineered.