The architect tries to limit project risks. So, she uses future-proofed designs containing abstractions. This can help to reduce maintenance efforts. But, when presenting such designs to developers, you may be surprised by bad attitude: "This is too complex to implement". Developers need simple designs for fast coding. Are you behind the eight ball then?
I myself like to discuss designs with developers. For me it's important to get early feedback from the guys who have to implement all this. So, I discuss all this not primarily with other architects, but with concerned developers. For me this is simply more effective.
So, if I get into "This is too complex to implement" discussions, I wonder what's the problem with my idea? Sometimes I missed something, so this critique is a kind of quality assurance for my design. This shows that it is worth to discuss with developers.
But, there are situations you know, the design works, but you earn unjustified criticism. What's going on here? For short, different focuses. The developer has to find implementations that work, whereas the architect investigates for reusability. The more concrete a design is, the faster the implementation can be done. The more abstract the design is, the more stable is an architecture in context to future changes.
How can we get together, developers and architects? Developers have to accept that a "more complex design" at the beginning of an implementation helps to simplify the development in the long run. The more experience a developer has with such "complex designs", the easier it is to get acceptance to follow such a design. So, you can expect longer discussion with non-experienced developers. On the other hand, with the right degree of openness for the unknown, even the most complex design becomes understandable if a detail has the right size.
Architects may have to separate the design into different and simpler views. To present concrete examples, that describe all the abstractions, can help here. There are two aspects in it: the current requirements and their concrete realization - to find examples for this is easy - and examples that show how the future can be, to give an idea of reusability. For this you've to read between the lines of your customers and may use requirements experiences from the past to get realistic examples.
The architect has to invest time for a mutual trust. For this it helps to meet on a regularly basis with developers. For me it is worth to do so, because the project results become better. Interesting to me: developers with an affinity to use patterns are good candidates to discuss reusability in more detail. But, whereas thinking in Java is a daily business for all developers, thinking in patterns isn't.
I'm not a fan of excessively using patterns, but it seems to be a problem for developers to even recognize why a certain pattern is used and which advantages it has in the concrete implementation. On the other hand developers are surprised at the implementation speed and elegance of pattern-based code when new requirements have to be implemented.
So, an additional mission for an architect is, to overcome all the developer's obstacles, so that those can create faster results in the future. Even if your developers come to the conclusion not until new requirements are on the horizon ;-).