I started off using Entity Relationship Diagrams as an Oracle Specialist and, as I encountered more types of formal analysis, made a point of learning about all of them.
As a result of my Java work I became exposed to UML as a diagramming notation for OO programming concepts but over time came to appreciate it as a fairly complete set of diagrams for supporting Business and Systems Analysis.
The recent search for a Business Analyst has highlighted to me that an awful lot of people are described as Business Analysts who, to my mind, do not have the skills to perform the job.
A good Business Analyst can add a great deal of value to a project. They are the front runner in terms of understanding the business domain. They have the following key roles to perform:
- Working with the business to understand the business domain.
- Capturing and documenting business requirements.
- Analyse the business domain to highlight areas of inconsistency and identify areas of uncertainty.
- Distill and communicate the business requirements to the implementation team.
The parrot is the so-called Business Analyst that just sits between the implementation team and the business and just acts as a conduit for questions and answers - actively subtracting value from the exchange by slowing it down.
The professional is, for me, the Business Analyst that can work with a business that has yet to fully formulate a problem and work with them to produce a full and clear definition of the problem and the business solution that can be used by the development team. The professional actively helps the Business think about the problem space and gives them the tools to properly understand it themselves. The professional will be able to answer a very high percentage of the implementation team's questions without recourse to the business as the questions have already been addressed by the analysis.
As far as I can tell the vast majority of Business Analysts in the Investment Banking sector fall perilously close to being parrots. While I am most used to UML, any business analyst that can use a clear approach to formally analyse the business domain and its requirements adding value all the while is fine by me.
As many of my colleagues will know I firmly believe that 'code is cheap' and I have come to realise that the same holds true of analysis documentation. What is truly valuable is the knowledge it embodies. While the concept of Bit-Rot is well understood in code; the same concept applies to analysis documentation (Word-Rot?). The real value is held in the analyst's head and in the heads of the business and implementation team at the end of the whole process.
I no longer believe that huge repositories of analysis have any real value - what is valuable is the process of producing the analysis and the knowledge that process imparts. A certain level of high level analysis documentation for invariant concepts can have longer term value but that will only be a small fraction of all that is produced.
I believe that there is no value to analysis artefacts that cannot be formally tested. Once an unit of analysis is complete it should be handed over to a tester for formal testing and then be used as the basis for User Acceptance Tests for the delivered system.
When a business analyst is required then you had better find yourself a professional and once the analysis is done you had better hold onto that professional. Inevitably team members move on, but perhaps the best hand over will be for the outgoing analyst to guide the replacement through a complete analysis of the domain.
I have worked with excellent analysts who have added immense value to a project and I have worked with some complete incompetents. Guess which ones I actively seek to work with again.
