What's a Software Architecture?
Thursday, February 26, 2009
A software architecture deals with (taken from Beautiful Architecture
What functionality does the product offer to its users?
What changes may be needed in the software in the future, and what changes are unlikely and need not be especially easy to make in the future?
What will the performance of the product be?
How many users will use the system simultaneously? How much data will the system need to store for its users?
What interactions will the system have with other systems in the ecosystem in which it will be deployed?
How is the task of writing the software organized into work assignments (modules), particularly modules that can be developed independently and that suit each other's needs precisely and easily?
How can the software be built as a set of components that can be independently implemented and verified? What components should be reused from other products and which should be acquired from external suppliers?
If the product will exist in several variations, how can it be developed as a product line, taking advantage of the commonality among the versions, and what are the steps by which the products in the product line can be developed (Weiss and Lai 1999)? What investment should be made in creating a software product line? What is the expected return from creating the options to develop different members of the product line?
In particular, is it possible to develop the smallest minimally useful product first and then develop additional members of the product line by adding (and subtracting) components without having to change the code that was written previously?
If the product requires authorization for its use or must restrict access to data, how can security of data be ensured? How can "denial of service" and other attacks be withstood?
It's a mouthful, isn't it?