OpinionHow much design is enough?
Share this article
Imagine two people are decorating houses, side by side. One wants every detail mapped out in advance, researching all the possibilities and putting in a massive order before seeing anything in person. The other prefers a more spontaneous approach. They might have a vague outline of the sort of house they’d like, but they’d prefer to make it up as they go along.
As things come together, the first person realises that nothing they’ve committed to quite looks or goes together in the way they imagined and there’s no real turning back. The second has a rather more chaotic process, but everything that goes into their house is absolutely fabulous. It’s only at the very end that they realise they have painted the same room seven different colours throughout the process.
These ways of thinking shape more than just our interior décor – they crucially apply to how we understand tech and software development. Committing to a large amount of architecture before kicking off is no longer considered best practice, but including it is still vitally important. Architects, developers and potential clients are left to decide – how much design is enough?
Getting it wrong
Without architecture, the bigger picture quickly gets lost. For instance, a developer might be working on new functionality that will be shared to various departments. Developing it for one customer in one department is fairly straightforward. However – have they considered all of the flows and interactions with other parts of the business? Is there a potential to consolidate some functions into a shared one stop shop service?
Good architecture provides an awareness of dependencies, interactions and other contextual drivers, like legacy systems and stakeholder mapping. If you want something that’s more than the sum of its parts, it’s essential.
Too much upfront design though, creates a very long feedback loop where you’ve built half a system before you have any clue if any of it works. In the worst cases, “solutioneering” takes over and the design itself – sometimes pre-issued by the client, with tech already decided – becomes more important than understanding and meeting the requirements. By that point, whether or not it actually benefits the end user has probably been completely forgotten.
Most often, things go wrong when architects and developers don’t talk to each other. Each withdraws into an ivory tower and fails to communicate or remember the benefits of collaboration. As a formalised process, architecture can become too distant from the reality of building it and too rigid to flex to new information that arises from agile iterations.
How do we get it right?
Agile has taken over – and architecture must flex to fit in. This means greater levels of collaboration, working hand in hand with development teams.
Breaking up the architecture approach so that it’s completed in segments that align with actual development can keep the process one step ahead of the actual build while ensuring it’s still adaptable. This can also allow both sides of the work to both validate and verify: build the right thing via architecture that focusses on big picture goals, the right way through feedback focussed iterations. Features will not just be effective in their immediate goal but in the broader context of the software.
Architectural principles and patterns can also be vitally helpful by collaboratively establishing the broad guidelines for architectural decisions that will be made later on. To go back to our house designing metaphor, you might not decide exactly what furniture is going into each room, but you might decide on distinct colour schemes that harmonise with each other.
Together, principles and patterns keep services and features aligned and consistent. Not every detail is planned out, but there will be a clear understanding of how things like naming conventions and interactions will be done and how users will be authenticated. That can be easily replicated in the future while still leaving flexibility around it.
At its best, architecture works in harmony with other delivery roles, working toward the same goal and focussing on software that solves problems for the client and the end user. Balancing development and architecture means finding effective methods to maximise both capabilities and harmonising with each other. In this, as in most other things, teamwork and collaboration is key.
To find out more about our capabilities in this area, check out our IT Solution Architecture & Design page.
Share this article