What is the right definition of “Software Architecture” ?

Recently a colleague gave me an interesting definition of Software Architecture he heard at a conference. It was something like:

Software Architecture is the sum of all decisions made for a software product.

Maybe this is true in some way, but I’d prefer a definition that emphasizes the overview aspect of architecture. In the IEEE standard “1471-2000 – IEEE Recommended Practice for Architectural Description for Software-Intensive Systems” a definition can be found that emphasizes this aspect:

The fundamental organization of a system, embodied in its components, their relationship to each other and the environment, and the principles governing its design and evolution.

Sounds good, however, I miss the aspect that a software architecture doesn’t suddenly appear out of nowhere. It is more a process than an entity. A process that never ends, the Architecture constantly changes and erodes during a product’s lifetime. It is the outcome of a tremendous amount of communication and also used in communication to a lot of stakeholders. I found a definition with more regards to this aspect in the “Microsoft Application Architecture Guide, 2nd Edition”:

Software application architecture is the process of defining a structured solution that meets all of the technical and operational requirements, while optimizing common quality attributes such as performance, security, and manageability. It involves a series of decisions based on a wide range of factors, and each of these decisions can have considerable impact on the quality, performance, maintainability, and overall success of the application.

Well, after all I’m still not 100%ly confident with this definitions. What would be your definition ?

Typedef or template ?

Every once in a while I see c++ templates being used in code that has only one single type to pass into the template. This type might change in future application versions, but it is forseeable that it will always be one and the same for the whole application. In this case I always ask myself why the developer hadn’t chosen a typedef instead.

Example: If a class processes the float data type and for future versions shall also be prepared to process double types – but a mix of float and double is no use case. In this case using a typedef offers the same degree of versatility – without the drawbacks of template programming. As drawbacks I see a higher code-complexity and a tendency to write code in .h files that belongs to .cpp files (although it is possible to split up .h and .cpp files also for templates – if one chooses a fixed set of types to be compiled in – but that’s a topic for another blog …).

Don’t get me wrong, there are many situations where templates are justified: If several types have to be processed by the same class and in the same application. Or if an independent binary library isn’t supposed to be recompiled for an application-specific set of types. But, again, a template should not be used if it will be compiled for only one type in an application (and if it is forseable that it will always be only one). If the type might change, but the amount of supported types will remain 1: Use typedef as long as you can.