RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Escape Metropolis: Bridging the Divide Between Developers and Architects : Page 2

The conflict between Planners and Workers in the film Metropolis can serve as a metaphor for the divide between architects and developers in the software industry. A veteran who's been on both sides has some suggestions for bridging the gap.


How Do We Escape Metropolis?

In the movie, the heroine Maria finds a solution by calling for a Mediator to bridge the gap between the Workers and the Planners. Closing the divide between architects and developers requires the same: we must become our own Mediators. As a developer, my approach for bridging the gap was to learn the language and concerns of the non-technical architecture community (Agar, Michael. The Professional Stranger. Academic Press 1996.). I read the Harvard Business Review and books on business change, organizations (Huczynski, Andrzej and Buchanan, David. Organizational Behaviour. Prentice Hall 2001; Wilson, Fiona. Organizational Behaviour and Work. Oxford University Press 2004; Dick, Penny. Introduction to Organizational Behaviour. McGraw Hill Higher Education 2005.), and consultancy. In addition, I spent some time learning Neuro-Linguistic Programming and influencing strategies (Wenger, Etienne. Communities of Practice. Cambridge University Press 1999.). These resources helped me understand the different perspectives and languages I encountered when interacting with architects and allowed me to work effectively with them rather than against them (Neuhauser, Peg. Tribal Warfare in Organizations. Harper & Row 1988.).
At the end of the day, we are all designers.

Architects need to take similar steps. I'm not a non-technical architect, but my advice is to keep track of what is happening in the development area. Trade magazines and sites such as Slashdot and DevX can help. As an architect I follow a few simple rules when engaging with development teams:

  1. Be very aware of deadlines and the need to provide pragmatic guidance in a timely fashion. This means being proactive, as development teams do not always feel they have the time to engage with architecture.
  2. Never dismiss concerns about a proposed architecture, even if I don't fully understand the issue at first.
  3. Ensure I have a network of development colleagues who are experts in technologies that I encounter.
  4. Always communicate precise and clear guidelines and architectures supplemented with practical examples.

At the end of the day, we are all designers; we just operate at different degrees of abstraction. Let's eschew this tribal behaviour and work together rather than talking at or working against each other.

Andy Schneider has worked in the IT industry for more than 15 years. During this time, he has built software in numerous languages (from embedded assembler to Java), run a software department, led software delivery teams (both small and large), and defined and built architectures—from applications through to enterprise scale architectures.
Email AuthorEmail Author
Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date