Best Practices in Sustainable Software Architectures

---

Best Practices in Sustainable Software
Architectures
Posted by s.aragon on 22 May 2017 - 3:00pm
By Edward Fisher (http://software.ac.uk/fellows/edward- sher), University of Edinburgh , Raquel Alegre,
University College London , Grace Cox, University of Liverpool , Edward Smith
(http://software.ac.uk/fellows/edward-smith), Imperial College London , Violeta Holmes, University of
Hudders eld , Catarina Martins, University of Manchester .
This post is part of the Collaborations Workshops 2017 
speed blogging (https://www.software.ac.uk/term/speed-
blogging)
 series.
A critical concept within software sustainability is the correct choice of a suitable software architecture that can be
supported long-term and can be easily adapted given changes in the base requirements. But what do we mean by
software architecture, what can we draw from the historical development of software since the birth of computer
systems, and from personal experience and intuition?
A software architecture is a roadmap or blueprint for use during the development cycle. It is also a method of
segregating work packages amongst multiple developers or the logical separation of tasks in a single developer’s
sequential work pattern. As with building architecture, there are choices that can be made at the block diagram level
that radically impact both the end functionality of the work and the length and dif culty of the path that takes the
designer to that end. Again, as with building architecture, there can be an inherent artistry and beauty of optimum
design within software architecture.
Getting the architecture wrong can leave projects into dead ends, stretch the timescales, and in some cases, promote
the downfall of a project through unmanageable interactions between units, between developers or between memory
structures. From a developer’s perspective, their personal development scope may creep, a signi cant cause of burn-







---

out, as boundaries within a design are ill-de ned and project managers have little idea as to whose responsibility a
particular function is. Worse still staf ng issues may present developers and managers with an only-one-person-to-do-
this dilemma.
In his famous book of