Components, Software Architecture and Product Structure

I shall begin with some basic concepts that are useful when discussing software architecture and the software development process.

Sequences of binary data are the foundation of software systems. These sequences form the natural components in the software architecture. The binary data are structured according to some language definition and, when interpreted, will give rise to a specific behavior. We say the component uses a given language to implement a new language, which is then available for some other component to use. Components are usually stored in files, but can also be volatile streams.

Note that a component never can do anything by itself. It must always be interpreted by another component which implements the language the former uses. It may seem we are building a castle in the air, or have turtles all the way down, but this time we are lucky. At the bottom is the microprocessor, a component which connects the logical structure of the software architecture to reality, which is what we care about for all practical purposes.

I must now clarify that I do not use the term software component as described in this Wikipedia article, or any other framework for connecting modules together. I mean that any meaningful binary sequence is a software component. It can be a text file, an executable, a network packet, an office document, a source file, a script, an mp3 file, a divx movie, user interaction, and so on.

The languages that connect components are what computing is all about. They are purely abstract constructs that alone define what can be done to reality through the microprocessor. A language can be a communication protocol, a programming language, a video or audio format, an instruction set to a microprocessor, an office document file format, and so on. It is common for languages to be extensions of other languages, for example programming language APIs (AWT/Java), XML schemas (RDF/XML) or protocol layers (TCP/IP).

I don't think I will ever catch up with the state of the art in language theory as it is frequently discussed on Lambda the Ultimate. But I will try, and the obvious read for the beginner is of course Structure and Interpretation of Computer Programs. Language theory is the key to computing.

The software architecture can now be defined as all the components and languages that form the software system, and how they relate to each other. In practice, large parts of the entire structure is omitted when discussing the architecture of a software system. At the bottom is some well known language or runtime environment which is not further explored. It is also common to collect natural components in new abstract components called modules, libraries or packages. This will reduce the software architecture to something that is quite manageable, but still gives us a good overview of the software system.

A software product is then defined as an abstract component, which contain one or more components from the architecture. The reasons to define products are many, but the ultimate purpose is to specify what is delivered to the customer or user. The product can be split into subproducts for reuse or to break dependencies, but this must also be reflected in the architecture, which dictates where product boundaries can be drawn.

Software products are individually tracked with configuration management. They have a version and can be branched. Their quality is tracked with test reports and issues.

The product structure is very similar to the software architecture, but there will be more components in the architecture than products in the product structure. It can be trivial with only one product, or very complicated with hundreds of products and configurations which fulfill every imaginable need. It is up to you to decide where to draw the line.