• An Architecture for every Application, and an Architect for every team

Every software application has an architecture, regardless of whether the project team has a designated architect.
And every team has a guiding architect, regardless of their designation.

Somebody needs to establish and nurture it. Ignoring this imperative leads to spagheti systems - non-maintainable and brittle. Many of us working in software delivery teams do what can be called ‘architectural work’, without having the labels (designation). And most software projects will have a small set of senior developers who create a workable architecture - whether they document it or not.
So architecture is as much a skill, as it is a role.

• Good software architecture focuses on business requirements rather than frameworks, models or programming paradigms

While all of that goes into creating an application, the underlying principles that guide the architecture need to be informed by business requirements.

When architectural decisions are technology-driven, it is largely owing to (Enriquez, 2018) :

1. Familiarity: wanting to stay in the comfort zone of what one already knows
2. Resume imperatives: wanting to brandish the latest technology in one’s skillset

What is Software Architecture

• the fundamental structures of a software system – making structural choices from among a realm of possibilities.

  software elements, and the relations among them properties of the elements and the relations

• the discipline of creating such structures and systems
• a blueprint for the system: helps identify tasks to be executed by design teams
• captures early decisions about high-level design
• facilitates communication between stakeholders

At a conceptual level, architecture is simple: you apply patterns, create perspectives, etc. However, reality is complex: you release a product and entropy takes over.

• a Building architecture metaphor is frequently applied in the literature

  conjures picture of a master builder creating beautiful designs. In reality, even with great buildings an architect’s work involves balancing opposing forces of site, budget, taste, function and physics.

Similarly, dev teams face day-to-day struggles from opposing pulls of speed, quality, cost, etc.

(Fowler, 2002) paraphrases a now widely mis-interpreted post by Ralph Johnson:

‘architecture is subjective, a shared understanding of a system’s design by the expert developers on a project - in the form of the major system components and how they interact.
It’s about the decisions that developers wish they could get right early on, because they’re perceived as hard to change. In the end, architecture boils down to the important stuff - whatever that is.’

Most contexts reduce this simplisticaly to the following, without attribution, highlighting the dangers of quoting out of context:

‘architecture is the stuff that is hard to change - the important stuff - whatever that is’

This leads to the urban myth that architecture is inherently hard to change - something that doesn’t dovetail with agile.

Architecture:

• not just a conceptual domain of experts disconnected from reality
• a rough-and-tumble of daily give-and-take: daily tussles of team members who have to balance trade-offs and competing forces to deliver high-performing applications.

The goal of architecture is to enable early and continuous delivery of business value from the software being developed.

Why create one?

• every domain has some architectural characteristics that are important to it, such as security, scalability, performance or resiliency. Proper architectural analysis helps fulfil these non-domain architectural characteristics.
• architecture also produces models at a a level of abstraction where business and technology decisions can be made (such as comparing options and analysing properties)
• architecture helps plan interim or migration states as a roadmap to a successful implementation in the future

Architectural Styles

APIs

• APIs are forever: design with care Once an API is released to production any significant change may potentially break existing integrations. Hasty design decisions can cause confusion, support issues and lost opportunities far into the future.

Glossary

Artefacts: architecture deliverables such as models, templates

References

1. Enriquez, A., R. & Salazar. (2018). Software Architecture with Spring 5.0. Packt.
2. Fowler, M. (2002). Patterns of Enterprise Application Architecture. Addison-Wesley.