Reviewing a 1992 paper: Foundations for the study of Software Architecture

This seminal paper by Perry and Wolf pulls Software Architecture definitions from established architectural disciplines.

Software architecture model consist of 3 components:

• Elements: processing, data and connecting elements
• Form: properties of/ relationships amongst elements
• Rationale: system constraints amongst elements and form.

Architecture vs Design

Design is a separate activity from implementation, but it is also a separate activity from architecting.

In design, there needs not be any reason given, any standards followed. However, architecture evokes notions of codification, abstraction, standards and style. It points the Software Architect to "this is how" and "this is why" - a formal methodology which requires formal training.

Gains and expectations

• Architecture must satisfy the functional and non-functional requirements of the system
• Architecture is the basis for design, cost estimation and process management
• Architecture as an effective basis for reuse
• Architecture as the basis for dependency and consistency

What I particularly love is how the field of software architecture was synthesized from other disciplines

Like a building architect who sits with a client to design their future home, the software architect must sit with the various users and use cases to design both the functional and non-functional requirements of the system.

Descriptive vs Prescriptive architectural style

Descriptive - codification of design elements and formal arrangement

Prescriptive - limits the kinds of design elements and their formal arrangements

Because one does not just build a sky scrapper with wooden posts and beams.

• Architectural choices has to be tied to Software Engineering principles (prescriptive)
• Architectural choices has to be tied to Software Engineering materials (descriptive)

The design process

1. Requirements: information about users and use cases
2. Architecting: framework for satisfying the requirements that determines what architectural elements to select and how they would interact with each other.
3. Design: modularization and detailing of interfaces of the architectural elements, data types and database types
4. Implementation: representation of the algorithm and data types for the design

Tech debt: Bad architecture leads to huge debts

Technical debt defines the increasing brittleness of a system - that is its increasing resistance to change or at least to change gracefully. Whilst it has been seen as a problem with the codebase, it is actually a 2 part architectural problem:

1. Architectural erosion: violations of the architecture
2. Architectural drift: insensitivity about the architecture - which leads to inadaptability of the architecture. This then results in lack of clarity and coherence of form - which in turn makes it much easier to violate the architecture that has now become more obscure.

Take home

• Using a framework like react (a javascript web library) or django (a python web framework) or spring (a java framework) does not automatically give your code an architecture.
• If you don't know the underlying architecture upon which the framework you are using is built, it is easy to violate it.