We are looking at improving the process for handing over tasks from architecture to development.At one end of the scale it there is no architecture guidance you risk getting chaos, with each developer doing things his way.At the other end of the scale where everything is specified, the specification takes longer than the development, and you risk having very boring development tasks.Has anyone found an optimal middle ground between these extremes? Which artifacts do you deliver to development? For example: modules, class structure, or sequence diagrams?
Are there any best practices regarding the handover from architecture to development?
architecture
I will start out by saying that the very concept of a seperate Architecture team is an affront to good software development practices.  Architecture teams in corporate environments tend to be a culmination of the worst ivory-tower pseudo-intellectual bull** artists that can be found amongst the pool of developers.Other organizations treat Architecture groups like a political reward and justification for a massive salary to the most senior members regardless of merit, knowledge or skill.  Most consist of both types.Every developer can and should be an architect and should be involved in the high level designs of a company.  The very thought that a single group has complete dictatorial control over every aspect of software design and that must be handed off to developers who didn't contribute to the design, don't understand the reasoning behind the design choices, and may understand critical flaws in the design being more comfortable and closer to the actual implementation and existing code, is frankly completely flawed from its very core, and will consistently result in one of three scenarios:Developers do not comprehend the design, or outright reject it due the realities of the current implementation, and end up determining their own undocumented design and implementing that instead.  The situation is formal design documents that do not reflect the implementation of the software.The developers blindly follow the design that may or may not take current requirements or unique aspects of user stories into consideration, resulting in a buggy and poor quality implementation.Intelligent developers who understand the design documents, and are able to implement them, quickly get bored with not being involved in design discussions.  They are either likely excluded from participating in the Architecture group due to political or seniority issues, so they become frustrated, bored, and leave for greener pastures.  This negatively affects the project resulting in a brain drain causing the vicious cycle of poor software quality to continue.The single best way to mitigate this problem is CHANGE the Architecture group and possibly put them in tech lead positions.  The role of the Architecture group should be more or less a scrum of tech leads if you will.  They should only rarely meet and only discuss the highest level technical direction issues, Eg. think discussion migrating from Java to Scala, Abandoning Oracle for MySQL, possibly writing common utility libraries that mandate a certain TYPE of design process over another, switching from StarUML to Altova UML.Actual and real software design will be a community process involving ALL software developers, laid out by the extremely high level direction of the Architecture group.