Reply to: Ratio of B.A.s to Developers

[Dactylion]

I think they are more like interpreters between the Polish builders, the Russian Architect and the French customer - except they only speak english.

Quite!

Although possibly only english words rather than actual english english!

[vetran]

Are you any the wiser? Apparently they're like planning officers: look at the plans and say yes or no depending on whether the right shade of brown is being used.

I think they are more like interpreters between the Polish builders, the Russian Architect and the French customer!

[vwdan]

Are you any the wiser? Apparently they're like planning officers: look at the plans and say yes or no depending on whether the right shade of brown is being used.

Not really, I just feel better about not knowing! I'm just going to lump them in with Programmers and PM's in my 'Avoid where possible, never become one' list.

[VectraMan]

Thanks for this thread - I've been genuinely wondering what a BA actually does. (I don't have anything to do with this side of IT)

Are you any the wiser? Apparently they're like planning officers: look at the plans and say yes or no depending on whether the right shade of brown is being used.

[vwdan]

Thanks for this thread - I've been genuinely wondering what a BA actually does. (I don't have anything to do with this side of IT)

[MarillionFan]

I like to consider this in building terms.

Developers = brick layers, electricians, plumbers, labourers
Testers = Health and Safety bod who turns up
Technical Architect = Architect
Manager = Site Foreman
BA = Planning Officers
Customer = Client

Effectively, left to their own devices the electricians, plumbers, labourers etc are going to sit on the arses, scratching their bollocks, making cups of tea until the foreman tells them to get on with it. He's going to use the plans drawn up by the architect under the direction of the planning office. Every now and then the Health & Safety bod is going to turn up and make some general noise but on the whole not actually contribute a huge amount of stuff.

You're all paid by Customer, who effectively paid for the plans in the first place, got planning permission and did all the work to get to this point. Everyone on the site reckons they're doing the customer a favour building his house but in truth without him they'd all be on the dole.

[SpontaneousOrder]

Even in a well organised business with a well documented process, BAing could easily be a full-time job for anything less than trivial - so why would you get a developer to be a BA?

Lots of BAs are tulipe, and are just there because it's expected - just like loads of 'agile' dev teams are tulipe and are just 'doing agile' because its expected, even though if you asked them "to what end?" they wouldn't say anything remotely similar to "to allow the business to achieve a state of agility".

A good BA on a project which would benefit from a BA is a valuable asset.

[Old Greg]

You missed the point, it isn't that complicated but no one actually has ever documented it (its all Tribal Knowledge) and when they attempt to no one in the business actually knows how it works.

This causes the kind of screw up you are fixing. It nearly always starts with the Rocket Science statement!

OK, I get what you're saying.

[nomadd]

All,

I'm interested to know what your experiences are of this ratio
i.e. number of B.A.s in an I.T. department compared to Developers (including the DBAs)

1: 10

(NB. The "10" figure includes all Architects/Devs/Testers/PMs)

[vetran]

It doesn't need a rocket scientist at all, but it needs someone who understands the business - niche knowledge rather than complexity if that makes sense. I got a very nice piece of work sorting out a mess of a clinical system project where the developers and clinical teams simply couldn't properly communicate with each other to design and build a system that would efficiently and safely support business process and required data flows.

You missed the point, it isn't that complicated but no one actually has ever documented it (its all Tribal Knowledge) and when they attempt to no one in the business actually knows how it works.

This causes the kind of screw up you are fixing. It nearly always starts with the Rocket Science statement!

[Old Greg]

ah the 'our business is so complex that only a rocket scientist could understand it' gambit.

You ask them to document it and you find they don't understand it either.

Alternatively you find it they do exactly the same as everyone else but have made it so complicated by adding undocumented fudges that they need to change the way they work and use a standard tool.

Lets be honest most business requirements have already been solved over & over.

It doesn't need a rocket scientist at all, but it needs someone who understands the business - niche knowledge rather than complexity if that makes sense. I got a very nice piece of work sorting out a mess of a clinical system project where the developers and clinical teams simply couldn't properly communicate with each other to design and build a system that would efficiently and safely support business process and required data flows.

[Antman]

Has anyone ever worked with/used the business rules approach from Ronald Ross?

[vetran]

Imaging is relatively simple from a business perspective, so I can see that working.

Clinical documentation is substantially more complex because of the breadth and variations between differing specialties, disciplines and care settings.

ah the 'our business is so complex that only a rocket scientist could understand it' gambit.

You ask them to document it and you find they don't understand it either.

Alternatively you find it they do exactly the same as everyone else but have made it so complicated by adding undocumented fudges that they need to change the way they work and use a standard tool.

Lets be honest most business requirements have already been solved over & over.

[Mich the Tester]

Then you do indeed need someone to mediate between the clinicians and the developers. Sometimes, when the developers wanted to engage directly with the clinicians, we'd let them do it for a bit of fun.

Yep, that was the 'product manager', or 'Product Owner' in Agilese.

[Old Greg]

The application included both.

Then you do indeed need someone to mediate between the clinicians and the developers. Sometimes, when the developers wanted to engage directly with the clinicians, we'd let them do it for a bit of fun.