Two (avoidable) Reasons Why Architects and Engineers Clash

Technology and Digital


May 5, 2016

In the blue corner, Enterprise Architects sitting at the right hand of the CIO, helping with big decisions around long term strategic planning, shaping transformation programmes, guiding long term technology choices and maximising business value.

In the red corner, developers are floating like butterflies and stinging like bees, trickling incremental changes in a ‘fail-forward’ culture where ‘test and learn’ lands a right hook on the chin of architectural theory. Feature driven development jabs big transformations in the eye.

Many transitioning organisations are on the ropes as they grapple with operating at two speeds at once. This can land a hammer blow on productivity and morale. Here are two ways to roll with the punches and keep moving forwards.

Round 1. Hey Engineers: Why so many flavours of different tech all doing the same thing?

Architects love getting ‘one’ of everything: a place for everything and everything in its place. One thing doing the thing it’s meant to do — well. Easy to change, and cheap to run. Ownership is clear. Everyone knows where they stand.

Anarchic Engineers come along and pick the latest open source tool, a different, better tool with each new project, and before you know it you’ve sixteen JavaScript frameworks, your code’s in every cloud in the sky, and inevitably, maintenance costs go into orbit.


Architects need to drop the notion of ‘one’ – except where it really matters. Yes, sixteen is too many but one would be stifling. Communicate where a single technology, approach or pattern really is essential by using shared principles and light-touch governance.

Engineers should adopt a technical radar (like this one from ThoughtWorks) that documents what technology is in production, what should be avoided, and what to try out on non-critical stuff. Simply documenting and sharing it will promote alignment, without constraining anyone. This works best when it is engineering led.

Then, a lightweight change process — using a discussion channel like Slack rather than a physical meeting — is a great way to bring in the Architects. Maintaining the radar creates a shared understanding and shared ownership and a place to continue building relations.

Round 2. Hey Architects: get out of my way, and stop slowing me down!

When running in two-speed mode, the legacy estate runs at one speed and digital products at another. Engineers have continuous build and delivery pipelines. Quarterly release cycles and three week-long regression test packs no longer set the cadence of software delivery. Whilst this is obviously seen as progress by many, it doesn’t give architects, or any other control function,  pace and providing their assurance that nothing is going to break, as a result of the release.


Three things will help here. First, the Architecture team should be keeping up with project development through sprint reporting and demos. The days of developers ponying up to a monthly meeting with a 20 page document describing proposed changes are long gone. Work with the product owners advising where the backlog can be improved. Turn up with a valid argument and you’ll be heard. This is a role shift for architects, and massively important if they are to stay relevant.

Second, architects need to stop waiting for something to go wrong so they can say, “I told you so”. Instead, look to preventing issues in the first place. Testing needs to be first class, so focus assurance on that.

Third, beyond testing, architects should help make sure accountability is in place.  . The goal of assurance remains the same, but the methods are different.

It isn’t just architecture teams that needs to change to resolve this particular battle.  Engineers need to look really hard at anything that touches legacy systems of record which are, of course, not built around the risk reducing, fail-fast paradigm. Unless you can completely decouple integration points it will inevitably slow things down.

Help speed up legacy testing by injecting some new-world approaches: your new friends, the architects, who show up at sprint demos and champion your testing approaches, and support models, should be able to help positioning this on the agenda.

The winner, by unanimous verdict…

… is the entire company, obviously. Get architects and engineers working together to control technical diversity without constraining progress. Re-cast the role of architect when it comes to assuring engineering products. And prevent either side from throwing in the towel.