Posted by: kalidasbhaisaab December 24, 2016
Login in to Rate this Post:
0 
? 
?
@k_ho_k_life I am sure you have looked into many materials that are available for the skill set called 'Business Analyst' therefore I will not go into details. The below is the summary of what I do. I hope it helps.
This is what I do:
I run and maintain a Report of customer accounts (under certain categories) that provides to management, a status of things that are past due, that are coming due and what actions are needed on them. There is a customer facing application, let's call it KalidasUI. To automatically and periodically run my Report (let's call it Kalidas Daily Dashboard) I have to pull data that are generated by KalidasUI in various tables that are across multiple database by using a tool (in my case it could be backend of Cognos BI or we use Toad; it depends on where the data type rests, i.e. Oracle db or SQL svr, because KalidasUI populates various databases). That is all that I do. I run and maintain the Kalidas Daily Dashboard.
Periodically, due to compliance changes (call it business generated requirements) or merely for enhancement of KalidasUI, I am asked to change my Kalidas Daily Dashboard. For example, The Retirement Accounts with more than a specific amount of balance, that falls under Account Type A, now needs to be pulled into my Kalidas Daily Dashboard. This Retirement Account Table, under Account Type A, was not previously a part of my Kalidas Daily Dashboard. Since Kalidas Daily Dashboard is also rendered in KalidasUI which is seen by external customers, therefore I will now have to consider this change request as a Project and work on writing a documented requirement for it. That is only because I support KalidasUI to generate Kalidas Daily Dashboard. I have to look into existing database schema, document how that schema needs to be changed, what are the business rules that needs to be changed (there is a decision engine, a tool, that I need to be aware of where my change will impact it), then I have to document all this in tools called RTC and RRC. Basically to manage end-to-end requirements for this project. Work with Release Manager on priority (that is sizing the requirements for a date of release, in sprint cycles), work with test team to document the impact to their Regression Test Suite (basically there is a suite of test skripts that run frequently, say every day or every pre-release, in a system of servers where all the logics, code and compilers run, called 'environment' that is almost like real time production environment. In our organization it is called E3 environment). I have to ensure that my new change to the application works as intended. That is to ensure that Kalidas Daily Dashboard shows the Retirement Accounts with Balance of specific amount that falls under Account Type A, and that this new change to the Kalidas Daily Dashboard does not adversely impact existing functionality of KalidasUI. This is done by properly (accurately) writing the requirements in RTC, RRC tool. Also, as an Analyst of Kalidas Daily Dashboard, which is part of KalidasUI, I have to respond to various questions coming from DBAs, Test Managers, PMs and Release Managers related to that change.
That is about it.
You already know about SDLC. As a Business Analyst I only support "a" part of that SDLC process. But all this work are in the realm of software development. In Business there is another important aspect of Information Technology which is called "Production Support". What if my Kalidas Daily Dashboard nightly batch fails to run? It is a Production Issue. There is a whole another team that works in Production Support. They handle issues that arise in Production. That is when the customer experiences an issue with the system. Therefore your work as a BA could also, in some cases, be on these type of Production Support and not merely new development as indicated by SDLC.This is the world of Incident Management, Defect Resolution, Prioritization of Defects for next Release. Say my Kalidas Daily Dashboard did not run because another program that populates specific table at the End of the Day failed to do so and the Control M jobs that ensure my Kalidas Daily Dashboard batch incorporates such table did not find those values on that particular day therefore it failed to run. To identify all this, someone needs to be dedicated to it. At 1:00 AM in the morning, if you are on call, supporting that application, you may get a call to be on the Communication Bridge Line to find out the Root Cause of why those Batch Jobs are failing. These are just examples of real scenarios if you were part of an application Production Support team.
Therefore in my few years in this field, at a high level, as a Business Analyst either 1. I worked to develop something new (a new requirement or towards an enhanced feature for an existing system) or 2. I worked to support an existing system in the real time. Those are plain vanilla BA roles. For these 2 role types, I needed other peripheral skills to support my work. I needed skills to understand how MQs worked to understand how my UI sends / receives data & session info. In other cases I needed to understand how rules engine worked. In the case of Kalidas Daily Dashboard, I need to understand how to make changes in current table, generally outlined in database schemas. To outline all these to my clients, I was asked to depict these changes in a diagram (common language like UML or BPMN may be used to show your requirements in a diagram). I needed to understand how to test them (therefore knowledge of JSON, REST, SOAP would have come handy). I needed to estimate my book of work and coordinate the resources in terms of planned release (a PM type knowledge was required). Knowledge of ITIL because I was interacting with change management concepts.
But these are not hard concepts to learn once you have the big picture figured out. Also whatever they say in the books, in actuality, as you mature with your application and the organization's system, people rely on you and demand more than what your Job Deskription would conventionally itemize.
And then there are other BAs that may work in projects specific to security (cryptography, IT Controls & Security Audit, Pen Test, Incident Response etc), Infrastructure (network and hardware requirements, Disaster Recovery and BCPs etc), Data Migration (including Integration Architecture, ETL, API and Micro Services patterns solutions etc). So there could be broad spectrum of core skillset that needs to be exhibited but the general idea is the same.
This is what I do:
I run and maintain a Report of customer accounts (under certain categories) that provides to management, a status of things that are past due, that are coming due and what actions are needed on them. There is a customer facing application, let's call it KalidasUI. To automatically and periodically run my Report (let's call it Kalidas Daily Dashboard) I have to pull data that are generated by KalidasUI in various tables that are across multiple database by using a tool (in my case it could be backend of Cognos BI or we use Toad; it depends on where the data type rests, i.e. Oracle db or SQL svr, because KalidasUI populates various databases). That is all that I do. I run and maintain the Kalidas Daily Dashboard.
Periodically, due to compliance changes (call it business generated requirements) or merely for enhancement of KalidasUI, I am asked to change my Kalidas Daily Dashboard. For example, The Retirement Accounts with more than a specific amount of balance, that falls under Account Type A, now needs to be pulled into my Kalidas Daily Dashboard. This Retirement Account Table, under Account Type A, was not previously a part of my Kalidas Daily Dashboard. Since Kalidas Daily Dashboard is also rendered in KalidasUI which is seen by external customers, therefore I will now have to consider this change request as a Project and work on writing a documented requirement for it. That is only because I support KalidasUI to generate Kalidas Daily Dashboard. I have to look into existing database schema, document how that schema needs to be changed, what are the business rules that needs to be changed (there is a decision engine, a tool, that I need to be aware of where my change will impact it), then I have to document all this in tools called RTC and RRC. Basically to manage end-to-end requirements for this project. Work with Release Manager on priority (that is sizing the requirements for a date of release, in sprint cycles), work with test team to document the impact to their Regression Test Suite (basically there is a suite of test skripts that run frequently, say every day or every pre-release, in a system of servers where all the logics, code and compilers run, called 'environment' that is almost like real time production environment. In our organization it is called E3 environment). I have to ensure that my new change to the application works as intended. That is to ensure that Kalidas Daily Dashboard shows the Retirement Accounts with Balance of specific amount that falls under Account Type A, and that this new change to the Kalidas Daily Dashboard does not adversely impact existing functionality of KalidasUI. This is done by properly (accurately) writing the requirements in RTC, RRC tool. Also, as an Analyst of Kalidas Daily Dashboard, which is part of KalidasUI, I have to respond to various questions coming from DBAs, Test Managers, PMs and Release Managers related to that change.
That is about it.
You already know about SDLC. As a Business Analyst I only support "a" part of that SDLC process. But all this work are in the realm of software development. In Business there is another important aspect of Information Technology which is called "Production Support". What if my Kalidas Daily Dashboard nightly batch fails to run? It is a Production Issue. There is a whole another team that works in Production Support. They handle issues that arise in Production. That is when the customer experiences an issue with the system. Therefore your work as a BA could also, in some cases, be on these type of Production Support and not merely new development as indicated by SDLC.This is the world of Incident Management, Defect Resolution, Prioritization of Defects for next Release. Say my Kalidas Daily Dashboard did not run because another program that populates specific table at the End of the Day failed to do so and the Control M jobs that ensure my Kalidas Daily Dashboard batch incorporates such table did not find those values on that particular day therefore it failed to run. To identify all this, someone needs to be dedicated to it. At 1:00 AM in the morning, if you are on call, supporting that application, you may get a call to be on the Communication Bridge Line to find out the Root Cause of why those Batch Jobs are failing. These are just examples of real scenarios if you were part of an application Production Support team.
Therefore in my few years in this field, at a high level, as a Business Analyst either 1. I worked to develop something new (a new requirement or towards an enhanced feature for an existing system) or 2. I worked to support an existing system in the real time. Those are plain vanilla BA roles. For these 2 role types, I needed other peripheral skills to support my work. I needed skills to understand how MQs worked to understand how my UI sends / receives data & session info. In other cases I needed to understand how rules engine worked. In the case of Kalidas Daily Dashboard, I need to understand how to make changes in current table, generally outlined in database schemas. To outline all these to my clients, I was asked to depict these changes in a diagram (common language like UML or BPMN may be used to show your requirements in a diagram). I needed to understand how to test them (therefore knowledge of JSON, REST, SOAP would have come handy). I needed to estimate my book of work and coordinate the resources in terms of planned release (a PM type knowledge was required). Knowledge of ITIL because I was interacting with change management concepts.
But these are not hard concepts to learn once you have the big picture figured out. Also whatever they say in the books, in actuality, as you mature with your application and the organization's system, people rely on you and demand more than what your Job Deskription would conventionally itemize.
And then there are other BAs that may work in projects specific to security (cryptography, IT Controls & Security Audit, Pen Test, Incident Response etc), Infrastructure (network and hardware requirements, Disaster Recovery and BCPs etc), Data Migration (including Integration Architecture, ETL, API and Micro Services patterns solutions etc). So there could be broad spectrum of core skillset that needs to be exhibited but the general idea is the same.