I recently came across some job postings under the title, "Systems Analyst," and it occurred to me people still do not know what it means. In the postings I saw things like:
"seeking a Systems Analyst with 4 - 6 years experience in defining system requirements, systems design specifications and implementation of major applications systems. Candidate must have experience with JAVA and the ATG application framework."
"Utilizes data modeling techniques to document business process and data flows."
"Strong SQL skills are required."
Sadly, Systems Analysts are still perceived as nothing more than glorified programmers, a misconception that hasn't changed in many years. This means people still have trouble differentiating between systems and software, the two are certainly not synonymous, yet one is often used to implement the other. The fact we can implement systems without automated support (a manual system) should be indicative of the separation of the two, but since we commonly implement today's systems via computer, the distinction becomes indiscernible to a lot of people. Nonetheless, the misinterpretation of "Systems Analyst" is typical of the sloppy thinking permeating our society.
A true Systems Analyst studies the business, defines the information requirements needed to support the business, and designs and/or modifies a system to implement the requirements. The system design consists of separate work flows, complete with inputs and outputs, that are connected through a shared data base. This then becomes the specifications for programmers to design, develop and implement software. When the programming is complete, the Systems Analyst is responsible for testing and implementation of the system.
This means a Systems Analyst needs to know:
- How to specify the information requirements of the business (to support the actions and/or decisions of the business).
- How to design a system into sub-systems (work flows).
- How to design inputs and outputs; e.g., screens and reports.
- How to design the logical data base (not physical).ow to write for people.
- How to develop and execute a test plan.
- How to prepare specifications for software.
If the Systems Analyst does his/her job properly, it eliminates the guesswork in programming thereby expediting the software development process. In other words, Systems Analysis is a precursor to programming. In the absence of a true Systems Analysis function, the programmer must try to deduce what is needed, a talent they are not necessarily suited.
Whereas a Systems Analyst is more of a generalist who is in tune with business and people, and tends to be somewhat extroverted in nature, the programmer is more in tune with technology and is very detail oriented as he/she must try to manage complexity. Because of this, the programmer tends to be more introverted. Whereas the Systems Analyst must look at the big picture, the programmer must focus on his/her piece of the puzzle. The two functions are totally different. To try to merge the two functions together does a disservice to both.
In my travels through the business world, I no longer see many companies trying to build major systems. Instead, I tend to see numerous programming assignments being developed with no overall system architecture. That is like trying to build a product without a set of blueprints. It's simply counterproductive.
When I hear people say, "We don't have time to do the upfront work (we don't have time to do it right)." I interpret this as, "We have plenty of time to hack away at the problem until we either wear out ourselves or the user (we have plenty of time to do things wrong)."
So how do we know when a company doesn't truly understand the Systems Analysis function? That's easy. When you see programming languages included in the job description.
Keep the Faith!
Author: Tim Bryce is a writer and management consultant located in Palm Harbor, Florida. http://www.phmainstreet.com/timbryce.htm He can be contacted at: [email protected]
Article photo © NLshop - Fotolia.com