Back in 2006 we wrote about how Architects are Part of the Team and shouldn't sit in ivory towers. This entry addresses some of the problems that arise when this is not the case.
In several organisations that I have been exposed to the architects sit within a completely different organisational area to the development team. Whilst I can appreciate this from a budgetary and reporting perspective (to an extent), it causes a number of very visible problems.
Problem 1: Perception
It is very easy for the development team to see a group of architects sitting in a corner, and think that they are sitting in an ivory tower coming up with unimplementable ideas for the sake of it. This puts you at an immediate disadvantage when trying to communicate an idea to the development team, as you are starting from a losing position. It is also very easy to actually become an Ivory Tower architect in this situation.
Problem 2: No ownership
If the architects are not involved in the project development as a matter of course - with appropriate power and responsibility - they can not be expected to own the deliverables coming out of that function. This is particularly a problem with non-functional requirements where there is no one else that can own them effectively.
Problem 3: Communication and Responsibility
In the situation where an architect has no formal relationship with the development team day to day, developers and project managers are free to ignore architectural advice that they are given, and even not bother to ask for it. The architect has no formal responsibility for the success of the project therefore why bother to consult them? Developers may also be more inclined to "muddle though" rather than seek architectural advice. This can result in a very poor deliverable (especially with relatively junior teams), and with architectural decisions being made by project managers and developers.
Problem 4: Firefighting
Architects effectively become fire fighters. There is a likelihood that the architects only hear about problems once they have happened - often after something has reached production. This can mean that they spend a lot of their time going back and fixing problems that would never have occurred with a better structure and earlier, more effective input.
Problem 5: Trust
In this situation architects may lose trust in the development team to deliver their vision, and as such feel that they must take on all architecturally significant development themselves. This can lead to a further lack of trust - this time from the developers and project managers to the architects and a vicious circle arises.
Clearly the absolute ideal is that architects are part of the core development staff and share the same management reporting lines. However, if this is not possible for various organisational issues, the development process MUST support architectural input at every step and a code-review and sign-off process should be instigated.
How are things structured in your organisation? What problems/benefits do you find with that structure?