Skills for an IT business analyst?
December 8, 2010 7:16 AM
What programming skills are expected from a typical IT business analyst? What else should I learn?
I came to this by accident as a subject matter expert, so my skill set is more tuned to requirements gathering and writing functional specifications. I make data dashboards for the industry I used to work in. We take a bunch of different data and perform some predetermined ratings/analysis on it. I also have incredibly patient and talented Oracle and Java developers.
I understand most select-type queries and some basic stored procedure stuff in Oracle, but as I look forward I see needing additional technical skills.
To be honest, I'm more of a business type and programming is a steeper learning curve for me. I tried learning Python from MIT Open Courseware, but some of it seems like overkill since I don't want to be an actual programmer.
Anyone else work in this role, or work with someone talented in this role? Any other advice to me moving forward?
I came to this by accident as a subject matter expert, so my skill set is more tuned to requirements gathering and writing functional specifications. I make data dashboards for the industry I used to work in. We take a bunch of different data and perform some predetermined ratings/analysis on it. I also have incredibly patient and talented Oracle and Java developers.
I understand most select-type queries and some basic stored procedure stuff in Oracle, but as I look forward I see needing additional technical skills.
To be honest, I'm more of a business type and programming is a steeper learning curve for me. I tried learning Python from MIT Open Courseware, but some of it seems like overkill since I don't want to be an actual programmer.
Anyone else work in this role, or work with someone talented in this role? Any other advice to me moving forward?
Like you, I'm more of a business-minded BA, with some IT exposure. I find as I go through my career that knowing Oracle is invaluable - like you, I only really know the basics, but that's typically been enough. Crystal Reports is also a really useful thing to know, and increasingly Microsoft Sharepoint is becoming more prevalent (at least in my last few gigs).
With all of these, approach them as you seem to have with Oracle - you don't need to know everything about everything, but learn how to do some basic configurations, setups, and reports and whatnot and you'll be fine.
posted by pdb at 7:51 AM on December 8, 2010
With all of these, approach them as you seem to have with Oracle - you don't need to know everything about everything, but learn how to do some basic configurations, setups, and reports and whatnot and you'll be fine.
posted by pdb at 7:51 AM on December 8, 2010
*Don't overstep what you are comfortable with.
--If you can write SQL, or are inclined to learn it, and it really does interest you, then by all means please do, but if you don't feel comfortable with it then just keep away.
Coming from a programming perspective, someone who thinks they know how to write SQL to get at some small bits of data can just as easily write SQL to slow up an entire DB. That being said, a BA who can write SQL, or has some small scripting background can be a great asset since they will be able to do some extra homework and ask the necessary leading questions before coming to their programmers.
posted by zombieApoc at 9:32 AM on December 8, 2010
--If you can write SQL, or are inclined to learn it, and it really does interest you, then by all means please do, but if you don't feel comfortable with it then just keep away.
Coming from a programming perspective, someone who thinks they know how to write SQL to get at some small bits of data can just as easily write SQL to slow up an entire DB. That being said, a BA who can write SQL, or has some small scripting background can be a great asset since they will be able to do some extra homework and ask the necessary leading questions before coming to their programmers.
posted by zombieApoc at 9:32 AM on December 8, 2010
I have found that knowing some Python has helped me greatly from time to time.
Although I know enough SQL to write various queries, I will generally not write and run anything against a big production DB without consulting a DBA first; it's too easy to do something that brings the whole thing to a grinding halt and then you're buying beers for everyone for the rest of the project.
But by knowing some Python (and/or Perl), you can take a big resultset that comes back from a database and chew on it in order to produce useful results, including getting it into formats that make sense to non-technical users.
I've also found that some basic handiness with XSLT and knowing a good amount of Unix commandline-fu (grep, sed, basic shell scripting) aren't wasted either. The XSLT might not be useful if you don't work with a lot of XML data, though.
My feeling is that it's not worth it to try and compete with the developers I work with in their areas of expertise. I don't take my 'Teach Yourself Java in 24 Hours' skills and start screwing around in their codebase; if I did, I'd probably just create a mess that they'd have to clean up later. So instead, I've always looked for complimentary skills that let me help them (when I'm not doing other things), particularly when they're tasks that most developers dislike doing.
These will vary with each project, but logfile analysis is a common one that comes to mind. I've never met a developer who likes doing it, and it's often viewed as sort of obnoxious groan-inducing scut work. You'll probably win yourself a lot of respect if, when something blows up and leaves a few hundred megs (or worse, gigs) of log files in its wake, you can jump right on it and start grepping your way to a concise, useful description of the problem.
posted by Kadin2048 at 11:23 AM on December 8, 2010
Although I know enough SQL to write various queries, I will generally not write and run anything against a big production DB without consulting a DBA first; it's too easy to do something that brings the whole thing to a grinding halt and then you're buying beers for everyone for the rest of the project.
But by knowing some Python (and/or Perl), you can take a big resultset that comes back from a database and chew on it in order to produce useful results, including getting it into formats that make sense to non-technical users.
I've also found that some basic handiness with XSLT and knowing a good amount of Unix commandline-fu (grep, sed, basic shell scripting) aren't wasted either. The XSLT might not be useful if you don't work with a lot of XML data, though.
My feeling is that it's not worth it to try and compete with the developers I work with in their areas of expertise. I don't take my 'Teach Yourself Java in 24 Hours' skills and start screwing around in their codebase; if I did, I'd probably just create a mess that they'd have to clean up later. So instead, I've always looked for complimentary skills that let me help them (when I'm not doing other things), particularly when they're tasks that most developers dislike doing.
These will vary with each project, but logfile analysis is a common one that comes to mind. I've never met a developer who likes doing it, and it's often viewed as sort of obnoxious groan-inducing scut work. You'll probably win yourself a lot of respect if, when something blows up and leaves a few hundred megs (or worse, gigs) of log files in its wake, you can jump right on it and start grepping your way to a concise, useful description of the problem.
posted by Kadin2048 at 11:23 AM on December 8, 2010
If you can read SQL, Java, and HTML/XML then that should be enough unless you are working on a specific project that requires something else. It doesn't really matter, as long as you can understand the syntax of whatever language you are looking at, which after a while is pretty straight forward assuming the developer's don't pride themselves on their creative code writing ability.
You should not require any low level systems understanding that really get into the nuts and bolts of a language. Understanding the basic concepts of object oriented programming, procedural programming, scripting and how the result is executed (compiled, interpretted, etc.) is useful, but probably not that important in most cases.
If you personally have to change code, then I say you are a developer and my advice does not apply..
posted by dobie at 12:19 PM on December 8, 2010
You should not require any low level systems understanding that really get into the nuts and bolts of a language. Understanding the basic concepts of object oriented programming, procedural programming, scripting and how the result is executed (compiled, interpretted, etc.) is useful, but probably not that important in most cases.
If you personally have to change code, then I say you are a developer and my advice does not apply..
posted by dobie at 12:19 PM on December 8, 2010
This thread is closed to new comments.
In my role, I've used my (very limited) programming knowledge to help me determine what questions to ask. Because I know something about what the developers do, I know what they need to know. Also, having worked with QA over the years, I know the kinds of things QA needs to know. This guides my writing of business requirements and functional specifications.
My suggestion: do some looking for BA jobs and see what skills are requested. I've done some of this and I see the gaps for me are either 1. a particular subject matter expertise that I don't have (e.g., Finance) or 2. a particular tool or set of tools that I haven't used (usually something Oracle-related, but that reflects the trend at the large co. where I work). I haven't seen ads looking for heavy programming skills for the BA role. Not sure if I'm answering your question, but I hope this helps.
Another thought: you might try contacting the folks at http://www.batimes.com/
posted by tuesdayschild at 7:41 AM on December 8, 2010