Agile Architecture


Why architecture matters

Solution architecture determines a lot. With good architecture the solution can be extensible, reliable, easy to maintain and advance. With bad architecture all the pains of complex solution development amplify significantly. 

But how to get there? How can we ensure productive architecture that will support all the discussed benefits? 

There are a few things that matter a lot to this outcome. 

The critical feedback

First of all, due to excessive complexity of software and IT solutions, any big up-front architecture is doomed, because as soon as it comes to implementation, a lot of things do not work out as intended. Of course, all of this often this remains unknown to those who design such architectures in the first place, as they can be far removed from the actual development process. And that’s a very bad thing. That means that the main feedback mechanism for architecture is broken. 

Incremental architecture 

How do you test architecture? You try to build something within that architectural concept and see if it’s working out. So, that is the primary cycle that has to be established and it needs to be fast. So, architects must work side-by-side with developers who implement their architectures and that information exchange cycle must be fast, otherwise the solution will navigate in the wrong direction very quickly and it will be very costly to remediate. Architectural problems are no regular bugs; you can’t just find the culprit in a single line of code and quickly fix it. Architectural issues may involve a lot of restructuring. So, this brings us to another important point: architecture must be built up incrementally, an architectural capability at a time. And every time such a capability is defined, the teams begin implementing some user-facing functionality within that capability and that immediately helps discover problems and quickly repair them... before a lot of other stuff has been built on top of that architectural idea. 

The continuous learning process

So, in summary, there are two primary things we must focus on: 

One: Those who define architecture and those who implement it must maintain tight, direct interaction. The implementors provide feedback to architects; architects adjust the design to accommodate for new learnings. 

Two: Build architecture incrementally. Define one or just a few key architectural capabilities and start implementing them. That will inform better ideas and better approach to the next couple of capabilities, and so on. 

Successful architecture is a result of purposeful, continuous learning. And of course, throwing something over the brick wall and expecting it to be successfully implemented is a matter of science fiction. We know better than that. It’s not a bad idea to establish a specific process of interaction between architects and developers: Attend each-other’s planning sessions, demos, problem-solving events, and so forth. Besides, some of the teams’ backlog items may be directly related to architecture. Maybe it’s a chunk of architectural work or some research activity or maybe it’s the first tiny slice of the functionality that will be built to test an architectural capability. In either case, it may be wise to treat those backlog items differently, keeping architects and possibly other subject matter experts in the loop, involving them in reviews, and so on. 

Taking action

Alright, it is time for action. How is architecture realized in your environment? Do you have a fast, reliable communication loop between those who define and those who implement architecture? What would be one simple, useful action item to improve your process? 

Alex Yakyma

Alex Yakyma is the author of “Pursuing Enterprise Outcomes” and “The Rollout”. As a consultant, Alex is helping enterprises succeed with complex challenges. Throughout his career, he operated in multi-cultural, highly distributed environments. Alex has trained a large number of change agents and leaders whose key role is to help their organizations achieve higher effectiveness at pursuing business outcomes.

Explore more content

Improving in the moment

Seeing the opportunity
Read more

Being an Agile developer

Knowledge workers are key to Agile <
Read more

Unit and Integration Testing Overview

The two important types of testing <
Read more
Contact Us