Software architecture can be defined following two 'major' points of view. The two points of view are technical and functional. The idea developed here is to design the system independently following these two axes and to merge them (projection operation) later in the process.
This offers many advantages:
- Separate the team in two very early in the development
- Use the same technical architectures for many applications
- Be able to switch the functional architecture between different technical architectures
- Give a guideline for the overall software development process and a robust design
Generally, technical architecture is less well understood that functional, so below more details will be given for the former.
The technical architecture of the system must be designed to support the technical requirements. The concept of technical requirements is often misunderstood and limited to technical constraints.
It is important to understand that the technical architecture must reply not only to the technical constraints but also to the technical functions/services the user will expect from the system
Equally important is not to confuse technical functions/services with functional functions(?)/services (discussed later). A helpful rule of thumb is that functional requirements have business value and technical requirement don't.
Examples of classical technical constraints are performance, stability, geographic distribution, ...
Classic examples of technical services are authorisation, persistence, object CRUD management, user interfacing, ...
However, the two aspects of technical requirements (constraints and services) will be handled similarly by the technical architecture. It is just important not to limit the technical analysis to the technical constraints therefore forgetting the services (and integrating them into the functional architecture which is a mistake).
Technical use cases (in contrast to standard use cases which are functional) are used as the primary means to describe technical requirements. This allows using standard use case methods to design the technical architecture.
The main outputs of this analysis are technical kernels, which provide packages of technical functions replying to the requirements across the system and in particular they 'model' the layers.
The functional architecture is designed to respond to the functional requirements. As mentioned previously, functional requirements have business value. These are things which must be done for the business to run (in opposition to the technical authentification service for example).
Use cases are the preferred medium for defining the functional requirements (with business modelling as input). Many methods exist to develop architecture based on use cases and these can be used here.
Mainly, this analysis results in a number of functional packages which put together support the business processes the system is required to.
The projection phase is admittedly one of the most complex operations in architecture design. The goal is to project the functional architecture onto the technical architecture. This generally results in an architectural matrix because the functional architecture is a row (horizontal) and the technical architecture is a column (vertical).
Another way of seeing this is by considering how each functional component blends with the technical kernels.
The result of the projection is the software architecture.