True Systems Analysis?


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 the business works.
  • 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. He can be contacted at: [email protected]


Article photo © NLshop -

Like this article:
  25 members liked this article


Marc Thibault posted on Saturday, September 4, 2010 3:51 PM

This has been a problem for a very long time. I didn't get to be called a Systems Analyst until I could turn an empty room into a multi-million dollar corporate IS resource.

Then IBM started using it for "two-years more experience than a senior programmer." The beginning of the end. 70's, 80's? I can't remember just when it happened.

The thing is, with Systems Analyst hijacked, there's no new title to replace it. For a few years, Technical Architect came close, but that's been drifting to mean "more than average development experience."

I've gone back, sort of, using "Business and Systems Analyst". But I still get calls from agents looking for somebody with ten years' Java experience.
Tony Markos posted on Saturday, September 4, 2010 11:06 PM

I enjoyed your article, but here is another consideration: A major problem is that 99.9 % of Systems Analysts (as well as Business Analyts) do not know what analysis is - let alone what systems analysis is. We really need to get back to basics.

We need to go to a dictionary (you, know, like they have at the reference desk at a public library) and look up the word "analysis". When one does such, chances are that the first listed definition will state that analysis is partitioning an entity into component parts (and then examining how those parts interrelate).

So analysis is largely about partitioning. Think of it this way: instead of being called Systems Analysts, these individuals should be called Systems Partitioners, because partitioning specifically defines what the major task at hand in analysis really is.

And unless we are as specific as possible about the major issue, the major issue will be unrecognized. If you doubt me, ask virtually any BA what guides him/her through the partitioning process. I will gaurantee you that you will get a blank stare.

David Wright posted on Tuesday, September 7, 2010 5:41 PM

Tim, great to see a post from you again.

Job titles and Roles confound a lot of companies; certain things need to be done, but who should do them, what skills and training do they need, etc.

That title "Business Analyst" is the most variable, but out of it I usually recommend the role of Requirements Analyst. Match an RA with an SA and you have a pretty effective team. The roles can overlap depending on the available resources. I have seen shops where doing requirements people also do external design... and have seen SAs do some requirements work as you describe.

Tim Bryce posted on Tuesday, September 14, 2010 11:30 AM
Thanks for your comments. The term "Systems Analyst" started to change in the 1970's as the role of programmers gained in stature. Most analysts today are glorified programmers. They are just entirely different job functions. I think the universities have done us a disservice in their curriculum as well. Bottom-line, we are our own worse enemies as we have failed to establish standards. To me, systems should be treated as a science, not an art-form.

All the Best,
Tim Bryce
Leslie posted on Tuesday, September 14, 2010 12:46 PM
"A major problem is that 99.9 % of Systems Analysts (as well as Business Analyts) do not know what analysis is - let alone what systems analysis"

I so concur.

Thanks for the article Tim. I find that the term Business analyst appears to e replacing Systems Analyst these days. Trouble is, that the Business Analyst description more often than not omits to include the 'analysis' part of the job in its description.
Tim Bryce posted on Tuesday, September 14, 2010 1:09 PM
I describe the separation of BA and SA using two different methodologies:

EEM - Enterprise Engineering Methodology - studying the business and devising an Enterprise Information Strategy synchronized with the business. Here, I talk about "Enterprise Engineers" which I believe is a more apt description than BA.

ISEM - Information Systems Engineering Methodology - designing and developing enterprise-wide systems. Software Engineering is considered a subset of ISEM.
Here I talk about "Systems Engineers" and "Software Engineers".

I also promote the concept of DBEM - Data Base Engineering Methodology - designing and developing the corporate data base logically and physically.

Then, of course, there is Project Management to watch over the methodologies.

All of this is part of an overall management philosophy which we call Information Resource Management (IRM).

Here are a couple of articles which should be of interest to you:

"Understanding the IRM/MRP Analogy"

"Enterprise Decomposition"

All the Best,
Tim Bryce

asjcma posted on Tuesday, September 14, 2010 2:30 PM
I concur with every word in your article Tim. Thank you for writing this.

I have been in companies diifferentiating between BA/BSA and SA where the former is more focused on understanding and identifying the need of the business while the latter is more focused on specifying the logical solution for that need specially in larger companies and enterprise level projects utilizing tools and techniques in business analysis documentation.

Regardless of the two being differentiated or not, I still believe that both shall focus largely on adding value and recommending solutions to the business or organization to further achieve its goals and worry less on the physical and technical design of the solution that may impair or limit the requirements therefore missing what is essential to the business.

Special mention on your last paragraph...and I will stay hopeful...

Thanks again,

J.J. Pellerin posted on Tuesday, September 14, 2010 4:16 PM
When I got my masters in information science I had to take a systems analysis class and it was right in line with what you describe as the actual job. Our instructor let us know from the outset that we weren't concerned with computer programs, we were concerned with systems made up of people.

So at least the UNT College of Information has it right.
Slipsurfer posted on Tuesday, September 14, 2010 5:54 PM

Great article!

After University, I sought out an employer who would give me structured career:

* Junior Programmer
* Programmer
* Systems Analyst

As you stated the systems analyst training did not overlap with the programming training; although it was a good foundation. As I moved through various organisations I have seen how the role titles have changed like fashion. Some days I was a applicaton analyst, a technical consultant, application consultant, solutions architech, business analyst; however deep down I know I am performing the 'old school' Systems Analyst role. As I look around the current job market the term is now almost obsolete. What do think is next season's title?

Keeping it real

zarfman posted on Tuesday, September 14, 2010 8:23 PM

Tim Bryce:

In Texas and many other states, offering engineering work to the public without a license is illegal.

Engineers can claim an industrial exemption if they meet the following conditions:

They practice engineering only for their fulltime employers.

Their practice is limited to work on their employer’s facilities or on products that their employer Manufactures.

They do not use an engineering title outside their company.

They do not claim that they are qualified to offer engineering services to another party.

In other words never refer to yourself as an engineer outside your company. Never moonlight engineering work for another company or project. Never offer engineering work on a contractual Basis.


Tim Bryce posted on Wednesday, September 15, 2010 8:49 AM
Zarfman -

Interesting. To me, engineering implies the discipline is based on a science with certain governing concepts and principles. This is how I perceive Enterprise Engineering, Systems Engineering, etc. I do not see it as an art form. If I did, I wouldn't use the term "Engineer."

All the Best,
Tim Bryce
[email protected]
David Wright posted on Wednesday, September 15, 2010 9:20 AM

Engineering, yes! Reminds me of PRIDE and IEM... when will that level of discipline be regularly applied to infromation systems? It would also clarify the BA and SA roles more clearly, perhaps with the recognition of the real role of Systems Architect.
Tim Bryce posted on Wednesday, September 15, 2010 9:30 AM
The hard part is to first get everyone to agree on such things as what a system is, what information is, what data is, etc. These are arguments we should have had decades ago. One reason we put PRIDE in the public domain was to encourage standardization.

All the Best,
Tim Bryce
[email protected]
Neeta posted on Thursday, September 16, 2010 6:48 PM
I am new to the so called role of System Support Analyst however , Sometimes it becomes difficult to streamline a diversified system which is spread across the globe and give your best of best analysis with defined time lines and limited business know how , A concrete analysis from all prospects helps drive the smooth process flow which is seldom understood by companies these days . I completely agree with the facts in the above articles which makes Programmer and System Analyst two completely different species and should have their own defined skill sets.
zarfman posted on Saturday, September 18, 2010 6:01 PM
Tim Bryce:

You wrote: Engineering implies the discipline is based on a science with certain governing concepts and principles. This is how I perceive Enterprise Engineering, Systems engineering, etc.

Zarfman writes: What science is Enterprise Engineering based on and what are its governing concepts and principles.

Zarfman writes: I agree with your observation about ads for BA’s. They seem to require an individual with experience in five different programming languages, and off the shelf software, and many different kinds of databases systems. What really irritates me is they require a degree in computer science, or engineering, or mathematics or its EQUIVALENT!!! What is the equivalent of a degree in electrical engineering? It seems to me one either has a degree in electrical engineering or one doesn’t. In my mind there is no equivalent.


Tim Bryce posted on Sunday, September 19, 2010 9:53 AM
Zarfman -

Thanks for your question. We spelled out of concepts and terminology in our book regarding the "PRIDE" Methodologies for IRM:

You can also learn more about "PRIDE" through our corporate web site:

Hope this helps.

All the Best,
Tim bryce
Only registered users may post comments.


Upcoming Live Webinars


Copyright 2006-2024 by Modern Analyst Media LLC