Johannesburg, 07 Jul 2003
In this day and age one might be forgiven for assuming that companies would have an adequate understanding of how to build the software on which their business existence depends. According to Nigel Bakker, director of software development specialists, GuruHut, in many case, this is a long way from the truth.
"In any large software development project, a key person is the business analyst (BA), to whom falls the responsibility of interpreting the needs of the business and guiding the software development team," he comments.
"The problem is that BAs, or more accurately, their managers, often do not know this. In fact, for the most part, BAs and their colleagues appear to be not entirely sure what it is they should be doing. They often find themselves spending large amounts of time dealing with data related issues. This is an almost criminal waste of their valuable time".
Bakker believes that much software written for business, by business, is of questionable quality and costs too much to produce, often leading to negative return on investment (ROI). He says, "Two of the reasons which might account for this include, firstly, inappropriate project management, especially old and outdated project management practises in a modern software development environment.
"Secondly, BAs do not do the job they are employed for." Having been directly involved in software development for over fifteen years, Bakker says that he always moderates his expectations regarding the customers` definition of the role of a BA.
He notes that there seems to be little agreement of what a BA does for a living. He believes that BAs are responsible for liasing between the IT people building the required software and the business people who require it. "The BA should ensure that the IT people build software that matches and serves the needs of the business it will be used in," he comments. BAs therefore require a thorough understanding of the business domain in which they operate and should be able to communicate, in a clear and concise manner.
With this in mind he sets down three practises that BAs need to master in order to fulfil their role effectively. These are business process modelling, writing effective use cases (requirements analysis and capture) and use case driven functional testing. "They need to understand the business requirements if they are to communicate effectively with the software developers," notes Bakker.
He contends that BAs should not be delving into the design space, should spend less time scratching around in databases and should not be doing project management. "BAs do not make good software designers in the modern software space. Good design is a highly technical skill, which needs to balance the technology constraints with what the user wants, while ensuring that the system remains flexible, agile and robust."
Bakker notes that because the BA communicates and works with both the IT people and business people their job lines are sometimes blurred and BAs may find themselves doing project management.
"If the BA is responsible for getting the project delivered on time they may not have the best interests of the client at heart from a functionality point of view. The BA therefore needs to understand his role and extricate himself from any other role which is thrust upon him."
To avoid these problems Bakker states that businesses need to take a look at how they hire BAs and what they expect from these appointments. "BAs should be employed to enable companies to commission high quality software that works for the business. In order to accomplish this, both the company and the BA need to clearly understand the role played by the latter in software development projects.
Share