Scroll to top

Bridging the gap between Architects and Developers

Recently I was talking to an architecture team and they asked me about reconciling their TOGAF based architecture practice with their agile development methodology. Not long before in a discussion it was mentioned that developers often failed to see the forest for the trees, and some responses to that don’t bear repeating. The divide between development and architecture is still alive and well.

On the other hand, and more positively, most were looking to rectify this.

Here I’m going to address this issue by focusing on just one principle:

“The Architecture should make developers feel confident, not constrained.”

As a developer, particularly in a green fields project, you are often faced with an overwhelming number of choices. Being able to refer to an architecture to narrow down those choices and ensure they align with the rest of the system is a good thing, its something developers want. What they don’t want is to be forced in to aligning to standards which mean they can’t deliver on their commitments in a timely fashion.

What can architects do to address this:

The architecture should be visible and searchable. If you can’t find the answer when you need it, it might as well not exist (is that a zen parable waiting to happen?).

The architecture should not overreach. Providing guidance around governance, security and integration patterns is important, but trying to pick specific libraries and approaches is stepping on the developers toes.

Be willing to listen and act. If the developers raise problems you should listen, but more importantly you should act. Be it an architectural exemption, a good explanation, or a change to the architecture, you should respond to the pain experienced by those closer to the ground.

Recognise different needs. Be it Pace-Layered Application Strategy or another categorisation, you should recognise that an application which will be a core part of the organisation for five plus years has very different architectural concerns than one that will service a mobile app for a three-month campaign.

Not everything here will work for you, but by thinking about architecture as a tool for assisting developers you’ll likely discover better approaches and outcomes for all.