“Good specifications will improve programmer productivity far better than any programming tool or technique.”
– Bryce’s Law
In terms of systems development, during the 1960’s and early 1970’s you were either a Systems Analyst or a Programmer. Period. At the time, there were substantially more analysts than programmers (at least a 2:1 ratio). This was due, in part, to the fact that computing was just coming into its own in the corporate world and there were still people around who could look at systems in its entirety. However, there was a screaming need for people to program computers and, as such, this became the boom years of programming. If you knew COBOL, Fortran, or PL/1 you could just about right your own ticket. Salaries were good, and you could intimidate your employer simply by what you knew (you had to commit something like murder to get fired). The emphasis on programming became so great that authors rushed out voluminous books to increase programmer productivity, hence the birth of the Structured Programming movement of the late 1970’s, which was followed shortly thereafter by the CASE movement (Computer Aided Software Engineering).
While programming was growing in stature, Systems Analysis was in sharp decline. Trade groups such as the Association for Systems Management (ASM) saw their membership dwindle to nothing and were forced to close their doors. The last of the old Systems Analysts either retired or were put out to pasture by corporations in the 1980’s. New job titles emerged, such as Software Engineer and Analyst/Programmer. This latter title is a bit of a misnomer as the emphasis was on programming and not systems analysis.
Although programming excelled, a noticeable void began to appear in terms of people who could see systems in its totality. Writing a good program is one thing, getting it to interface with other programs to form a whole system is something entirely different. By the turn of the century, the industry started to talk about such things as “Enterprise Architecture,” “Business Processes,” “Business Rules,” “Business Analysis,” etc. Further, new conferences, trade groups, and job titles began to emerge. Today, programmers are considered a dime a dozen and the stock of a true analyst is on the rise.
All of this is indicative of the industry trying to reinvent systems theory. In reality there is nothing new here as systems analysis is systems analysis. But as companies implement these concepts and job titles again, they are a bit uncertain as to where they fit in and their relationship to other Information Technology functions.
A Systems Analyst goes by many names these days; e.g., Business Analyst, Enterprise Architect, Systems Engineer (my personal preference), etc. Nonetheless, we are talking about a person whose mission is to study the information requirements of a business and design a total system solution to satisfy them. Further, the analyst is responsible for specifying the software requirements and, as such, is considered the intermediary with the programming staff. The personal characteristics of the …