Business Analysis (BA) is a role which collect, analyses requirements and get it across to the Engineers who build the ultimate product. It's crucial since it's the first step in any lifecycle be it product or software or any other. However, in the traditional BA role, solution requirements are fixed and documented up front on how the solution is expected to function at the end of the project. But with the constant change in the industry and competing firms with each other in the industry demand ones' to be Agile. This is where the traditional role of a Business Analyst gets converted to an agile model. An Agile BA is a role who is involved through out the entire life cycle of the project and involved in the facilitation and management of evolving requirements.
I'm a Business Analyst working for WSO2, a open source application development software company focused on providing service-oriented architecture (SOA) solutions for professional developers. On this blog post I would elaborate on my experience being a BA and challenges I faced during performing such. What I wanted to jot down this post is because personal experience be it good or bad, are the ones that drives you to the correct path.
The value addition of engaging a Business Analyst arise by actually facilitating them to be a part of the interface for a client in to an Organization. It's vital that the BA folks talk to the client throughout the Client life cycle since then the person would understand the evolving requirements of the customer and apply the learnings for the new clients. With the constant change in the markets a BA is no longer a person who documents each and every move of the client neither a person who does all the documentation; but an individual who should make an impression on the client.
Why is it exciting to be a BA ...
Being a BA is exciting since you get to learn so many different domains by dealing with clients. You not only get the wide exposure dealing with different clients but you tend to learn a lot since all those clients who deal contains are the best in their own domain.
We are thrive to make relationships with the client and not only just help sort out their identified problem. Sometimes these relationships help tone your own carrier.
For me, I loved the fact that how I saw technology at WSO2 is being put to solve a middle-ware problem. At WSO2 we have a complete PaaS platform and it's pretty technical since its' end user is always a developer itself. Therefore, the fact that how to apply the knowledge I have gathered testing the products being a QA in my carrier I now see how actual clients use them for different use cases. I used to look deeper in to technical back then but now I look at them in a birds eye viewpoint and how each technologies map in to an architecture. Its quite fascinating.
Why is it exciting to be a BA ...
Being a BA is exciting since you get to learn so many different domains by dealing with clients. You not only get the wide exposure dealing with different clients but you tend to learn a lot since all those clients who deal contains are the best in their own domain.
We are thrive to make relationships with the client and not only just help sort out their identified problem. Sometimes these relationships help tone your own carrier.
For me, I loved the fact that how I saw technology at WSO2 is being put to solve a middle-ware problem. At WSO2 we have a complete PaaS platform and it's pretty technical since its' end user is always a developer itself. Therefore, the fact that how to apply the knowledge I have gathered testing the products being a QA in my carrier I now see how actual clients use them for different use cases. I used to look deeper in to technical back then but now I look at them in a birds eye viewpoint and how each technologies map in to an architecture. Its quite fascinating.
Other side of the Coin...
Well, it's by nature that every job has its own challenges. But it's important for any job out there to define the boundary. Most of the people fail to do their jobs due to a couple of reasons, either they dont know what they are expected to do, or there's no clear responsibility or authority provided or someone else is overriding the task that you do or lastly the individual doesn't have the required skills.
For any BA including myself have faced or still facing almost all.
Why is it important for a BA to stick throughout the life cycle is; obviously from one call one cannot get the Business Problem they are trying to solve unless the client is really talkative :) Some don't just spill them out or some may just be 'so' vague and it takes forever to understand where the problem is. Working for a middle-ware company during the past 8 months or so, whenever I questioned about the business problem all they say told is they want to move in to a SOA. Is this the business problem? Hell No !! It's a step they just took to solve the problem. Of course if you just want to finish off the business that answer is more than adequate as we have a complete PaaS to cater to any middleware requirement that is out there. OK... The next problem is what is a business problem. For example, Lets say you're an e-ticketing company. Having the time taken between an end user clicks on a website and the time the end user gets the response is high. That is a problem !! It makes a problem since the end users will refrain from using the site if the site is slow. Well now one may say that for such a problem the how we find the root cause? Since the delay could arise anywhere. But making note of such a problem ensures that the problem is solved. If the ultimate problem is not solved if they choose the technology they thought, this would provide a bad impression to the technology provider. Whatever you do it's equally important that you do the RIGHT thing although you may loose the business. Being shortsighted will get the deal closed off but the company would not sustain. Hence the most important role of a BA is to identify the Business Problem and get the relevant architects to solve the problem they face.
Not knowing what to do is dangerous and this may be due to the lack of responsibilities you are put up with. How do we overcome this? Guess it's partly the task of the management of any organization to clear the boundary of a BA to perform its task and be very clear what they expect out of them. It'll be conflicting since a BA identifies the problem and this may be at the expense of the time. But it's crucial from the clients point of view. So at any given point of time there will be a cold battle between a sales guy whose looking to get to the target vs a BA who slows things down.
Since you are one of the very first guys the client talks it is important that you know your basics to surprise the client. In a good way :) Sometimes it's impossible to join in every engagement with the client, but a subsequent meeting should always be held to brief a BA of the technologies they have to identify and promote any remedies for potential problems similarly any new developments in the company. Also, a BA should learn the basic architectures with the help of Solution Architects since almost the same thing just move and evolve around. Knowing such most used architects makes you explain the solution to the customer easily and with real world examples the client will buy it. Therefore there should be frequent meetings to brief the BAs of such situations the technology has made a significant difference onsite.
All in all, if the BA be only put as a documentation guy a company will loose investing on such a role. Therefore, it's crucial to correct it at an early stage by clearing out the boundaries and identifying the actual responsibility of such a figure.
