From my first steps into the Corporate IT world circa the late 1980’s, I have seen a dizzying amount of roles and job titles as so have many others in the IT environment. Regardless of what was new, what was legacy, the O/S, the databases, languages, and especially the analysis tools, one thing I feel remained the same – The Systems Analyst. Even the Developer, Programmer, or Coder has changed when the technology shifts. They still basically code, but it is not the same as how the Systems Analyst remained a standard throughout the years. This is in spite of all the fancy name changes.
Still today, we see many Analyst titles:
- Functional Analyst
- Programmer Analyst
- Business Analyst
- Systems Analyst
- IT Analyst
- Operations Analyst
- Production Analyst
And there are probably more. Over the course of the last few years, the Business Analyst has taken on a more, well, Business related function. More Project Management related yet still dealing with the Process and Requirements. New tools such as Salesforce. New subjects like Business Process Management. Yet the Systems Analyst did have the skill and experience to take this all on and the nitty gritty tech side short of the tech pros who did the last mile of system changes. These being the domain of the DBA, SA, and Developer – perhaps a Network Admin.
As a Systems Analyst, I did the same work as I did when I was a Functional or Business Analyst. My domain was the full SDLC, requirements and planning to design to test to build to installation. To be a successful and goal exceeding analyst, you should know your customer’s process by being aware of their data, flows, and current setups. Maybe it does not mean ultra better requirements than a Business Analyst, but the key is when those are processed into a design, and that facilitates the best work with the DBAs, SAs, and Developers. This is better laid out in a Waterfall environment, but it should work well for AGILE as well. Some well known basic artifacts such as Process Flows and High-Level Designs are best served by the analyst being versed on the usual suspects: Data Structure, Database Design, File Systems, and Operating Systems to keep the list brief.
The Programmer Analyst I see is somewhat of a coder who does part of the analysis. They don’t usually go too high up the line to Business Process knowledge I believe, but they excel at the middle stages and do well at testing. Should they really be developing as well? No division of responsibility? Why no Systems Analyst to pull it all together. I am not thinking or believing that any of the aforementioned “analysts” are not important. My observation over the course of the waves of tech seems to find a never-ending position that I believe will always be there short of the unknown of course – The Systems Analyst. Why not train and educate people to be full Systems Analysts like the other roles in IT? I have not seen it, but perhaps I am just ignorant. There were no analyst titles in colleges back in the 80’s and perhaps still aren’t.
I kept one thing in my mind from what I learned in Comp Sci and Comp Eng courses, systems are basically three bare-bones sections: INPUTS, PROCESSES, and OUTPUTS. The infamous, “Garbage-In”, “Garbage-Out” lives in there. To be a good Systems Analyst, don’t just know how a software tool works or what favorite new procedure makes you follow, you need to use the basics, grab the big picture to drill down to the details, link it all up, document it, share it, whoops, sorry I meant collaborate. Like a driver or pilot gets to be a part of their craft, so a Systems Analyst takes command of the End-to-End system points.
Another great point to making successful Systems Analysts is to learn from the experts in each area, again, the DBAs, SAs, Developers, Network Teams. They run the show, but you keep it, or should, all humming along as your responsibility. Tools are great which many job ads and HRs seem to be looking for, but the knowledge and passion for process knowledge and collaboration trump that. We all collaborated long before that word ever was a twinkle in some Six Sigma teams eyes. It’s always been, common sense, using logic, digging, or dare I say, analyzing the situation.
The Systems Analyst, every IT should have one come standard.