Hitchhiker's Guide to Software Architecture and Everything Else - by Michael Stal

Friday, November 16, 2007

What is Software Architecture

Like Andrew Tanenbaum, I could argue that there are so many definitions for software architecture that it is difficult to choose from them. You may also define it as follows: Software architecture is taken into consideration only when it hurts.
One possible definition for software architecture could be as follows:Software architecture denotes the set of artifacts and practices required to build a software system so that it achieves its implicit and explicit qualities. It includes the systematic partitioning of the software system into appropriate subsystems and relationships as well as the guiding principles used for that purpose. The partitioning of responsibilities and interactions need to be modelled using an interrelated set of viewpoints to address the functional and non-functional qualities.
Note that I am using "systematic" as an important attribute here as I don't consider ad-hoc systems (for example just hacking a Java program) as software architecture. From this personal definition follows that software architecture is both an entity and an act.
I am wondering what your favourite of software architecture is. Maybe one of the dozens available at the CMU SEI webpages?

5 Comments:

  • I think software architecture is an attribute of a system (whether it is designed systematically or ad hoc)
    The job of the architect is to ensure that the architecture is intentional and actually balances the correct quality attributes.
    Here is my definition:

    Software architecture is the collection of the fundamental decisions about a software product/solution designed to meet the project's quality attribute requirements. The architecture includes the main components, their main attributes, and their collaboration (i.e. interactions and behavior) to meet the quality attributes. Architecture can and usually should be expressed in several levels of abstraction (depending on the project's size).

    If an architecture is to be intentional (rather than accidental), it should be communicated. Architecture is communicated from multiple viewpoints to cater the needs of the different stakeholders.

    By Anonymous Anonymous, at 10:13 PM  

  • Hi Michael, give me a try.

    My definition is pretty simple: Software Architecture is the main interface between requirement management and development. Software Architecture defines the basic components (or services), their main interfaces, their interaction, communication and distribution within the system. It reflects non-functional requirements like performance, robustness and stability (just to name three) in particular. In addition, software architecture is essential to tame complexity, the worst enemy of stable, secure and lasting systems. And, a decent description of the architecture is the best tool to explain a system to all stakeholders – customers, developers, testers, marketing folks and managers. This might sound simple but it is definitely not.

    By Blogger Maik G. Seewald, at 1:29 PM  

  • My definition is pretty simple: Software Architecture is the main interface between requirement management and development. Software Architecture defines the basic components (or services), their main interfaces, their interaction, communication and distribution within the system. It reflects non-functional requirements like performance, robustness and stability (just to name three) in particular. In addition, software architecture is essential to tame complexity, the worst enemy of stable, secure and lasting systems. And, a decent description of the architecture is the best tool to explain a system to all stakeholders – customers, developers, testers, marketing folks and managers. This might sound simple but it is definitely not.

    By Blogger Maik G. Seewald, at 1:30 PM  

  • Great definitions if you ask me. Thanks to Arnon and Maik.

    -- Michael

    By Blogger Michael, at 10:09 PM  

  • If we don't know what it is, then how can we refactor it?

    For now, I think I'm going to use "High-level design", or perhaps even "High*est*-level design". That is, your architecture, as your design, is part of your implementation, defined completely by source code and how it is organized (namespaces, assemblies, packages, modules, etc.).

    This, I think, gives me a concrete target of my refactoring efforts.

    By Blogger Unknown, at 7:47 AM  

Post a Comment

<< Home