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.
Tim:
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.
Tony
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.
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
"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.
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"
http://www.articlesbase.com/information-technology-articles/understanding-the-irmmrp-analogy-32346.html
"Enterprise Decomposition"
http://www.phmainstreet.com/mba/ss060529.pdf
All the Best,
Tim Bryce
http://www.phmainstreet.com/mba/
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,
-arnel
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.
Tim,
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
David
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.
Regards,
Zarfman
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
timb001@phmainstreet.com
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.
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
timb001@phmainstreet.com
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.
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.
Regards,
Zarfman
Zarfman -
Thanks for your question. We spelled out of concepts and terminology in our book regarding the "PRIDE" Methodologies for IRM:
http://www.phmainstreet.com/mba/pridebk.htm
You can also learn more about "PRIDE" through our corporate web site:
http://www.phmainstreet.com/mba/
Hope this helps.
All the Best,
Tim bryce
Only registered users may post comments.
|