Basically you have identified a data access interface that needs to be extracted. There may even the command aspect to it.
This reminds me of the saying that an XP project goes into "maintenance mode" from week two...
thought RUP was restrictive but probably the most 'agile' project i was on ( pair programming, test, test, test ) ended up a disaster because the core beliefs of scope, money, quality and time were forgotten. they thought mock objects and unit testing in groups of 2 would save them. the team ended up cnanging the tests more than the functional code.
Sounds like the marketing pitch of an outsourcing company. You're right, once they've outsourced IT they've disposed of a mission-critical portion of their business which they will find very difficult to "insource" if they ever decide that it was a mistake to outsource it.
That tends to be where I think B/As who specialize in an industry can be really useful; they've spent 5 or 10 years learning the busines processes that end-users in stove-pipe organizations don't even understand themselves (e.g. banking, trading). I also knew one B/A that had to extract critical info in bits and pieces over time from people who make it very clear to him they wouldn't be bugged frequently by development issues (people with big enough salaries and clout that they got what they want, period).
I can imagine how the IT/outsource firm internally could choose to be agile, I can imagine how the client could choose to be agile, but I suspect you are only going to truly see the benefits of agility if both those firms are willing to view themselves as part of one team, either because they are that professional and motivated or because the economics of the contract help to reinforce good behaviours and penalize bad ones.
quote:
--------------------------------------------------------------------------------
But consider a company where atrrition rate is high and bunch of new developers take over the application.
--------------------------------------------------------------------------------
HR problems should be solved by HR solutions, not by bureaucratic processes. Address the actual problem, the high attrition rate, don't put a process band-aid on it.
Depending on the website/forum you choose to hang out in you can find people who will fight ferociously for any particular methodology be it lightweight (e.g. agile, xp) or heavyweight (typical SDLC implementations).
If by that you mean do I think that the skills and professionalism of the specific developers influence the outcome (where the outcome is how well understood and maintainable the code is), then the answer is definitely yes. Not "developer centric" in the sense that only the original developer understands it - that is what you definitely have without readable code and good unit tests.
I don't think that is even just specifically a B/A issue.