I attended Developer Summit last week and went mainly to the architecture sessions.
One trend I noticed was the wake up call for developers to close the gap to the business side of their organizations. It is a line of thought I have taken for granted, but that may be because I worked for five years as a bean counter before I became a developer. The colleagues that came straight out of some tech school and never saw the process and people side of software development might need the wake up call, but calling it a new paradigm to see software as an enabler of business is to devalue a lot of talented people around the word.
Another trend I spotted was that we have to understand that there are lots of architectural decisions made at the developer level. I think that discussion is a bit taken out of context without discussing the role and abstraction level of architects. We tend to call a lot of developers architects independent of the level of abstraction they work in. Both deciding between static methods or a singleton and the amount of external data centers are considered architectural decisions.
I think that you hand over the right to decide about thing in abstraction levels below yours as soon as you hand over your design to the implementor. As I wrote here, I think that one responsibility of an architect is to aggregate external information and spread it within the organization. Seen from the abstraction level point of view that would mean that every one within a developer organization should aggregate information relevant to his abstraction level and inform those at a lower level. Taken one step further you have to inform the ones ‘above’ you too, since small gravel can make the optimal solution undo able.
It is not about climbing the abstraction ladder the better you get. It is about finding the abstraction level you are fit for and grow within it.