Hi Stewart,
Great feedback and advice! Thank you for helping out your fellow practitioners!
Adrian
Don't post in here very much nowadays but I do take issue with your statement:
"as the BA you have to define HOW it will be sent"
Solution is not the role of the BA. Your company will have solution architects who have the skills, knowledge and training to do this. Its there job not the BAs.
Kimbo
Hi Kimbo,
I'm assuming you are based in the US? It's interesting, because 90% of UK companies, certainly the ones I have worked for, don't have such things as a 'Solutions Architect'. Even larger companies don't tend to have such roles over here. So more often than not it is either a joint decision between the Developer and the BA (If its a IT solution), very occasionally a Stakeholder (If it's a process) or it is the BA themselves who will determine the solution.
This is probably just a difference between the two countries and how Business has grown differently (and therefore works). A good example of this is that in the US certification of a BA seems to be all important, whereas here in the UK it is much less so.
It's an interesting topic though - national differences of how a BA works. I've noticed on this forum a few differences, to the extent where it would be interesting to see if a BA from the UK could get a job in the US and vice versa. My suspicion is maybe not?
Australia mate, not the US. although I have worked there and the UK too.
Didn't know that about the UK. bit surprised to hear it to be honest. Not doubting you of course, well maybe a bit :) If not an architect, then there will surely be senior developers?
Still think that before defining a solution, the business requirements need to be determined. Some may be parked until later and not even considered for a solution at that point. Plus going straight to a solution (perhaps you don't) means your requirements may have confirmation bias towards what the perceived solution will be. This may mean missing a better alternative or leave gaps from missed requirements. Plus in the future when your solution is end of life, your requirements may be too narrow to find a better solution - although you'd do new requirements then, so that's no argument.
Its a common mistake among BAs IMHO. A software solution or multiple software solutions may be only part of the business solution anyway.
Interesting topic.
brought to you by enabling practitioners & organizations to achieve their goals using: