Random Thoughts

Lately the question of what is an architectural change of a software system, has popped up in various discussions. The answer to this question guides the involvement of architects in systems development, and architecture governance and documentation.

I would say, that if we base on the well-known definitions of software architecture, only certain kinds of changes could be considered as changes of architecture, independent of how big in terms of effort the change is.

In many previous works on software systems architecture, the architecture has been defined as consisting of following three parts:

For example the definition of (software system) architecture, adopted by many standards organizations, the (software system) architecture is "fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution" (e.g. ANSI, IEEE and ISO).

That definition, which is revolving around building a structure for certain purpose, is well in sync with the definition of architecture in civil engineering (by which the discipline of software architecture is inspired), where architecture is mainly seen as “the art or practice of designing and building structures and especially habitable ones” [Merriam Webster].

Although the latest incarnation of the ISO standard on systems architecture description [ISO 42010:2022] has for some reason dropped “elements and relationships” from the definition of system architecture, I will stick with the previous definition, as the elements and their relationships of the software system, which representing how the software system is built, are the most important things to consider in the context of the change of the system.

To clarify what is the architectural change, we need to bring in one more concept – the architecture style – which represents what is architecturally common to a family of software systems, being a kind of design language for the software system architectures, and is usually seen as consisting of following things [Garlan & Shaw, Shaw & Clements and SEI CMU]:

Well known architecture styles are for example: data flow (a.k.a. pipes and filters), data centered (a.k.a. repository) systems, layered systems, etc. [Garlan & Shaw].

Now, based on these definitions, we can define what we mean by the change of architecture (or architectural change) of the software system.

Following kinds of changes of a software system can be considered as changes of the architecture (or architectural changes):

adding a new or removing an existing component,
adding a new or removing an exiting connection, and
adding a new or removing an existing rule or principle guiding the design and evolution of the software system.

Two first ones are simple and local, because they do not affect the architecture style of the system, but the last one is in nature complex, as it can affect the architecture of the system globally, and can lead to the change of the software system architecture style (e.g. by changing set of allowed component and/or connection types, and the way how the software system can be built using the components and connections).

Simple description of architectural changes could be given by coloring the corresponding elements on the diagram ("green" for additions and "red" for removal):

Defining architectural change this way means for example, that if the existing rules and principles of a software system architecture allow implementation of components on several platforms, then reimplementing an existing component on different platform, allowed by the architectural rules and principles, is not an architectural change. But if the new platform is not yet included into the architecture rules and principles and will be by this change, then this change is an architectural change.

If the change is such that the meaning/purpose of one component or connection has been changed, then this must be considered as being equal to the removal of the old component or connection and introduction of a new component or connection.

A good example of the later case is (a rater usual case of) change of the core schema of a central database (or repository) of a repository-centric system in case there has not been established any interface schemas for connections with the processing components of the system or otherwise insulating those from the central database (or repository), we in architectural sense actually replace one (in this case very central) component and all its connections to all other components.

Therefore one, seemingly small, change becomes actually a massive architectural change, affecting whole system (causing cascading changes and possibly leading to many unanticipated side-effects).

If we consider the simple measure of the complexity of software system the number of components and connections (see Complexity in/of the enterprise architecture), then this way of treating the architectural changes allows us also simply measure the effect of the changes to the complexity of the architecture, by the added/removed components and connections.

Although the reasoning above is about the architecture change of the software systems, the formulation of systems architecture as a set of components, their interconnections and rules of composition, does not rule out any other types of systems -- so we can apply same definition of architecture change also to the business system (or to the combinations of both business and technology systems).