What is software architecture ?

In a few words, software architecture defines a set of decisions about how to implement a complex IT system.

Pre-requisites for a good architecture are a good knowledge of the functional, non-functional requirements and the key scenarios. A good understanding of the overall environment is equally important to design a solution that will perfectly fits with existing platforms and interacts with other external systems. One of the first steps when analyzing the way to build a future application is to understand what are the key design goals and the existing constraints. Some of the principles that could influence the solution are :

  • Build to change instead of building to last
  • Model to analyze and reduce risk
  • Identify key engineering decisions

The purpose of a good architecture is to design a solution that will fit the business needs, by maximizing the qualities of the system. Important decisions will influence the final implementation. By taking care of the environment and the requirements, the software architect can recommend :

  • the architectural style (or a mix of them) : Client/Server, smart client, web application, a service-oriented architecture, a message bus, ...
  • the deployment strategy
  • the technologies, existing tools, frameworks or applications
  • the decomposition in layers and tiers

Following the requirements, the software architect has to determine what are the needed solution technical qualities and propose a mean to fulfil them. The quality attributes of a system can be :

  • System qualities : supportability, testability
  • Run-time qualities : availability, interoperability, manageability, performance, reliability, scalability, and security
  • Design qualities : integrity, flexibility, maintainability, and reusability
  • User qualities : usability

A complete software architecture includes different views that is described by a blueprint using a well-known notation (typically UML) :

The logical structure

A static view describes the logical subsystems (abstraction or logical components) and how responsibilities are distributed among these different subsystems. It includes also the description their relations and what are their different interfaces. Representation will typically be packages, classes and components diagrams (object oriented abstractions and entity-relation schemas).

The dynamic behavior

When the subsystems and their interfaces are defined, the software architect will describe the interactions between them. This is more a dynamic view of how the subsystems communicates and how to handle the process flow, the concurrency, synchronization and integrity aspects of the design. The best graph to represent dynamic aspects is sequencial diagrams.

The implementation environment

This part of the architecture describes aspects of the implementation like the language and its version, the IDE (integrated development environment), the source control system, packages names, the physical structure of the sources but also naming or coding conventions. Base classes, building blocks are described and analysed for covering the cross-cuttting concerns :

  • Authentication and Authorization
  • Caching
  • Communication
  • Configuration Management
  • Exception Management
  • Exception Management
  • Validation

The deployment view

The software executes on a network of computers (nodes). The various elements (processes, tasks, packages) are mapped onto the various nodes. The different runtime environment are described (development, test, acceptance, production). Each of them will require special configuration and parameters. But the code has to stay independant (or the most independant possible) of its runtime environment and should be able to execute without receompilation on any of the platform.

But this is just an overview, the matter is complex and large. If you need help for a future project, think about Codeflow !