Five Tips for Producing a Quality Solution Architecture

Establishing a suitable architecture early in a software development project can be critical to the success of that project. The architecture forms the core of the solution, and insufficient attention and consideration early in the project can result in costly issues and changes later in the project.

Given the importance of a robust solution architecture Equinox regularly undertakes assignments that involve reviewing proposed architectures and providing an independent assessment of the architecture in behalf of the client or the business. This article provides some useful tips on some of the things we look for, which may help you when producing solution architectures.

1. Does your solution architecture exist and can it be communicated?

The formality of the solution architecture will differ from project to project, depending upon the size of the project and the tools and methods being used. However, whatever the project you do need to give sufficient attention to important architectural considerations and you do need to be able to communicate it in a manner that can be consistently understood by project stakeholders. We sometimes see architectures that have not been documented using standard views or notations, and this can undermine the architecture if the readers interpret the architecture inconsistently.

• Have you given due attention to key architecture considerations?
• Has the architecture been documented?
• Is the architecture documented using an industry standard notation and using standard architectural views that can be read and understood clearly by other parties involved? 

2. Have the non-functional requirements been elicited and captured?

Requirements analysis activities often place attention on functional requirements, with non-functional requirements sometimes taking a lower priority. From an architectural perspective non-functional requirements are very important and will influence key architectural decisions. We sometimes see non-functional requirements that are poorly defined or worse development teams making assumptions on these requirements, which creates a major architectural risk to the quality to the solution.

• Have non-functional requirements been fully elicited from the business?
• Have the requirement been captured against all fundamental non-functional categories, as outlined in ISO9126 or FURPS (functionality, usability, reliability, performance, supportability)? 

3. Does the proposed solution architecture meet the organisation's needs?

In developing your solution architecture you need to ensure that core functional and non-functional requirements have been considered and addressed in the architecture, which should give you confidence that a solution built on the architecture can meet those requirements.

• Is the proposed solution architecture appropriate for the organisation – not over engineered and not under engineered?
• Does the proposed solution architecture address the functional and non-functional requirements?
• Does it meet the organisation's overall needs? 

4. Is solution maintainability being factored into the architecture up front?

More organisations would like software solutions to be delivered that can be maintained internally or by third parties who were not involved in the development. On these projects maintainability becomes an important architectural consideration that needs to be accommodated within the software architecture and development practices up front. As per other architectural considerations it is costly to retro fit maintainability into the solution toward the end of the project.

• Have maintainability requirements and standards been elicited and agreed?
• Does the architecture and software practices support the development of a maintainable solution that will adhere to the maintainability requirements and standards?
• Have maintainability standards been integrated into the software development processes? For example do tools stop code from being submitted if it does not meet the agreed standards? 

5. Is the development team ready to enter construction phase?

The development team is clearly critical to the development of a high quality solution. You need to have confidence that the team is ready to construct a solution in a disciplined manner that will adhere to the solution architecture and the requirements.

• Has the development team given sufficient consideration to architecture and design?
• Are they following an agreed software development methodology?
• Have they got the required processes and tools in place to develop a quality solution that adheres to the architecture?