Tuesday, February 02, 2010

Are there any System Analysts out there?

Has anyone met a System Analysts lately?

I ask because I’ve been looking for over a year and can’t find one. I should say immediately I’m not looking to hire one, rather I want to find out what they do. I’ve looked and I’ve asked and the role seems to have disappeared from organizations. Or rather, perhaps I should say the title has disappeared; the role still exists in some places, for better or worse.

My belief is that the System Analyst role has been divided up between the Business Analyst and Architect roles. Like a System Analyst, a Business Analyst will look at what is required from a computer system but they (should) look predominantly from a business perspective, not a technology perspective. Like a System Analyst, an Architect will look at the current systems and how it they work and fit together and how they should work and what new work is needed.

(Note: Of course the Architect’s role is itself a complex issue and needs subdividing, that will need to wait for another blog entry.)

I’ve run this idea past a number of people in the last year and I’ve yet to have anyone seriously disagree. In order to validate it further I went to my old (1992) copy of Roger Pressman’s Software Engineering [[link]] and found the following definition of System Analysis:

“... system analysis defines the roles of each element in a computer-based system, ultimately allocating the role that software will play”

Pressman doesn’t define the System Analyst’s role still, it seems logical that a System Analyst is someone who does system analysis. Later in the book he gives the list of the objectives of system analysis:

1. Identify customer need
2. Evaluate the system concept for feasibility
3. Perform economic and technical analysis
4. Allocate functions to hardware, software, people, database, and other system elements
5. Establish cost and schedule constraints
6. Create a system definition that forms the foundation for all subsequent engineering work

If you look at that list 1, 3 (economic) and 5 fit squarely in the BA function while 2, 3 (technical) and 6 fit in the Architect role. The BA is concerned with the people element of item 4 (and the implied process change) while the Architect is concerned with hardware, software, db, etc. Of course the two functions need to work together here because there are trade-offs.

So that’s it, System Analysts no longer exist, an open and shut case. Except...

I’ve also observed what BAs do and I think some BAs are filling a System Analyst function while holding a Business Analyst title. This is wrong. A Business Analyst should be concerned with the business need and what will deliver value to the business.

In other words: BA should be concerned with the “what”, not the “how”.

When a BA steps into the “how” they are engaging in design and enter the world of Engineers and Architects. There are, at least, three good reasons why they must not do this:

1. By specifying the “what” they restrict the options available for the development team which means they prematurely close off discussion of how needs can be best and most effectively satisfied.
2. Engineers and Architects tasked with designing solutions have the training, experience and skills necessary. One wonders if the BA who suggests “how” has equal competences, and if they do, why are they working as a BA rather than an engineer?
3. Specifying the how undermines the engineering team and encourages them to take a box-ticking approach. This in turn affects quality.

In undertaking design (synthesis) they are removing their attention from analysing the what - making more work for themselves. Synthesis and analysis are very different activities and are deliberately separated.

(Of course, on a small team the same person may find themselves engaged in analysis one week and the following week tasked with creating the solution. In such cases it is still worth considering the two as separate activities and getting some mental separation.)

I’m commenting here on what I’ve observed, its not that I have a dim view of System Analysts - if there are any out there I’d love to hear your comments. In fact, there are two reason why I’d like to see the return of the System Analyst role.

Firstly, as Tom Gilb would be quick to point out: there is an important role for System Engineering in the IT development. IT work which is too tightly focused on a piece of software, or a point solution, risks ignoring the role IT plays in the wider system. There is a need for more System Engineering in our IT development efforts and part of that is System Analysis (although maybe a different type of system analysis.)

Which raises the question: who in a typical IT development team is best positioned to take on the wider system, interdisciplinary and engineering questions which arise in large development?

That sounds like an Architect to me.

Secondly, in so much as a System Analyst is one type of Architect I think it’s a better title because it is less prone to ego-bloat. Unfortunately, some people let the title “Architect” go to their head. Once they get to be “An Architect” they see no reason to code any more or get their hands dirty with detail. They prefer to sit alone, draw UML diagrams and issue edicts. I’ve heard them called “space cadet” or “astronaut” architects. They become divorced from that is really happening.

So purely on the grounds that I suspect the “System Analyst” title less prone to pomposity than “Architect” I think it should be used.


  1. Is the title and split necessary? Or is it more important just to be aware of the activity?

  2. My dad used to be a systems analyst, many years ago. The job title seems to have disappeared now.

    But I did work in a place where there was (and AFAIK) still is a very similar role. It was at a financial institution where we had to take price feeds from various exchanges around the world.

    We had what we called a feed analyst. They pretty much did the work you described. It was very useful for us developers to let the analyst do the early nit-picking on specs from the exchange, and to manage the relationship with the exchange. I worked closely with a feed analyst for one feed I was working on and his contribution was extremely helpful.


Note: only a member of this blog may post a comment.