Our industry has a love-hate relationship with the software architecture role, with many organisations dismissing it because of their negative experience of architects who dictate from “ivory towers” and aren’t engaged with the actual task of building working software.
This reputation is damaging the IT industry and inhibiting project success. Things need to change.
Developers focus on the low-level detail
If you’re working on a software development project at the moment, take a moment to look around at the rest of the team. How is the team structured? Does everybody have a well defined role and responsibilities? Who’s looking after the big picture; things like performance, scalability, availability, security and so on?
We all dream about working on a team where everybody is equally highly experienced and is able to think about the software at all levels, from the code right through to the architectural issues. Unfortunately the real world just isn’t like that. Most of the teams that I’ve worked with are made up of people with different levels of experience, some of who are new to IT and others who have “been around the block a few times”. As software developers, the code is our main focus but what happens if you have a team that only focusses on this low-level detail?
Imagine a codebase where all of the latest programming language features are used, the code is nicely decoupled and testing is completely automated. The codebase can be structured and formatted to perfection but that’s no use if the system has scalability issues when deployed into a live environment.
Architects dictate from their ivory towers
The software architecture role is different to a developer role. Some people view it as a step up from being a developer, and some view it as a step sideways. However you view it, the architecture role is about looking after “the big picture”. Many teams do understand the importance of software architecture but will bring in somebody with the prestigious title of “Architect” only to stick them on a pedestal above the rest of the team. If anything, this instantly isolates the architect by creating an exaggerated gap between them and the development team they are supposed to be working with.
Mind the gap 44
Reducing the gap
Unfortunately, many software teams have this unnecessary gap between the development team and the architect, particularly if the architect is seen to be dictating and laying down commandments for the team to follow. This leads to several problems.
• The development team doesn’t respect the architect, regardless of whether the archi-tect’s decisions are right or not.
• The development team becomes demotivated.
• Important decisions fall between the gap because responsibilities aren’t well defined.
• The project eventually suffers because nobody is looking after the big picture.
Fortunately, there are some simple ways to address this problem, from both sides. Software development is a team activity after all.
If you’re a software architect:
• Be inclusive and collaborate: Get the development team involved in the software architecture process to help them understand the big picture and buy-in to the decisions you are making. This can be helped by ensuring that everybody understands the rationale and intent behind the decisions.
• Get hands-on: If possible, get involved with some of the day-to-day development activities on the project to improve your understanding of how the architecture is being delivered. Depending on your role and team size, this might not be possible, so look at other ways of retaining some low-level understanding of what’s going on such as assisting with design and code reviews. Having an understanding of how the software works at a low-level will give you a better insight into how the development team are feeling about the architecture (e.g. whether they are ignoring it!) and it will provide you with valuable information that you can use to better shape/influence your architecture. If the developers are experiencing pain, you need to feel it too.
If you’re a software developer:
• Understand the big picture: Taking some time out to understand the big picture will help you understand the context in which the architectural decisions are being made and enhance your understanding of the system as a whole.
Mind the gap 45
• Challenge architectural decisions: With an understanding of the big picture, you now have the opportunity to challenge the architectural decisions being made. Archi-tecture should be a collaborative process and not dictated by people that aren’t engaged in the project day-to-day. If you see something that you don’t understand or don’t like, challenge it.
• Ask to be involved: Many projects have an architect who is responsible for the architecture and it’s this person who usually undertakes all of the “architecture work”.
If you’re a developer and you want to get more involved, just ask. You might be doing the architect a favour!
A collaborative approach to software architecture
What I’ve talked about here is easily applicable to small/medium project teams, but things do start to get complicated with larger teams. By implication, a larger team means a bigger project, and a bigger project means a bigger “big picture”. Whatever the size of project though, ensuring that the big picture isn’t neglected is crucial for success and this typically falls squarely on the architect’s shoulders. However, most software teams can benefit from reducing the unnecessary gap between developers and architects, with the gap itself being reducible from both sides. Developers can increase their architectural awareness, while architects can improve their collaboration with the rest of the team. Make sure that you mind the gap and others may follow.