From practical experience, the emphasis in “breaking up architecture and development” is on “breaking” – it does not work.
A customer I have been working for decided to split software development across two different organizational branches: project management, specification, and architecture on one side and software development and testing on the other. The transition to this organizational structure was made in a “jump into cold water” fashion.
The idea was that the high level and therefore expensive work would be done in Germany and the low level cheap work would be offshored to a “development factory” (“industrialization” was another frequently heard term, but that is another story).
This did not pan out as planned, for a number of obvious and maybe not so obvious reasons:
- Architects in that company often are programmers that are either totally out of touch with current developments, or clearly less than decent programmers, or aren’t even programmers at all. IMNSHO an architect must have years of programming experience and must be a really good programmer with clear ideas on what kind of programming style promotes high software quality.
- Estimates where done independently by the architecture and the development team. Since both teams had different ideas about how the software would be designed and because these ideas never got synchronized the overall estimate often was the total of planned work for substantially different approaches.
- The architects had no real influence on the programmers. If concepts were not liked the development team simply priced them out of range (“if we do it like this (solution that we don’t like), it will cost 30% more”). Project management did not have the necessary insight to call shenanigans or to understand and act on long term consequences.
- When architects and programmers are separate persons a huge amount of information must be transferred in the form of papers, talks, and meetings. It is much more natural and efficient to let the senior developers, possibly with some guidance, develop the architecture, and then let them move on to programming as the project continues.
- Developers in India are not just “coders”, if that management idea of “low level programmers” would exist. They can and want to do architectural work, too. Intelligent programmers will resist to micro-management on the code level.
- The separation felt and worked like contracting development out to an external, untouchable company. Estimates had to be accepted like carved in stone; risk surcharges, profit margins, and baseline costs where added, and there was no direct talk to the programmers. Code reviews weren’t even on the agenda.
- And – the whole thing just does not work out financially. The plan was to specify everything down to a pretty low level and then let the cheap “code drones” take over. The problem: You spend 50% of the time or more on expensive experts working out a detailed specification and then try to get your money back by executing the last 50% or less with cheap labor. And then you find that instead of ten programmers you need fourteen plus two group supervisors plus one off-site manager to get the same job done, and your customer is not willing to deal with documents written in English. So much for comparing hourly rates by dividing one through the other and drawing the wrong conclusions.
As you might have guessed, the split between architecture and development has been reversed after a year of pain and suffering, and surely a lot of money and enthusiasm lost.