Architecture, especially in projects that follow the agile philosophy (and maybe the scrum methodology) tends to be downplayed. This is because the agile manifesto says that we should focus on “working software over comprehensive documentation” (architecture is generally comprehensively documented) and “responding to change over following a plan”.
There are lot of benefits in having a well put together solution architecture and the following list illustrates these.
A solution architecture…
Allows for early design decisions.
The architecture is a representation of the earliest design decisions we make about a system. These decisions enable and constrain everything that follows in the eventual implementation and tend to be the key decisions that will cause major problems and increased cost / effort if changed later. This inevitably delays a project.
Allows for the early prediction of system quality attributes.
The architecture will allow us to predict how maintainable the system is if we change something, or if we decide to isolate the system from dependencies on the OS that it boosts portability.
Inhibits or enables a systems quality attributes.
The decisions an architect makes are generally not for the sake of functionality, but for the achievement of required quality attributes. Whether a system will be able to exhibit its desired quality attributes is largely determined by its architecture (even if the resulting implementation is poor). This is a key point.
Creates reasoning for managing change.
A system will change, it might need new features, need to adapt to new operating systems and hardware (new environments), handle more robust security, need more user types, have bug fixes deployed etc. Every architecture separates possible system change into 3 categories and a good architecture will ensure that change occurs more in the first category than the 3rd (which hikes up effort, cost and delays):
- Local change – Accomplished by modifying a single element (adding a new attribute to a single database table)
- Non-local change – Requires multiple element modifications but leaves the current underlying architecture untouched (you add an attribute to a database table, this requires a change to a business rule, which also requires a change in the GUI).
- Architectural change – Affects the fundamental ways in which the elements are positioned and interact with each other and will require that change occurs all over the system (you change all communications to asynchronous instead of synchronous, you switch from single processor support to multiple processor support). So architecture is the things that are hard to change.
Defines constrains on an implementation.
An implementation ‘exhibits an architecture’ if it conforms to the design decisions prescribes by the architecture. A well thought out architecture will ensure that the implementation results in the desired quality attributes. Deviation from the architecture will highlight problems and a non-attainment of the required quality attributes. As an example, an architectural decision for an element (software component) to perform within a certain performance budget (complete a task with 10 milliseconds) must be honoured by one implementer to ensure that a sub-system of elements performs within an overall performance time of 1 second, meeting the performance quality attribute requirement.
Enables evolutionary prototyping.
Once you’ve created an architecture, you can create an executable skeleton whereby you can analyse the consequences / take measurements of your architectural design decisions to understand whether the architecture is feasible going forward. Will it perform well?, is it portable?, are there bottlenecks? – You can then flesh out the skeleton. This hugely helps when identify risks.
Easier to use independently developed components.
Decreasing time to market, re-using existing solid architectural design decisions, reduces cost and testing time.
Influences the organizational structure.
By drawing up a technical architecture, you have influence on how the system is implemented and who implements it. In project management, the architecture will define the work breakdown structure, who the teams are (and what new teams need forming), what teams and individuals needs to work with who. This will affect budget, hiring, training, communication channels, internal procedures, resource sharing and file system organization.
Enhances communication between stakeholders.
Because architecture is an abstraction, you don’t deal with all of the detail all of the time in architecture so it removes the barriers in communication. This means you can explain and show the architecture to non-technical people / key stakeholders than can provide business input. Discussing the architecture will the stakeholders will allow you to make trade-off decisions in terms of the design.
Improves cost and schedule estimates.
One of the roles of the architect is to assist the project manager in coming up with a cost and implementation / deployment schedule. This needs to be done early on in the project, therefore an upfront architectural design is key in getting a more accurate vision of the cost and schedule. This is top down estimation. Alternatively, an architectural plan will allow an architect to define a high level set of teams, who can provide a bottom up estimate. A combination of both top down and bottom up estimates provides a consensus that is likely to be more accurate.
The architecture can be a re-usable model.
If an architecture proves to be successful and produce the quality attributes desired, the components, decisions, reference material, templates, test harnesses and prototypes can be re-used again.
Can be the basis for training.
Successful architectures can be used to train new team members. When there is only implementation code, it is very difficult for a user to get familiar with a system. Having a well-defined architecture will allow a developer to understand the design time component relationships and runtime operation of the system.
Pretty good reasons to spend some time in the initial stages of a project drawing up an architecture wouldn’t you say.
This list was compiled through my own research and also by referencing “Software Architecture In Practice – 3rd edition” which is an excellent book that is well worth investing in if you’re taking a serious look at working in the world of software architecture.