Sometimes I feel like our disciple works in circles, what’s old is new etc. What I mean is after years of progress suddenly the discussion has turned to start to question whether the BA is needed and even whether requirements should be documented. Is it possible we are going backwards to where we were years ago in the software development process?
Where we were
Years ago when I managed software development for a mid-size company, software development consisted of having a developer sit down with the users and then run upstairs and start coding, there was no concept of software requirements, specifications (or any documentation) test cases etc. The process for software development entailed having a developer focused on a specific area and thus whenever we had new development in that area that is who we would send. This of course also meant that any maintenance of the application was almost always done by the same developer. Back then analysis was not seen as a separate responsibility or discipline. I certainly would not say that this is how development was performed everywhere but it was typical of companies which we networked with. Over the years the term business analyst was coined, and in larger development projects the role of the analyst was clearly understood as essential as the repository of process knowledge, facilitator, leader whose responsibilities were to understand what was needed, question, document, and finally communicate the end result to the developers. The complexity of our businesses, systems etc. have made the BA and also the business architect a necessity which may or may not have been necessary in the past. For another viewpoint read a conversation I recently participated on the SDN network (SAP Network Blogs – Just a developer?!) about the split of responsibilities between developers and analysts, this is a tough question, especially for in-house developers as they are usually fairly knowledgeable of the business and sometimes question whether a business analyst is needed or should be a go between them and a user. Longer term as the state of business analysis improves this discussion will become mute as the role of the business analyst will become much clearer and companies that leverage this position will be at an advantage. Small and mid-size companies might trail larger companies in this regard but that is only as it is typical for an employee to serve many roles.
Where we are
Over the past decade the software development process has been changing, the concept of the software requirement specification (SAP calls it a blueprint) has become fairly understood albeit I would argue that we are not yet at a good maturity level (I commented about this in a previous post What is a SAP Blueprint? so I won’t bore you with the details here). What I will say is that as we have started to make progress on the analysis front, suddenly there is discussion (I would call it more confusion) that new methodologies means there Is no longer a need for software requirements specs even whether a business analyst is needed. See Industry Watch: Changing requirements, changing skills for more details on some of the discussions. I am not certain that the new methodologies specifically are advocating that documentation and the analyst no longer matter but I think it is being interpreted this way. If you look at requirements from an agile point of view the only difference to the standard waterfall development is that instead of having the requirements upfront and signed off on before development starts the process is spread out over the life of the development process. The same issues exist regardless of the development process used, there is still a need for knowledge transfer, traceability, change impact analysis, risk assessment and all need to be factored in to the development process.
Are we going back to the past?
To advance the state of the art in development we need to certainly rethink the process but let’s not forget all the mistakes from the past and where we were before, we didn’t call it agile back then we just called it development because software development in general was in its infancy but I certainly would not want to go back to those days and though I embrace the use of agile development methods, I do not agree with .