Reading Fielding - Software Architecture

In the first chapter of his dissertation Architectural Styles and
the Design of Network-based Software Architectures, Roy T. Fielding defines software architecture.

A software architecture is an abstraction of the run-time elements of a software system during some phase of its operation.

A software architecture is defined by a configuration of architectural elements...

From this I draw the conclusion that a software architecture is a configuration of abstract run-time elements. Abstraction is the process of removing irrelevant details. A software system can be abstracted in many ways, depending on what you want to show. This means that a software system has many architectures. I must object to this definition. To say that a building has many architectures just sounds strange. Perhaps what is meant is that the design of a building is influenced by many architectural concepts. Despite this, the building only has one architecture, its own.

My definition of software architecture adheres more to the traditional meaning of architecture as the documentation for a specific software system as a whole. Fielding makes software architecture synonymous with configuration, which is just one of many abstractions of the whole system. This also have consequences for his understanding of the term architectural view. In Fielding's definition, it is the configuration that can be viewed from different angles, when it should have been the architecture as a whole, with the configuration as one view.

More interesting is Fielding's definition of architectural style.

An architectural style is a coordinated set of architectural constraints that restricts the roles/features of architectural elements and the allowed relationships among those elements within any architecture that conforms to that style.

Styles exist to make it easier "to directly compare architectures for different types of systems". This is a good definition that I can agree with, except that I would have written "to directly compare architectures for different systems", to be more true to my definition of software architecture. But this is a minor complaint. It is worth noting that Fielding does not use the term pattern due to its altered meaning within OOP as compared to Alexander's original definition.

When I look at the definitions as a whole, I get the feeling that Fielding, in his desire to define architectural style, has pulled the definitions of software architecture, configuration and style together, almost making them the same. It would have been better to differentiate them more, making each of them clearer as a consequence.

Lets proceed with connectors.

A connector is an abstract mechanism that mediates communication, coordination, or cooperation among components.

Internally, a connector may consist of a subsystem of components that transform the data for transfer, perform the transfer, and then reverse the transformation for delivery.

I don't use connectors when I describe my own architectures. I think it is better to connect components directly with a use relation. If transformations are necessary, they are better handled by an additional component, implementing languages for the communicating components to use.

Finally I want to say something about data. Lets see how Fielding defines them.

A datum is an element of information that is transferred from a component, or received by a component, via a connector.

I agree with Fielding that data is important. But I choose to include them in the definition and design of languages, subsequently used and implemented by components. I get a feeling that he likes the notion of data being transmitted over connectors because this closely mimics his own main interest, the design of network-based software architectures.

P.S.
Yes, behind every component and connector there can be a large architecture that has been abstracted away. In this sense Fielding is correct when he talks about "the many architectures within a system". But this definition is not useful when analyzing the architecture of a system, precisely because all the uninteresting architectures have been abstracted away.
D.S.

P.P.S.
In one of his blog posts, Fielding says "Compare that to the Atom architecture within my blog, which consists of just the externally observable behavioral abstraction." In my view, externally observable behavior is a language or interface, not an architecture. Perhaps this is not what he meant, but it is easy to draw that conclusion.
D.S.