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.
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.
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?